Where to hook in switching of user identity

[Cantor, Scott]

> Now I want to implement the user switching aspect, and I'm looking for
> guidance on how to integrate it.  In particular, I'm wondering if this
> function should logically be part of the authentication process (perhaps
> as a post-auth or output intercept), or part of the subject canonization
> process.

The "post login" interceptors aren't part of authentication, they run after it. Output intercepts are for final message manipulation (and there are virtually none at this point, it's just there for parity).

> I think I understand what I need to do to accomplish this (replacing the
> SubjectContext for the spoofer with the target), so it's more a question
> of where.

Not sure I have a full idea. There are probably session implications to this...

I don't know. I think I would try to avoid exiting the authn flow without having already made the switch, but I don't know what kind of SSO behavior you want.

If you want everything session related to be left alone (be the original user), maybe you'd want to do it in an interceptor but you'd have to be sure to blow up the AttributeContext that's already there and probably do your own work to replace it by wiring in a new call to resolve attributes.

If you do it as a c14n flow, that would flip the session to the target user and pretty much everything would just run as though that user logged in. But you're also talking about manipulating authentication methods...this is really low level stuff. It's not designed to do this.

The most conservative approach is with a login flow modified to do all this. The contract out of that is explicit and clean and the rest of the system will run the way it's meant to based on whatever comes out of that.

-- Scott