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: RE: [saml-dev] Question concerning linking of principals


> Problem: a Relying Party wants to query some attributes for a principal
> (call him principal B) that has some association with a principal (call
> him principal A) that the RP already holds a Name ID for.
> 
> Would an appropriate solution be for Principal A to have some attributes
> that gives Principal B's NameID and SAML attribute authority? The RP
> requests these attributes, using Principal A's NameID, and then does a
> second attribute request using these NameID and AA values? Are there any
> other approaches to this?

As Conor said, there are lot of subtleties to it. But for a basic linking
use case, I believe the People Service isn't needed. A profile of ID-WSF on
top of SAML attribute query can do the job, by using the original IdP to
supply, as you say, a NameID and endpoint to use.

This is all defined by ID-WSF because it includes the notion of an EPR based
on WS-Addressing that can both point to the second attribute source and also
provide a security token for the SP to use in its query.

This token would have an EncryptedID in it that identifies principal B (but
doesn't reveal that to the SP, since it's private to the two IdPs).

This gives you privacy, control over both linking and attribute release, and
proof of presence to make queries without having to just hand over the
second NameID.

The EPR itself could be supplied during SSO in an attribute or be asked for
after the fact by the SP.

You can also repeat it as needed to aggregate across as many sources as you
need, including crosswalks that wouldn't all centralize at the first IdP.

-- Scott




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