OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Constrained delegation with additional attributes

I've been looking at the SSO with constrained delegation profile with an
eye on solving a problem we have.

The scenario is this. A VLE uses WS-Security conversations to invoke a web
service on a remote virtual filesystem (VFS) on behalf of a particular VLE
user, who is logged in to the VLE. The VLE sends the remote service
authentication info about the VLE and the user's attributes, to allow the
remote service to make an authorization decision on whether that user can
upload a file to the VFS.

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

That user now wants to upload a file to the same VFS using the same
mechanism but they are trying to access an area of the VFS that is highly
protected and requires additional attributes to gain access. Those
attributes can only come from the user's home institution and not the VLE.

The VLE has to somehow get those extra attributes from the user's IdP but
that's not allowed as the IdP will only release those attributes to the
VFS' SP (the web service).

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.

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.

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.

Could the second scenario, of forwarding an <AuthnRequest>'s <Response> to
the VFS and allowing the VFS to initiate an <AttributeRequest> be viable?
The VLE couldn't do it as it wouldn't get the attributes the VFS requires.
Only the VFS can do that.

thanks for reading this overlong question!


Alistair Young
Senior Software Engineer
UHI@Sabhal Mr Ostaig
Isle of Skye

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]