Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Wed, 2 Nov 2005, Jim Fox wrote:

> ...
>  2) If the SSOHandler realizes the user needs to be authenticated,
>     either by lack of cookie credentials or by a re-authn request
>     (the latter from eauth) it redirects the browser to either
>     ".../HSLogin?" or ".../HSRelogin?", both also handled by the
>     same SSOHandler.  The path "HSLogin" is protected by pubcookie.
>     The path "HSRelogin" is also protected by pubcookie, but with
>     apache directives specifying a forced reauthentication.
> ...
> My inference from the Shib 2.0 document is that is can support this
> sort of custom authn by redirection out of the box (nearly, at least).
> If so, extending the method to passive authn or logout seems not
> too much trouble.

The setup in (2) above deals with the equivalent of the SAML 2.0 
AuthnRequest ForceAuthn attribute, ie, go to /HSLogin if ForceAuthn is 
false (or absent), /HSRelogin if true.  But the AuthnRequest structure 
element has these elements/attributes in it that might affect how 
user authentication is handled:

  Subject
  NameIDPolicy
  Conditions
  RequestedAuthnContext
  Scoping
  IsPassive
  ProviderName

(I think all the other stuff is about how the response is handled, not 
about the authentication.)  And of course several of those are elements 
with potentially a great deal of complexity in them, RequestedAuthnContext 
in particular (25 authentication context classes are specified in the SAML 
2.0 saml-authn-context document, and some of these are complicated 
multi-element things in themselves ...).  Since several of these 
elements/attributes might appear together in a request, for each unique 
combination to be handled by a distinct location would require, I dunno, 
maybe a billion locations.  So if any significant number of these factors 
is to be handled by a non-built-in SSO scheme, I can't see any alternative 
but to pass the information to it rather than relying on distinct 
locations to be configured.

We can assume that the Shib 2.0 built-in SSO code will parse the 
AuthnRequest and invoke various classes that ultimately will control what 
page, if any, the user sees, what interaction it asks for, and what 
response is prepared to be returned to the requester.  I don't know that 
anyone has done much analysis into interactions among all the possible 
factors (the text for ForceAuthn mentions an interaction with IsPassive), 
but even without that this will be a complicated implementation.  In fact 
I don't think there's any way Shib 2.0 will support all this stuff, so 
we'll have to decide what it should support (where as always code 
contributions will be the best way to ensure something is supported).

In any case my point is that whatever built-in stuff Shib 2.0 does to 
handle AuthnRequests and do user authentication, it will be different than 
any of the webiso systems that people have deployed now.  None of those 
webisos handles SAML 2.0 AuthnRequests.  So if Shib 2.0 hands this 
function off to a non-built-in SSO scheme, the overall behavior will be 
different than if the site used Shib 2.0 natively.  Assuming Shib 2.0 does 
a halfway decent job of handling AuthnRequests, the non-built-in scheme 
will be only a subset of what Shib 2.0 can do (though of course it might 
be preferable to a site for other reasons despite this).

So here's the deal.  Shib 2.0 comes out.  The IdP has all this cool 
AuthnRequest stuff in it.  If the IdP doesn't have any provision for 
invoking a non-built-in scheme, then a site that has such a scheme (CAS, 
Pubcookie, A-Select, etc) already deployed has these choices:  (1) put the 
IdP behind local SSO just as they do now, and give up the AuthnRequest 
features; (2) deploy the Shib 2.0 native SSO alongside or instead of their 
existing one; (3) hack on the Shib 2.0 IdP to somehow call their existing 
scheme, obtaining a subset of AuthnRequest features.  So if Shib *did* 
have provision for invoking a non-built-in scheme, the difference would be 
that (3) would be a little easier; but it would still be a subset.

Would that subset be an acceptable subset?  Here is where things get 
really murky.  How much of all this AuthnRequest crap will actually get 
used by anyone?  Have your SPs been clamoring for the 
MobileOneFactorUnregistered authentication context class, or the ability 
to specify the saml:Conditions in the returned authentication assertion? 
Mine haven't.  In fact I would say that SPs in the classic 
multi-organizational arrangement that Shib was designed for (eg OCLC 
accepting campus users) are essentially never going to use any 
AuthnRequest features for a long time; all they want is plain old 
authentication (sure, US E-authn specifies a homemade ForceAuthn 
equivalent, but it's not clear to me that they test for it or that anyone 
expects to use it).  SPs that might use this stuff are IMHO much more 
likely to be closely associated with a particular IdP hence have more 
explicit expectations of its capabilities.

So maybe there really is an expedient subset of AuthnRequest factors that 
could be exposed via an API to an external-SSO provider, post-parsing of 
the full AuthnRequest by the Shib 2.0 IdP.  I suppose these might be 
ForceAuthn and IsPassive, maybe saml:Subject, maybe a set of authn context 
class URIs (so we can get our SecurId mode at UW).  If, say, CAS, 
Pubcookie, A-Select, and CoSign folks can agree on this, and agree to 
write handlers accepting these params and mapping them into functions of 
these systems, then maybe we can all get what we want.

 - RL "Bob"