Shibboleth Developers

["Scott Cantor" <>]

> I've also had a look at the WS-Security SAML Token profile and it seems
> that the AuthorityBinding could be used for the VFS to get the location of
> the AA to ask for attributes that the IdP will only release to the VFS.
> Thus completely bypassing the VLE.

That's old, there is no AuthorityBinding element anymore. Metadata addresses
this, there's no need for it be in-band.

> What I'm not quite sure about is what the IdP would do if it got a request
> from the VFS for attributes.

Same as it would for any other request. Either you share an identifier for
the user or you don't.

> The point here is that the VLE can pass on attributes to the VFS that it
> originally got from the IdP but it can't get extra attributes that VFS
> needs as the IdP's ARP won't allow it to release them to the VLE, only the
> VFS. So the VFS has to get them, independently of the VLE.

ARPs are an implementation detail and have nothing much to do with this, as
this is *not* Shibboleth anyway. An IdP can include as many encrypted sets
of attributes for any SP it wants. There is no need for attribute queries in
many, if not most, use cases, and queries have a lot of drawbacks, such as a
lack of clear proof of presence of the user at the SP when using long-lived
identifiers. Although this can be obviated by requiring the authentication
assertion be attached to the query.

The real issue is whether you know up front what the possible delegation
scenarios are going to be when you sign on to a web site. If you do, just
include it all up front in the token and everything is much simpler.

-- Scott