Shibboleth Developers

["Scott Cantor" <>]

> Note that the passthrough to the Authentication Handler in Shib 2.0 could 
> invoke some other web signon scheme (pubcookie, CAS, etc); the difference 
> being that these schemes would not receive or do any processing of the 
> SAML AuthnRequest info (like a SAML signon system that is being proxied-to

> would).

Well, in effect, proxying (formally anyway) means there's a second
AuthnRequest between the proxy (call it IdPA) and IdPB because SSO is a two
party (plus browser) protocol.

The original AuthnRequest can constrain the number of additional hops or
IdPs, and the "handler" in Shib 2.0 would itself be issuing an AuthnRequest
of its own after processing the original, and then presumably it would be
picking up the assertion from IdPB and transforming/mapping it into a new
assertion for the SP.

An open question is how much SP functionality such a proxy would need. With
the Java SP, presumably pieces of it could be embedded, but configuration
obviously starts to get pretty complex once you combine roles like that.
It's not impossible to imagine just implementing it by sticking the full SP
in front of the authentication handler that supports proxying. But maybe
not.

-- Scott