Shibboleth Developers

["Alistair Young" <>]

Here I am replying to my own mail!

There are two ends to the communication:

1) VLE (SPa) uses the delegation profile to get AuthenticationStatement it
can use for the VFS (SPb).

2) VFS asks the AA for more attributes.

Assuming the VLE can give the VFS the SecurityTokenReference and a SAML
Subject then the VFS has enough info to go back to the AA, independently
of the VLE, to get extra attributes for that SAML Subject.

What I'm not sure about is whether a SAML Subject, issued by an IdP is SP
specific, i.e. would the AA release attributes to the VFS based on a SAML
Subject it originally issued to the VLE?

Could the delegation profile of shibb help in this case to set up an
authentication session for the AA to recognise the VFS?

Goes without saying that the AA already knows about the VFS from it's
metadata so trusts it anyway.

The question for me is can SPa pass on a SAML Subject (possibly in a new
WS profile) to SPb and SPb use that SAML Subject to get attributes about
the Subject that are denied to SPa?

Alistair


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

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