Hi Jerome,
I haven't tried any code yet, but I think I found what was going on by
looking at some of the code. What I'm talking about is related to the
first modification mentioned in
http://restlet.tigris.org/issues/show_bug.cgi?id=281
(using getPeerCertificates()).
When using servlets, the specification states that client certificates
should be presented in attribute "javax.servlet.request.X509Certificate"
as a java.security.cert.X509Certificate[] (Section 5.7 of spec 2.2 and
Section SRV.4.7 of spec 2.3).
I think the modification made to use getPeerCertificates() aimed to
achieve this, by putting this information in attribute
"org.restlet.https.clientCertificates" of a Restlet Request. (Out of
curiosity, why use a List and not an array? Although Restlets are not
Servlets, it might have made porting some code a bit easier. I don't
think it really matters, though.)
By looking at the current code in SVN, this feature seems to be
implemented in com.noelios.restlet.http.HttpServerConverter (method
toRequest).
Unfortunately, this relies on HttpServerCall.getSslSession(), which is
implemented in SimpleCall, but not JettyCall (which I believe is the one
used by AJP). Perhaps this is not quite the right place to abstract
this. Indeed, when using Jetty directly or AJP (or the ServletCall I
guess), the HttpServerCall does not get to see the SslSession, but the
relevant information regarding the client certificate can still be exposed.
I reckon it should be possible to convert the content of Servlet Request
attribute "javax.servlet.request.X509Certificate" into
"org.restlet.https.clientCertificates" when using these other connectors.
To be more specific regarding AJP, the mod_jk configuration of Apache
Httpd is at: http://tomcat.apache.org/connectors-doc/reference/apache.html
In particular, to pass the chain of certificate, this should be used:
JkOptions +ForwardSSLCertChain
Passing this from the AJP connection to the servlets is done in Jetty in
this file:
https://svn.codehaus.org/jetty/jetty/trunk/extras/ajp/src/main/java/org/mortbay/jetty/ajp/Ajp13Connection.java
All I've just mentioned is about the SSL certificate attributes, but I
guess it could be useful to expose the SSL cipher, which is String in
"javax.servlet.request.cipher_suite". The servlet spec version 2.3 also
defines "javax.servlet.request.key_size", which should be an Integer.
I'm not sure from which specification the
"javax.servlet.request.ssl_session" attribute comes from, but it's in
the Jetty code mentioned above.
The other piece of information that would be interesting to get
(especially the context of AJP and probably Servlets) is the remote user.
Servlets have a getRemoteUser() method which returns a String. This is
visible via Apache-Httpd -> AJP -> Jetty (and Tomcat, if
tomcatAuthentication is disabled in its AJP configuration, see
http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html ).
This is useful for delegating the authentication task to existing
modules of Apache Httpd (which is also something I'm looking into, aside
from certificates).
Unfortunately, as far as I know, Restlet Requests do not have a
getRemoteUser() method. Perhaps it would be a good idea to pass this,
when it exists, as another attribute, say "org.restlet.remote_user"? I
guess it could be used by other protocols than HTTP/HTTPS.
I could try to write a patch, but since it may modify the API (or at
least the interfaces), it might be better if someone more experienced
with the code does it. I'm going to copy and paste all this in an RFE. I
hope this clarifies what I was trying to get in the first place.
Thank you,
Bruno.
Bruno Harbulot wrote:
Hi Jerome,
Regarding Jetty, AJP and the client certificates, I submitted a patch a
couple of days ago for Jetty, as there was a small bug:
http://jira.codehaus.org/browse/JETTY-457
I'm please to say Greg Wilkins (Jetty) has already incorporated the
changes in Jetty 6.1.6rc1.
I'll try to provide more details and examples later on this week. I've
just spotted a thread on this list about 2-way certificate
authentication which seems relevant.
Bruno.
