Shibboleth Developers

[Chad La Joie <>]

On yesterday's developers call we talked for a good amount of time about 
how people might integrate the Java SP with their application.  I took 
away, from the discussion, to main areas of focus:

1. What ways might web app developers expect to integrate Shibboleth 
into their application?

2. What available integration points does the J2EE specification allow.

Let me try to cover what I've learned having spent a day and night 
studying applications and the Servlet spec.  First, I learned I have no 
life.  More importantly I found the following 4 ways generally used to 
integrate authentication, and in particular SSO based authentication, 
into apps.

* Programmatic Integration - Where the developer specifically calls out 
to an authentication source, perhaps through some library like Acegi or 
more directly by making DB or LDAP calls.  Providing something like this 
would require a pretty big learning curve and would be pretty invasive 
to the code itself.

* Container Integration - Where the application relies on the container 
to perform the authentication and the app just looks for information in 
the request of session.  This is analogous to the way the current C++ SP 
works.  There is no standard interface for this type of integration, 
either on the container side or on the application side, though on the 
application side there are common sense APIs that could be used.

* Servlet Integration - Where one or more servlets are deployed along 
with the application.  The servlets handle the authentication stuff and 
make the data available via the session or request objects.  This has 
the benefit of working with the J2EE standard but still requires some 
invasiveness.

* Filter Integration - Where a servlet filter is deployed, probably 
invoked based on a URL-mapping and not specific to a given servlet or 
set thereof.  Information again is made available through the session or 
request.  This is probably the least invasive option and the one I 
currently favor.

I'll note that the last three options require that the application 
expect information to be provided through the request or session 
objects.  This is *not* how most web applications (Java or otherwise) 
work, most expect to read their own internal store of data.

I know that a number of people have piped up with the suggestion of JAAS 
and Tomcat realms.  Let me address each.  JAAS is *not* meant for web 
application or for SSO.  It was originally an API for doing 
authentication in desktop apps that collected user name and passwords. 
Some people have managed to hack JAAS into other areas but it's pretty 
messy.  Frankly, JAAS is just a poor AuthN API.

Tomcat realms are nice but they are Tomcat specific.  If we went this 
route the SP would not be deployable on anything other than Tomcat (I 
think there would problems even with JBoss and Geronimo, which embed 
Tomcat).

In summary.  The J2EE spec offers no standard way to perform SSO based 
authentication.  Servlets and Filters are the only standard mechanism 
available and offer the smallest learning curve but still require 
applications to be "federation-aware".
--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124