Shibboleth Developers

[Jim Fox <>]

> I guess to be pragmatic, there's a lot of stuff in Shibboleth because I
> really, really needed it. In some cases I did the work to make it happen,
> and in others, I leeched off Walter. ;-) But this one isn't important to me
> at all, so let's find some volunteers. I guess you and Jim are first up?

Our (UW's) present IdP works thusly (roughly):

  1) An authentication handler (SSOHandler in 1.3, SSODispatcher in 2.0)
     is invoked for all requests for ".../HS?", the normal browser
     entry point.  This path is not protected by any local SSO.

  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.

  3) When SSOHandler is invoked in one of the protected paths it has
     a remote user value, and thus can complete the shib login.


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.

Any other local SSO system that also works by Location style apache
directives should be able to be accomodated in a similar manner.

Jim