Hi,
glassfish_at_javadesktop.org wrote:
> Hello everyone,
>
> I'm currently interested in implementing an jsr 196 server authentication module for some specific infrastructure that we have at work.
>
> This infrastructure requires that we login with a client certificate, and then, additional credentials are fetched by the server using SAML via the "Post binding" (we're only interested by plain web applications, no web services).
>
> The SAML authentication part should be no problem, a ServerAuthModule fit perfectly for this kind of job.
>
> The certificate handling seems however to be a lot more problematic. Some other posts on this ML already addressed the problem of using SSL certificates in conjunction with a SAM, but i just wanted to make a short recapitulation in order not to miss anything:
> - There is actually no way to use the CLIENT-CERT authentication method if a custom ServerAuthModule is registered for a given webapp, because the auth-constraint will always trigger the use of the SAM, and realms will be ignored.
>
> Starting from this, the most obvious workaround are:
> - Splitting the web app in twice, one with a SAM, the other one using the certificate realm.
> - Put the client certificate requirement on a specific http-listener.
>
> None of these solutions would suit us well (and will probably not suit most people).
>
> So, as stated by Ron in one of his blog post[1], a solution would probably be to initiate the SSL connection in my own SAM:
> "[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: contrary to web-service endpoints, we can only have one httpservlet-security-provider registered, and it is applied on all auth-constraints. Having one big monolithic SAM which have to deal with multiple auth-method is probably against the SAM philosophy.
>
> 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, at least
> for the case when CLIENT_CERT is specified in web.xml[/i]."
>
> Well, that certainly sounds like a great idea to me... :-) Is there any hope that it will be implemented in the near future?
>
> 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).
>
> On a side note, there seems to be a CLIENT-CERT authentication module for JBoss:http://docjar.com/html/api/org/jboss/web/tomcat/security/jaspi/modules/HTTPClientCertServerAuthModule.java.html
>
The code for GF will be very similar. I guess the code
request.getCoyoteRequest().action(
ActionCode.ACTION_REQ_SSL_CERTIFICATE, null);
Which has been used in JBOSS would do the same function as requesting the proprietary
attribute "org.apache.coyote.request.X509Certificate" would do on GlassFish.
> But I've no clues on how the client certificate exchange is supposedly being initiated...
>
> Anyway, any insight on the subject is most welcome,
>
You could also try and mimic what CLIENT-CERT auth-method would do
inside your SAM by redirecting a Non SSL request that arrives at the
SAM to an SSL enabled listener on GlassFish which also has client-auth
enabled. I have tried something like this recently. Not sure if this
helps you.
regards,
kumar
> Thanks,
> Marc
>
> [1] http://blogs.sun.com/monzillo/entry/pluggable_authentication_in_the_glassfish
> [2] https://glassfish.dev.java.net/servlets/ReadMsg?listName=users&msgNo=24847
> [Message sent by forum member 'marc_h']
>
> http://forums.java.net/jive/thread.jspa?messageID=476856
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>