search

ratcashdev / authenticroast

Automatically exported from code.google.com/p/authenticroast
1 stars 0 forks source link

SSLClientAuthenticator should not require clientAuth=need or clientAuth=want in Tomcat #18

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The settings named in the Summary force Tomcat to request a client certificate. 
Otherwise the request attribute "javax.servlet.ssl.X509Certificate" is never 
set.

These settings are undesirable in configurations where there are authenticators 
other than SSL, e.g. Form or Basic, because if the user is using a browser to 
login he is presented with a meaningless client-certificate-selection dialog, 
probably listing zero certificates.

Tomcat has internals that will perform an SSL renegotiation to request a client 
certificate, when required by an authentication module. The 
AuthenticationRequestImpl.Tomcat6 class should perform this action on behalf of 
the SSLClientAuthenticator when required, i.e. when the 
"javax.servlet.ssl.X509Certificate" attribute hasn't been set yet.

This fix requires:

1. Add a getPeerCertificates() method to AuthenticationRequest and 
AuthenticationRequestImpl. The basic implementation returns 
request.getAttribute("javax.servlet.ssl.X509Certificate").

2. Modify SSLClientAuthenticator to call this method instead of 
request.getAttribute("javax.servlet.ssl.X509Certificate").

3. Override this method in AuthenticationRequestImpl.Tomcat6 to do the Tomcat 
magic if necessary.

Patch files attached. The pom.xml for the Impl module adds the Apache Tomcat 
'coyote' module, and I brought the 'catalina' module version up to date while I 
was in it.

I don't know how any of this plays out in the JSR196 world. I certainly 
couldn't find anything in the specification (i.e. a PublicKeyCallback) that 
supports it. So the JSR196 implementation will continue to rely on the 
container having already got the certificate from the client. I've provided a 
possible override of the method for JSR196 but it may well be that just 
removing this is a better option.

I also don't know how it plays out in an SSO environment.

Note that to use this in association with clients that don't send the correct 
RFC 5746 messages, you may also need to configure Tomcat's SSL Connector with 
allowUnsafeLegacyRenegotiation="true". Java clients and servers should ideally 
use Java versions > 1.5 update 26, or > 1.6 update 22.

Original issue reported on code.google.com by EsmondP...@gmail.com on 13 Dec 2011 at 4:04

Attachments:

GoogleCodeExporter commented 9 years ago 
Oops, left a trace in there.

Original comment by EsmondP...@gmail.com on 13 Dec 2011 at 4:25

Attachments:

GoogleCodeExporter commented 9 years ago 
I finally solved this a completely different way, by putting an Apache HTTPD in 
front of Tomcat. This allows for much more fine-grained control over SSL down 
to the <Directory> or <Location> level, such that you can change cipher suites, 
use different certificates and CA certs, want/need client authentication, right 
down to the bottom level, rather than be stuck with it all on or off as you are 
with Tomcat. This is a far better solution so the attached patches can probably 
be disregarded in favour of documenting this solution. Now that I've put Apache 
HTTPD in front I am wondering why I didn't do it years ago.

Original comment by EsmondP...@gmail.com on 30 May 2012 at 8:16

GoogleCodeExporter commented 9 years ago 
Note that the AuthenticationRequestImpl.java attached to this question neither 
compiles nor runs under Tomcat 7. The Apache HTTPD solution above is a much 
better technique all round.

Original comment by EsmondP...@gmail.com on 12 Jul 2012 at 9:57