> "[i]In Glassfish, you can instigate SSL client auth
> from your SAM (if an SSL transport has already been
> established as a result of the enforcement of a
> transport guarantee) by requesting the proprietary
> attribute
> "org.apache.coyote.request.X509Certificate[/i]."
> However this way of doing have two major drawbacks:
> - There seems to be no portable way of doing this.
> - The SAM should decides itself which authentication
> applies in which case...
Hi Marc,
you are correct that the attribute-based instigation of a tls renegotiation
is not standard. Moreover, the TLS protocol impl must be up-to-date with recent changes
to the protocol, that were made to mitigate a vulnerability inherent in renegotiation.
that said, Glassfish and Tomcat both rely on an attribute based instigation of tls renegotiation to cause client authentication. Thus this is the answer to your question about the mechanism used by the JBOSS SAM you referenced. I only skimmed the code, but I believe the attirbute fetch that causes the tls renegotiation occurs within the call to authenticate. That call could also occur directly within the SAM.
> Ron also wrotes[2] that:
> "[i]One way around this, within Glassfish could be to
> support the configuration of a SAM in addition to login-method in web.xml, ...
I don't think there are any plans to do this. In retrospect, perhaps a
better way to empower a SAM to manipulate the properties of the transport connection,
would be to define a new callback, that would provide access to the SSLSession.
> What would also be also really interesting, is the
> possibility to bind different SAM to different
> servlet or url-pattern in the same webapp, each of
> one with specific auth-constraints... [b]that[/b]
> would be great (another way to get rid of the
> infamous single login-method limitation).
I think you can already do this in at least a couple of ways. You have already
suggested multiplexing within a monolithic SAM. Another approach would be define
your own AuthConfigProvider, that returns ServerAuthConfig impls, that return url-specific
AuthContextIDs, when getAuthContextID is called, and that returns different AuthContexts, containing different SAMs when getAuthContext is called with an AuthContextID. I am not
sure that everyone will have a need for this complexity, but I believe it can be encapsulated within the pluggable layers (should it be needed).
Ron
>
> But I've no clues on how the client certificate
> exchange is supposedly being initiated...
>
> Anyway, any insight on the subject is most welcome,
>
> Thanks,
> Marc
>
> [1]
> http://blogs.sun.com/monzillo/entry/pluggable_authenti
> cation_in_the_glassfish
> [2]
> https://glassfish.dev.java.net/servlets/ReadMsg?listNa
> me=users&msgNo=24847
[Message sent by forum member 'monzillo']
http://forums.java.net/jive/thread.jspa?messageID=476895