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.
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