Shibboleth Developers

["Scott Cantor" <>]

Peter Williams wrote on 2009-04-15:
> If the app can signal Shib SP to selectively perform multiple act of
> delegation (by "proper" means) on async bindings, this seems fine. Rather
> than the app having being responsible for controlling the distributed
trust,
> it simply asks Shib to "setup an onward channel" (using the standard
> profile(s) that enforce the standard, controlled, delegation model.)

All I'm saying is that doing it right requires care, and assertions can't
just be used to do delegation unless the IdP wants them to be and includes
the necessary support.

What you're doing when you delegate is using an assertion in combination
with the service's key to enable it to authenticate to the IdP as the user.
That's all, nothing more or less.

Pragmatically, the SP has little to do with any of this and its only
function at the moment is to make it possible for applications to get access
to the assertion and a few other details we're working out. It will not
initially go talking to the IdP for an application and handle all the token
exchanges. In theory it could do some of that, and it might someday.

> Just seems strange that the webSSO idp should have to know anything about
> domains/addressing/policies of the web service endpoints, first. While
> obviously the IDP should have a circle of trust that includes the web
> service providers, that a particular SP leverages a particular set of
> providers on any given transaction should not be known to or controlled by
> the IDP (or an upstream idp in idp-proxying)

That *doesn't* have to be known in advance, but the intent to exchange the
original assertion for a new one usable downstream does.

It's also possible to overload the original one with support for direct
forwarding/reuse, but *that* requires the prior knowledge you're talking
about, not to mention gets difficult in terms of privacy.

-- Scott