Shibboleth Developers

[Velpi <>]

Little more than a year ago I tried to build some kind of clean, portable 
integration from an IIS/Apache fronted Tomcat with Shibboleth auth into 
container-managed authentication. Out focus shifted away from this too early to 
finish it, but here's what I have learned about that so far:

> * 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.

This definitely the most flexible approach so some people will need it, but most 
people won't want to do this, especially when it's a black box app...
This is really too much of a burden for most deployments, but it should be 
possible.


> * 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.

This is very easy to use and it's a good standard from a user's POV. Some black 
box apps will like this a lot too because of that. But it's not the most easy 
way for integration since every container implements the standard differently. 
It didn't seem easy/possible to hack into that in a general way...


> * 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.

This is a good tradeoff between the burden of programmatic integration and the 
ease of container based integration, but it's usually used in combination with 
one of the other options since it can't really protect any resource by itself. I 
think this will be the best choice for the "Shibboleth handler" 
(Shibboleth.sso), if that's the architecture you want to pursuit.


> * 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.

Filters are heavily used for this kind of integration. They're flexible and easy 
to use. The standard is also very well defined. But they lack thorough container 
integration which often causes problems.


> 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.

If they read their own internal store, then good code has one class that 
centralizes access to the data. Shibbolizing an app usually means replacing this 
class, and often that's the only thing that needs to be changed. so I don't see 
this as a problem, but rather as an advantage.


> 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.

I agree. JAAS should be avoided for several reasons.


> 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).

Try looking at a "Tomcat valve". It's still Tomcat-specific, but I think it's 
more flexible. It offers access to container internals AND the request. It looks 
a little like a filter, but it's called before container managed security kicks 
in which should make it better in that area. (I thought I was getting somewhere 
in the area of container managed security when I started building a valve, but I 
was a little sad for giving up the idea of not making it Tomcat-specific)


In my opinion, it would be nice if the SP code would be built like a library. 
This already enables the use of programmatic security. A filter could be built 
to use this library to make it more easy to use (=code re-usability: the purpose 
of servlet filters). Container integration could be achieved in the same way by 
writing container-specific "things" until there is a good standard for that (eg 
a Tomcat valve that again uses the same "Shibboleth libaries").
I think this combination would make it easy to transform most applications 
(including black-box apps) to using Shibboleth.



Good luck, I'm looking forward to the eventual masterpiece!

-- Velpi