Shibboleth Developers

["Alistair Young" <>]

> I would suggest not copying saml-dev on this, as it's a Shibboleth draft
oops, sorry! point taken

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.

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

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.

Alistair


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

>> I've been looking at the SSO with constrained delegation profile with an
>> eye on solving a problem we have.
>
> I would suggest not copying saml-dev on this, as it's a Shibboleth draft
> proposal at this stage, and is more likely to confuse anybody else. I
> shared
> the draft with the SAML TC, but saml-dev is not the TC.
>
>> This is fine, until the user in question has logged in to the VLE using
>> Shibboleth or similar, i.e. they are not a member of the VLE's home
>> institution.
>
> Yes, but that's the point of the profile.
>
>> In one scenario, the VLE could switch to ECP mode and just become a
>> passive router for attribute requests from the VFS to the user's IdP but
>> that means that potentially sensitive attribute information, destined
>> for
>> the VFS is going through the VLE.
>
> No, you'd just encrypt them, but I don't see the point of ECP here.
>
>> Another scenario would be the VLE passes the original <Response> it got
>> from the user's IdP after the initial <AuthnRequest> to the VFS and
>> tells
>> the VFS to get the required attributes directly from the IdP. That way
>> the
>> VLE isn't involved in the extra attribute exchange.
>
> You could just as easily encrypt data in the original assertion for the
> VLE,
> and then it would forward the assertion (NOT the response) to the VFS. Or
> you can supply an identifier in the assertion that the VFS can use to
> obtain
> more data. Encryption can be used to clearly scope the identifier for use
> by
> the VFS.
>
>> The constrained delegation profile doesn't seem to take into account
>> additional attribute requests by, in effect, SPb (the VFS), especially
>> when those attributes contain highly sensitive information which should
>> only be seen by the VFS.
>
> It's orthogonal to the profile. It is possible within the framework of the
> profile. People keep focusing on attributes. That's not the main focus
> here.
> Get the authentication flows and encryption right, and the attributes can
> get tacked on afterward.
>
>> Could the second scenario, of forwarding an <AuthnRequest>'s <Response>
>> to
>> the VFS and allowing the VFS to initiate an <AttributeRequest> be
>> viable?
>
> No, the Response message is not usable because WSS allows assertions to be
> attached, not SAML protocol messages. The assertion is usable if you
> implement something along the lines of the profile.
>
> -- Scott
>
>