IdPv3 deliberate change of principal and shared principals

[Cantor, Scott]

> If and how SSO would operate in this scenario is one of many
> open questions.

I think it's best left as a totally orthogonal notion outside of the authentication layer, which leaves SSO able to function freely as it already does, purely as an authentication detail for the user doing the impersonating, not the one being impersonated.

> I looked in the wiki but did not see any existing support for
> this type of functionality. Have I missed it?

No. There is some support for changing the behavior of an identity switch, but that's after an actual login as a user that doesn't match a session.

> My first thought is that neither an intercept flow nor a
> subject canonicalization flow would be able to implement this
> type of functionality since it would most likely require
> "removing" the canonical principal or preventing it from
> really being "set" in the first place, and that a new
> authentication flow evolved from Password would be required.
> 
> Thoughts?

I think it's exactly an intercept, actually, and really comes down to fully documenting the contract between the authn flow and the rest of the system.

That said, post login intercepts run after attribute resolution, so it's likely that would need to be redone as part of the intercept, but that's not hard, and it allows for what I think you really want anyway: use the initial resolve to find out what the user can do, and then redo it in the context of the changed ID.

This is really more about documenting the currently undocumented mess of the context tree than anything else.

Bottom line, PLEASE keep this out of the login layer. That is more than complex enough and getting worse.

-- Scott