Impersonation details - New feature request

[O'Dowd, Josh]

> No, because that's much riskier and more expansive than 99% of people would ever need.
> What I did was build an interceptor that obtains a list of authorized account names and directs it to re-reresolve the attribute set based on a selected account name *for a single response* to a service.
> The identity in the session never changes. It just passes out data for a different identity one request at a time, and you can plug in a function to return the list of authorized identities on a per-anything basis.

Thanks.  We do have a requirement where for a given service(in a development/testing environment), a developer or tester needs to impersonate different user types(i.e., student, advisor, etc.).  My solution was to implement a dedicated IdP that registers only the test/dev services.  The password login offers a checkbox for requested impersonation, where the user authenticates their own credentials and a group is checked for authorization to impersonate.  If authorized, the user gets an additional form to enter the impersonated ID.  This is all done in an extended password-authn-flow and then I am rebuilding the authentication result before declaring 'proceed'.

I wish I had thought of your solution, using an intercept to simply change the assertion, but I couldn't get my head around how to do the request-at-a time where an SSO session already exists.

While the solution I have works well for us, you are right that it is risky, no matter how much we audit and what security protocols we put in place for authorization.  I will likely try to apply this new feature to replace/rework my solution.

Josh