Other than my usecase, this is a general configuration issue. In
the
old JBossWeb your were required to have a truststore that had each and
every CA each application required. Which is counter to the idea that
each application has its own security domain.
I completely agree, but as I say I think we do quickly run into
technical reasons why this is needed outside of our control - but I will
double check.
On 6/27/2013 12:02 PM, Darran Lofthouse wrote:
> On 27/06/13 16:14, Bill Burke wrote:
>> You can just pass in a dummy trust manager.
>
> Yes we use custom trust managers in a couple of places.
>
> The response from this method may only be applicable to web browsers but
> I seem to remember there was something that the browser relied on this
> information coming from the server to decide which certificates the
> client could choose from.
>
> For a client where this is entirely in it's control this may not be an
> issue.
>
> I am not against what you are asking for, let me try it out again and I
> will see what options we have for a trust anything config, even for our
> Client Cert scenario integrating with PicketLink it may be easier for us
> to trust anything and then compare with PicketLink at the time a secured
> resource is accessed.
>
> Regards,
> Darran Lofthouse.
>
>> On 6/27/2013 11:04 AM, Darran Lofthouse wrote:
>>> I will have another look, last time I looked into this however there did
>>> seem to be a need for list of accepted issuers of certificates to be
>>> returned from the X509TrustManager in use: -
>>>
>>> X509Certificate[] getAcceptedIssuers()
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On 27/06/13 14:10, Bill Burke wrote:
>>>> Its an IDM SaaS, so different realms will have different security
>>>> models. It should be possible from a NIO perspective, no? Last time I
>>>> looked at that stuff it did seem possible.
>>>>
>>>> On 6/27/2013 5:47 AM, Darran Lofthouse wrote:
>>>>> I will check for you but from last time I worked on this I am not
sure
>>>>> if that is possible - I think a valid trust store was still required
>>>>> server side to verify the remote certificate - even if it was just a
>>>>> trust store containing certificate authority certificates.
>>>>>
>>>>> Do your clients definitely not have a least a common certificate
>>>>> authority signing their certificates?
>>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>>
>>>>>
>>>>> On 26/06/13 23:57, Bill Burke wrote:
>>>>>> Sorry, I want to be able to validate the client cert within the
>>>>>> application servlet.
>>>>>>
>>>>>> On 6/26/2013 6:56 PM, Bill Burke wrote:
>>>>>>> I think you misunderstood me. Not looking for client-cert
auth. I want
>>>>>>> to be able to validate the client server within the
application servlet.
>>>>>>>
>>>>>>> On 6/26/2013 6:50 PM, Tomaz Cerar wrote:
>>>>>>>> It can do it already but config is going to change in
future.
>>>>>>>>
>>>>>>>> Take a look at WebCERTTestsSecurityDomainSetup in
testsuite on how to do it.
>>>>>>>>
>>>>>>>> Basicly you have to setup securityRealm with server ssl
cert, then setup
>>>>>>>> securtiy constraints for web app
>>>>>>>>
>>>>>>>> That test we have in testsuite also tests mapping client
certs to users via
>>>>>>>> CertificateRoles security module.
>>>>>>>>
>>>>>>>> --
>>>>>>>> tomaz
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: undertow-dev-bounces(a)lists.jboss.org
[mailto:undertow-dev-
>>>>>>>>> bounces(a)lists.jboss.org] On Behalf Of Bill Burke
>>>>>>>>> Sent: Thursday, June 27, 2013 12:11 AM
>>>>>>>>> To: undertow-dev(a)lists.jboss.org
>>>>>>>>> Subject: [undertow-dev] certs
>>>>>>>>>
>>>>>>>>> I need to be able to client certs in the following
manner:
>>>>>>>>>
>>>>>>>>> * Set the server to WANT client certs so that it is
optional
>>>>>>>>> * Obtain certificate at the servlet layer so I can
validate it myself.
>>>>>>>>>
>>>>>>>>> Can Undertow do these yet? Just want to know so I
can create the
>>>>>>>>> appropriate jiras.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Bill Burke
>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>
http://bill.burkecentral.com
>>>>>>>>> _______________________________________________
>>>>>>>>> undertow-dev mailing list
>>>>>>>>> undertow-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>>>
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>
>>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/undertow-dev
>