Skip to Content.
Sympa Menu

shibboleth-dev - RE: Constrained delegation with additional attributes

Subject: Shibboleth Developers

List archive

RE: Constrained delegation with additional attributes


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Cc: <>
  • Subject: RE: Constrained delegation with additional attributes
  • Date: Tue, 22 Nov 2005 10:24:54 -0500
  • Organization: The Ohio State University

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

An assertion, not a statement. What's in the assertion is not specified. It
could easily include attributes encrypted for SPb.

> 2) VFS asks the AA for more attributes.

Why? I'm not saying it can't, but why do we immediately have to go here?
Callbacks have a lot of drawbacks, starting with the fact that the user
can't give any real-time approval of the release.

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

Why make the problem harder? If you want to allow queries, you have to do
more work to get a usable identifier in the assertion and still protect
privacy. For one thing, SPb and IdP have to share an identifier, transient
or otherwise.

If you know up front that you want to supply information to SPb, just
encrypt it into the token in the first place. If you don't, then you
wouldn't know to create an identifier to be shared with SPb, so you're stuck
anyway. Instead, SPa has to go back to the IdP to get a fresh assertion
containing encrypted attributes for SPb.

There's no profile for that that doesn't slide all the way into WS-Trust,
which is why I'm reluctant to go there right off the bat. I did that token
profile strawman mostly to provoke reaction.

I'd much rather see how far people can get layering delegation on top of
SSO.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page