impersonate users as an admin

[Umar-Mukhtar]

Which version of Duende IdentityServer are you using? 6.0 Which version of .NET are you using? 6.0 Describe the bug How can an admin impersonate other roles while logged into the application? How would tokens be exchanged and stored? As admin he should be able to obtain access to any user without having to know any credentials and switch back to his role at anytime. A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior.

Expected behavior Admin logged in as user. Admin clicks "login as customer" and now can see limited options as a customer. Admin can switch back to his role at any given time. A clear and concise description of what you expected to happen.

Log output/exception with stacktrace

data

Additional context How would tokens be managed in this scenario? Is it even possible using duende ids. Add any other context about the problem here.

[StuFrankish]

Bearing in mind, I'm not a member of Duende's team so I can't speak on their behalf, I still think there are a couple of points to raise here.

1. I think you're asking the wrong question of the wrong product. Your identity provider's responsibility ends once it creates a session and returns the user to the client application. It shouldn't be responsible for managing what happens within that client application, that's the clients problem.
2. Build your client application in such a way that allows your support / admin users to access the information they need, in a controlled & secure way, without resorting to impersonating a user.

I would consider any function to impersonate another user messy to develop/maintain (the audit logging alone would be a nightmare to keep track of) and a huge security risk. If one of your admin/support accounts is compromised, that is your entire userbase at risk.

[brockallen]

In addition to @StuFrankish's reply, what you're asking for is not part of the OAuth/OIDC specs, so that's not something IdentityServer does. Of course, you are building the token server using IdentityServer, so you could add that as a feature to your solution, but you would be responsible for coming up whit a design and implementation.

[Umar-Mukhtar]

What does impersonation refer to in the docs? please shed some light on the link below

https://docs.duendesoftware.com/identityserver/v6/tokens/extension_grants/token_exchange/

[Umar-Mukhtar]

Bearing in mind, I'm not a member of Duende's team so I can't speak on their behalf, I still think there are a couple of points to raise here.

1. I think you're asking the wrong question of the wrong product. Your identity provider's responsibility ends once it creates a session and returns the user to the client application. It shouldn't be responsible for managing what happens within that client application, that's the clients problem.
2. Build your client application in such a way that allows your support / admin users to access the information they need, in a controlled & secure way, without resorting to impersonating a user.

I would consider any function to impersonate another user messy to develop/maintain (the audit logging alone would be a nightmare to keep track of) and a huge security risk. If one of your admin/support accounts is compromised, that is your entire userbase at risk.

It's the client requirement that admin can impersonate as other roles in the application. As the system revolves around tokens for identity that was the sole purpose of asking this question here because it would require creating another token with in the same session for the user that needs to be impersonated and access api resources. Hope that clears the reason

[StuFrankish]

What does impersonation refer to in the docs? please shed some light on the link below https://docs.duendesoftware.com/identityserver/v6/tokens/extension_grants/token_exchange/

That does not relate to user impersonation. It means one system impersonating another. Specifically this section: https://docs.duendesoftware.com/identityserver/v6/tokens/extension_grants/token_exchange/#impersonation

In the impersonation use case, API 1 doing the token exchange becomes “invisible”. For API 2 it looks like as if the front end is doing a direct call.

So when the front end calls API 1 which calls API 2, API 2 sees that the client made the call, not API 1, even though the call came through API 1 - API 1 is impersonating the client.

It's the client requirement that admin can impersonate as other roles in the application. As the system revolves around tokens for identity that was the sole purpose of asking this question here because it would require creating another token with in the same session for the user that needs to be impersonated and access api resources. Hope that clears the reason

Regardless of why - as @brockallen has said, user impersonation is not part of the spec and therefore not part of Identity Server. If you want to impersonate a user, then you will need to find a way of handling that scenario yourself.

[mr-davidc]

@Umar-Mukhtar Did you ever end up getting a solution working ?