Adding Pluggable Authentication to all Servlet 3.0 Containers

I been working with the Servlet 3.0 Expert Group to define the new security features to be added to Servlet 3.0. As part of this work, we are discussing whether Servlet 3.0 compatible containers should be required to support the Servlet Container Profile of JSR 196.

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.

Comments:

Absolutely. I'm currently in alpha with a JEE5 application that should be deployable on any JEE5 compliant application server. The catch is that the application is an authentication server. It contains it's own internal authentication mechanisms and is managed entirely through a web interface. This pretty much breaks the app-server agnostic idea. If the server does support JSR 196 it might work. If not, there's a world of hurt ahead.

Thanks for your postings on the subject of ServerAuthModules and JSR 196. They've been invaluable in getting this far.

Posted by Eric on May 18, 2009 at 08:57 AM EDT #

Eric,

Thanks for your interest and support. You may be interested to know that Geronimo has integrated support for JSR 196, and is working to pass the tck. I have also heard that the same may soon be true of Jetty. Also, I prototyped an extension to Tomcat, which I need to find the time to make available.

What application servers are you targeting for deployment of your authentication service?

Ron

Posted by ron on June 15, 2009 at 04:32 AM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

monzillo

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today