Adding Pluggable Authentication to all Servlet 3.0 Containers
By monzillo on Jan 29, 2009
The Servlet Container Profile defines a contract to sustain the integration of portable implementations of additional HTTP layer authentication mechanisms in the security-constraint processing machinery of the container. The profile and the JSR 196 SPI on which the Profile is based, were standardized in the JCP in July of 2007. Glassfish V2 is the RI and there is an associated TCK (i.e., Technology Compatibility Kit) as appropriate to ensure common semantics and to sustain portability of mechanism implementations. In addition to the RI, preliminary support for the Profile (without confirming compatibility) has been demonstrated in Tomcat, JBOSS, and Jetty. I have also been consulted on the development of a handful of portable server authentication modules (e.g., Kerberos, OpenID, and OpenSSO).
Feedback from authentication mechanism developers and system integrators has been very positive. Feedback from Servlet container vendors has been mostly supportive, but appears to stop short of being willing to accept a requirement that their products support the profile.
IMV, the existing native Servlet authentication mechanisms (i.e., BASIC, CLIENT_CERT, FORM, and in some cases DIGEST) are no longer sufficient. When we defined the native set, we expected a migration from password-based mechanisms to CLIENT_CERT. That has not turned out to be the path we are on. Instead the industry is embracing 3rd party authentication services, and up to now, portable integration of such services has been accomplished using application layer techniques (such as Servlet filters) that run after the container constraint checking machinery, and thus depend on an application layer replacement for the constraint processing of the container.
If you have a need for the integration functionality that is enabled by the Servlet Container Profile of JSR 196, I would be interested in hearing from you. More generally, I welcome your opinions on this topic.