I’m using standard container authentication for a multi-module application, deployed on latest Glassfish server (3.1.2).
I used to have form authentication for the main web module and http basic authentication for a module containing rest web services.
Now, for both modules, I need to be able to perform certificate authentication, but only as an option. Some clients still need to be able to login via form / basic auth.
I tried to use JSR-196 to intercept certificate authentication data forwarded by a reverse proxy. The problem here is, in Glassfish, it seems I need to reimplement some help that the container provides if I use JSR-196: storing authentication in session, SSO, even form/basic authentication… It’s Glassfish way or mine, it seems, but I want a mix. So, my JSR-196 module now needs to handle cert, basic and form authentication as well as persistence mechanics. Looks overkill.
I tried a more naive approach, namely using form authentication and have my reverse proxy send authentication data to j_security_check. It works for the first module, but is too implementation specific and really looks like an hack.
I also imagined doing cert authentication in another module, directly on the app server (without reverse proxy) and redirecting to the original module once authenticated, using sso as glue. But sso on glassfish won’t work between modules which have different auth types.
I’d rather use something standard, elegant if possible. Also, I want my application to use Java EE security, not some 3rd party lib, be it from Spring or anything else.
What are the options for implementing this on Glassfish?
Finally, I implemented it using a combination of those:
The reverse proxy isn’t used for ssl. I know about the potential issues, but I’m satisfied with it and it’s the best way I found to access all certificate data I want. Other options involve implementation-specific details, this is more standards-based.