Shibboleth Developers

[Nathan Dors <>]

This is good stuff. Will it be expanded into another draft 
document?

Many homebrewed web SSO systems have their own AuthN request 
formats and dispatcher mechanisms to effect different modes of 
authentication. I'd like to get my head around that use case.

In Pubcookie, for example, the login server unbundles Pubcookie 
AuthN requests and decides which login "flavor" should handle it. 
Some sites just use the basic userid/password flavor. Other sites 
have added additional flavors for SecurID, PKI, etc. Each flavor 
can decide what to do about re-authentication; it's just a 
parameter. (In Pubcookie, it's also "variable", meaning re-auth 
can depend on how long it's been since the user last 
authenticated, but don't let that sidetrack us here.)

I know Jim Fox has done some thinking about this use case here, 
but my basic question is whether you're thinking that the SSO 
dispatcher servlet would most likely dispatch to a *single*, say, 
Pubcookie AuthN handler or if it would dispatch to *several* AuthN 
handlers, one for each Pubcookie login flavor. It's okay to say 
you don't know. Maybe either route could work. It would seem to 
depend somewhat on how much of the SAML AuthN request (namely, the 
AuthN type and re-authentication status) is available to each 
AuthN Handler. So maybe that could be fleshed out some more.

Thanks,
Nathan

On Mon, 24 Oct 2005, Chad La Joie wrote:

> Yeah, I was supposed to do a write up on this but got busy with other things 
> and forgot.  So, let me give you an overview of the web-based mechanism, 
> because it's actually possible to explain that one and then I'll explain in 
> broad terms what you'd do for non-web SSO endpoints. Note the ordering of 
> some of these steps is not exactly how I'd code them, but I'm giving them in 
> this order, here, to hopefully make the explanation clearer.
>
> To start with, there with be an SSO dispatcher servlet that servers as the 
> entrance SSO process for browser based systems.  This class is mainly 
> responsible for two things.  First, it's responsible for figuring out what 
> AuthN mechanism to use.  In SAML2 service providers can send a list of AuthN 
> types and say something like "Pick the greatest of these that you, IdP, can 
> do".  Once that is determined is can read the SAML AuthN request to see if 
> the SP is requiring re-authentication (another new feature in SAML 2).
>
> Now the dispatcher needs to decide whether to actually authenticate you.  If 
> the SP require re-auth then the decision is made.  If not, the Dispatcher 
> will check to see if you've already been authenticated with one of the AuthN 
> mechanism that would fit the SP's request.  For example, if you've 
> authenticated with an end user cert and the request from the SP require 
> userid/password or PKI, then you'd be good and wouldn't need to to re-auth. 
> The, obviously, the last case is if you haven't authenticated with a 
> mechanism that satisfies the SP's requirements (either because this is your 
> initial log in, or you just haven't done the right thing yet) you'll be asked 
> to authenticate.
>
> Authentication will be performed by an AuthN Handler, which is nothing more 
> than an HTTP servlet in the browser-based use case.  The IdP will have a 
> mapping from AuthN mechanisms, which are identified by URIs in SAML2, to 
> AuthN Handlers.  Once the Dispatcher figures out what AuthN method to use it 
> just forwards the servlet request to the AuthN Handler, transferring control 
> to the handler.  If you've been thinking the Dispatcher was like the 
> IdPResponder in the current Shib code, you're right, but this is the main 
> difference.  The Dispatcher actually transfers control of the request to the 
> Handler not just invokes it.
>
> At this point the Authn Handler will "do it's thing", and that thing will be 
> different for each authn method.  If it's a userid/passwd it'll probably 
> present a form, if it's client cert auth the AuthN Handler will be client 
> cert auth protected.  Because the Handler has control of the request, it can 
> go back and forth with the client however many times it needs to.  These 
> Handlers will extend a base Handler class that will "take care of things" 
> after the authentication is done.  This mostly means recording what type of 
> authentication happened, when it happened, and which service it happened 
> with.  This info is needed for the single log out.  Then the base Handler 
> will construct the SAML response and send the user on their way.  And that's 
> browser based AuthN, in a nutshell.
>
> Now, I know you're a smart guy, so you probably looked and said, we'll that 
> will work for stuff other than browsers, and you're right.  It's just HTTP. 
> So, a non-browser client could use this mechanism just as easily as a 
> browser, and I suspect that'll work for a modest number of clients.  If, 
> however, you want something different, maybe SOAP with some number of other 
> standard (WS* for example) then you may want to do something different.  At 
> that point you'd define another endpoint that would be used instead of the 
> Dispatcher and do authentication that way.  All the code for figuring out the 
> right authn method, recording session information, forming the SAML response 
> and what not will not live in the Dispatcher and Handler servlets so you'll 
> be able to use lots of that stuff, hopefully.  This is obviously a more 
> complicated route but if I can do the coding correctly, hopefully it won't be 
> to hideous.
>
> Tom Scavo wrote:
> > Currently, local authN/SSO sits in front of the IdP.  At the I2MM WG
> > session in Sep, it was noted that the architecture of the IdP must
> > change to accommodate passive authN in SAML 2.0, which makes total
> > sense.  No details were given, however.  Could someone elaborate?  If
> > the IdP subsumes the authN step, what plugin mechanism will it use to
> > support a variety of local authN services?
> >
> > Thanks,
> > Tom
>
> --
> Chad La Joie             315Q St. Mary's Hall
> OIS-Middleware           202.687.0124