Shibboleth Developers

["Tom Scavo" <>]

On 6/19/06, Scott Cantor 
<>
 wrote:
> 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.

Or IdPA could simply pass the assertion from IdPB on through to the
original SP.  If we assume the SP trusts IdPA (not an unreasonable
assumption it seems), then no transformation is necessary.

> 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.

Even if the proxy is simply passing assertions on through to the
original SP, it needs most of the functionality of a full SP.  If the
proxy has local functionality as well (like myVocs), then a fully
featured SP is required.  In fact, even more is required, namely, the
ability to impersonate SPs.

Tom