Ory Hydra & Impersonation

[dm17]

Someone who seems like an Ory dev posted a hypothetical solution here:
https://community.ory.sh/t/how-to-implement-account-user-impersonation-in-ory-hydra/2050/2

The only modern auth/identity provider that seems to support this officially is Authentik:
You can quickly edit, deactivate, or even impersonate a user profile, and set a new password for new users or reset an existing password.

• https://goauthentik.io/docs/

It seems like an important feature that doesn't need to be enabled across the board in order to be available for Ory users (especially considering KeyCloak is a competitor, which is the standard recommendation for those needing impersonation).

So the first question is: perhaps someone has implemented or better documented what hackerman (above) has described? If not, then do you know why they think it is too big of a security risk to even provide a demonstration of an impersonation feature using Ory Hydra?

I figured it would be skillful to ask here considering the Ory forum (above) is in read-only mode - and I'm not sure how long its been that way.

[dm17]

To those still looking, it seems zitadel has gained interest in helping in this area of being an auth service provider: zitadel/zitadel#6006

[vinckr]

To reiterate an earlier point, there is a reason why few identity providers implement direct impersonation because its complex and easy to get wrong:

Regarding use cases, I think t his should be based on demand and not "could be useful" :) Impersonation is very dangerous, and adding it needs to be rooted in a concrete and useful way that can not be achieved otherwise, specifically:

• Support impersonation: Your support staff should have a dedicated screen for account management and support. Impersonation is not useful if the user wants to "show you" something that is broken (i.e. due to some browser plugin). Here you need screen share, not impersonation.
• Multiple profile: This is achieved through account switching (see Google Login)
• Two accounts: Open two private browser windows
• Anonymous: This is actually a nice feature but does not need impersonation. Instead it would be cool to issue temporary IDs. Maybe we can figure something out here!

The use case for impersonation is almost always support impersonation in my experience.
In most cases you can solve it well by copying over the permission set of the user you want to impersonate. But it depends of course on the details of the use case.

What use case did you have in mind when opening this discussion @dm17 ?

[aeneasr]

In my view, impersonation is easy to pull of with Ory, because you have full control over the user ID and token payloads in the consent flow:

1. Initiate OAuth2 normal, add an additional parameter like impersonate=userID to the URL
2. In the login/consent app, check for that parameter. Let the user log in with their admin account, and then grant/deny the impersonation request based on some permission or dialogue or whatever.
3. Either set the subject payload to the impersonated ID, or
4. If you want to be more secure, set subject to the admin user id and add another claim like "impersonated_user":"the-user".
5. Handle impersonation in your app securely.

The problem Zitadel and others have is that you. can't just integrate Ory into your existing stack. With competing products, a flow described like above is simply not possible because you don't have control over the login and consent step. With Ory you do, and as you see it's not magic to implement.

Hope this helps and also explains why Ory is better than competing products!

[fforootd]

While I usually do not join in discussion in others forum, I feel the urge to clarify some things here 😁

With competing products, a flow described like above is simply not possible because you don't have control over the login and consent step.

I guess you rely on outdated information for this 😢
With ZITADELs session-api people can build their own login/register/consent UI

On the subject of "impersonation", as @dm17 points out, we are in the process of finishing the exact implementation of impersonation. It is safe to say that we will support this on our APIs as well as with standard APIs - RFC 8693 aka OAuth Token Exchange - which is already supported in zitadel/oidc