Shibboleth Developers

["Scott Cantor" <>]

> Am I on the right path thinking that the authn process starting
> with shib 1.3 might go something like this:
> 
>   HS request is direct to tomcat - no apache up front.

More precisely, no authentication up front to the SSO service (let's dump
the HS name). Whether Apache is involved just depends on the deployment
(might be Apache + jk, might be Tomcat).

>   HandleServlet's doGet method parses the request and invokes a
>   site-dependent LoginServer's checkLogin (e.g.) method, which
>   implements some sort of site-dependent login.  The HandleServlet
>   provides the request's parameters through some structure or class.

These are just my thoughts...

I think the SSO service would probably process the request and then invoke a
plugin based on the various request properties, e.g. a JAAS-style cascade of
plugin modules with properties that tell the service whether they support
IsPassive, ForceAuthn, what AuthnContext they map to, etc. Might even be
JAAS, but I don't think it's sufficient.

For some of us, those modules will directly handle authentication and user
session management for SSO. For people that want to translate the request
into an alternative form and invoke a different and/or non-Java
authentication service, they could write a fairly small amount of Java to do
this (I assume, I still don't know what one of these looks like, exactly) or
just have it redirect to a non-Java resource of some sort, which brings
Apache back into the picture.

At some point, control has to get transferred to another servlet endpoint
that is the actual SAML Authn Authority and that is authenticated.

The part I haven't figured out is how that transition works. I guess one way
is to have the login modules create a Java object in the container session
that would contain the identity to be used by the AA. But that puts the
security at the mercy of Java sessions, and they aren't secure. I guess a
simple mapping of an alternative session identifier/cookie to the identity
object could be built in.

> Since Bob was the "main one beating the drum for this" it would be
> kinda tragic if pubcookie wasn't ready to go right from the start.
> Pubcookie doesn't right now do any java.  I'd like to get moving
> toward the new and improved login as soon as possible.

Problem being we just deferred the work. I don't know if we have the cycles
to fully design this. I could be way off or missing something obvious.

-- Scott