[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 institution. 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 -- Alistair Young Senior Software Engineer UHI@Sabhal Mòr Ostaig Isle of Skye Scotland
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]