delegation in IDP3

[Cantor, Scott]

> For purposes of note taking and the dev team: I think during Assertion
> Subject c14n the SubjectCanonicalizationContext#requesterId in this case
> needs to hold the entityID of the RP to whom the transient/persistent was
> issued.  Correct?  But right now in ProcessDelegatedAssertion it's doing what
> the original regular c14n action code from which it was copied does:
> c14n.setRequesterId(requesterLookupStrategy.apply(profileRequestContex
> t)).  And I think that's wrong, it should be (somehow) obtaining the entityID
> of the RP to whom the NameID was originally issued and use that as the c14n
> context requesterId.  Scott/Tom/Rod: does this sound correct?  If so I'll open
> 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.

i.e. I know why it's failing, I don't know if it should fail.

> Assuming a bug: As far as a temporary workaround, I know that this all works
> for cases where the NameID isn't pairwise with an RP and doesn't need to be
> "reversed", e.g. where it's a "direct" transform, like unspecified (i.e with the
> principal name), emailAddress, etc.  So you could configure the IdP to issue
> Assertions with one of those sorts of NameIDs to the initial SSO SP, and that
> would I think avoid the problem.

Per my suggestion, yes.

-- Scott