delegation in IDP3

Brent Putman putmanb at georgetown.edu
Tue Jul 26 17:45:48 EDT 2016



On 7/26/16 5:18 PM, Cantor, Scott wrote:
>> a Jira issue.
> Functionally speaking, yes, either we have to do that, or we need more flexibility in whether that check gets done by the decoder of the NameID.
>
> Policy-wise, I don't know what is "right" because I haven't thought about the policy implications here. If the presenter here is the SP to whom the transient was issued, then I guess that doesn't seem inappropriate that the IdP would be willing to decode it. But that's off the top of my head.
>

Hmmm, yeah. Good point about the policy implications.

I was just trying to determine if the presenter to the Liberty SSOS flow
is always the RP to whom the Assertion token's NameID was issued.  I
*think* it is, because on each trip through the Liberty SSOS profile the
new to-be-issued Assertion gets a new NameID generated from the resolved
and c14n-ed principal name.  Initially I thought that the original SSO
NameID was cloned each time and carried down through the whole
delegation chain.  But I can't find any evidence of that, and it sort of
doesn't make any sense.  I think the NameID generation part of the
Liberty SSOS flow is just doing what the standard SAML SSO flow does.  
So even for n-tier as opposed to the simple 1-tier, the assumption still
holds.  I think.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160726/0a62c788/attachment.html>


More information about the users mailing list