shibboleth-dev - RE: Constrained delegation with additional attributes
Subject: Shibboleth Developers
List archive
- From: "Scott Cantor" <>
- To: <>, <>
- Subject: RE: Constrained delegation with additional attributes
- Date: Mon, 21 Nov 2005 17:23:44 -0500
- Organization: The Ohio State University
> 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
- Constrained delegation with additional attributes, Alistair Young, 11/21/2005
- RE: Constrained delegation with additional attributes, Scott Cantor, 11/21/2005
- RE: Constrained delegation with additional attributes, Alistair Young, 11/21/2005
- RE: Constrained delegation with additional attributes, Scott Cantor, 11/21/2005
- RE: Constrained delegation with additional attributes, Alistair Young, 11/22/2005
- RE: Constrained delegation with additional attributes, Alistair Young, 11/22/2005
- RE: Constrained delegation with additional attributes, Scott Cantor, 11/22/2005
- Re: Constrained delegation with additional attributes, Tom Scavo, 11/22/2005
- Re: Constrained delegation with additional attributes, Alistair Young, 11/22/2005
- RE: Constrained delegation with additional attributes, Scott Cantor, 11/22/2005
- RE: Constrained delegation with additional attributes, Alistair Young, 11/22/2005
- RE: Constrained delegation with additional attributes, Scott Cantor, 11/22/2005
- RE: Constrained delegation with additional attributes, Alistair Young, 11/22/2005
- RE: Constrained delegation with additional attributes, Alistair Young, 11/22/2005
- RE: Constrained delegation with additional attributes, Scott Cantor, 11/21/2005
- RE: Constrained delegation with additional attributes, Alistair Young, 11/21/2005
- RE: Constrained delegation with additional attributes, Scott Cantor, 11/21/2005
Archive powered by MHonArc 2.6.16.