Shibboleth Developers

[Chad La Joie <>]

Scott Cantor wrote:
> 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?

Certainly this is true for if you're comparing only the servlet and 
filter impls, it should be true for the a Tomcat realm too (as it's just 
HttpServletRequest/Response based too).  It's likely there would be some 
difference between those three and a programmatic interface.

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

Yeah, I have to say that I'm currently unable to view a set of clean 
APIs that could be provided.  Maybe I'll see something after I've coded 
some.

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

Actually even what it means for basic, digest, form, and client-cert is 
under defined and is no way portable across containersyep,.  The 
authentication part is but one part of the security constraint portion 
of the servlet spec.

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

Doesn't necessary have to be.  This approach could do both what you 
suggest and handle lazy session.  The app would just need to know when 
to issue a redirect to the servlet.

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

Yeah, neither this, nor the servlet based approach, relies on container 
or declarative security (for authentication).  Both will require 
declarative security statements to make sure that SSL is used.

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

I agree, but most people aren't writing their apps this way.  You're a 
special case, because of your experience, and have led people (correctly 
I think) to this model.

--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124