Shibboleth Developers

["Alistair Young" <>]

> That's old, there is no AuthorityBinding element anymore
oh dear! I got this from:
http://www.oasis-open.org/specs/index.php#wssprofilesv1.0
Is the SAML Token Profile deprecated now?

> this is *not* Shibboleth
I agree it's not shibb but it would be nice to have the notion of shibb
ARPs to preserve the user's privacy if so desired.

> An IdP can include as many encrypted sets
> of attributes for any SP it wants
I see what you're saying but it would have to release attributes for
multiple SPs in the same Response.

> 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
hmmm... I suppose the VLE would know which SPs it is capable of talking to
so could ask for a huge chunk of attributes from the start. Surely the IdP
would refuse though? The ARP would block release of VFS attributes to the
VLE.
I'm also not comfortable with sensitive attributes going through the VLE,
especially when it will never use them itself.

What's needed at the web service is, in old talk, is a
SecurityTokenReference and SAML Subject to allow the web service to go to
the AA and ask for extra attributes independently of the VLE.

The SAML Token profile was quite nice - pity it's gone, or is it?

Alistair


-- 
Alistair Young
Senior Software Engineer
UHI@Sabhal
 Mòr Ostaig
Isle of Skye
Scotland

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