Shibboleth Developers

["Scott Cantor" <>]

Is it fair to say these options are basically orthogonal to the question of
how we implement actual SAML (or other protocol) processing? Meaning either
inline in the filter or servlet(s) would probably work, and it's just a
question of the configuration approach?

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

I'm biased by my own inability to envision this, but I don't think SAML
lends itself well to this design because it doesn't decorate URLs with a
self-contained "ticket" attachment that you can just pull off and process
via an API.

It has to deal with XML messages, POST, etc. as well as very complex request
options. I could easily imagine an API for initiating SSO, but there's no
real value to that when a simple redirect can accomplish the job (e.g. what
the current SP does). That beats maintaining API code for every langauge
(even Java) to me.

The API stragegy becomes more viable for people building proprietary SSO
gateways behind a SAML enabled site, because they can strip out all of what
SAML can do and turn things back into a simpler protocol. That should be
something we facilitate others to do, but not something we build initially.

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

Is this what you call the servlet spec's security constraint features? As I
understand it, that is part of the spec, but the way in which you might add
a login "type" besides basic, form, and client cert is not standard and is
container specific.

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

Again, trying to understand in my own terminology, is this roughly the
"protect the front door" approach many apps use? You have a dedicated
"login" app/resource and it just happens to be protected by SSO instead of
being a login form. The rest of the app is "naked" and relies on the servlet
session cookie?

My point, roughly, is that this integration model is possible to use
regardless of what else we do or don't do.

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

In effect, meaning we don't rely (at least exclusively) on integration with
the container to enable declarative security constraints, which would be
container specific?

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

Well, it's how pretty much every custom application on my campus works,
because I pushed hard for people to do it. Doesn't mean all the data they
use is handled that way, of course, just the non-local data.

My experience has been that applications developed in this way are the most
portable and adaptable to anything you throw at them. Every other technique
I'm aware of has a high degree of technical lock-in and separation of
concerns problems. In other words, to the minimal extent that Shibboleth or
systems like it encourage that style, everybody wins.

The advantage of an API is really quite specifically the ability to
integrate at the application level without root access to the site. That is
a non-issue with Java (which is also why Java has zero traction in the
hosted site space).

As I alluded to on the design call, I also think that it's a fantasy to
think that some other strategy for integration is somehow "cleaner" when
applied to packaged applications. Almost all web apps are so broken wrt to
authentication that anything you do ends up as a kludgy hack that limits
function and makes life hard for users. I don't think an API is a magic
bullet, far from it.

-- Scott