User Impersonation in Duende IdentityServer

Question

I am aware the user impersonation question has already been asked several times. Unfortunately, none of the questions I read so far provided a reproducible guideline or overall concept how to do this in a secure way. Since every action needs to be logged, I can't use a hack to do this.

For that reason, I would like to kindly ask the community once again for advice and sanity check of my own ideas. Also, new approach suggestions are warmly welcome.

The questions I read so far include:

• IdentityServer4 - How to Implement Impersonation
• Allow supporter to sign in as another user
• Impersonate with IdentityServer, with having an actor claim for the impersonated user
• Identityserver3 - User Impersonation

Introduction

Basically, I have an ASP.NET Core Razor Pages app and an ASP.NET Core Web API, both protected by Duende IdentityServer.

Support Engineers need to be able to impersonate customers for service reasons ONLY after the customer consented to impersonation. Basic work flow:

• in the Razor Pages app, the customer activates "Grant Impersonation Permission" under his/her personal settings
• impersonation permissions are valid for a maximum of 7 days
• customers can revoke impersonation permissions at any time
• Support Engineers are then able to log in as any customer that granted impersonation permission at the back office (without the customer being present, no remote-desktop style)

Approach 1:

When the customer grants permission, use the Token Exchange mechanism to exchange for a new access token with a life time of 7 days. Store this token in a database in IdentityServer and allow only Support Engineers to get a customer's access token via a Controller using the customer's ID, name etc.

While this would work, I'm not comfortable with the idea of storing long-lived access tokens.

Approach 2:

When a Support Engineer logs in, based on his identity, show a custom consent screen where customers can be selected for impersonation and then log in as the selected customer. The Support Engineer would then get the access token as well as the ID token.

The biggest problem is:

Are there any extension points/mechanisms in IdentityServer to be hooked-in to control the sign-in process to kind of turn the sign-in process to log in the customer instead of the Support Engineer? Is even possible to do this in IdentityServer?

Approach 3:

In Allow supporter to sign in as another user, user mackie pointed out a high-level view of a impersonation feature. Here are the steps:

1. Navigate to client application Sign in using whatever credentials
2. Check if any impersonation permissions exist (how these are defined is entirely up to you)
3. Prompt for impersonation account selection (or just continue as self)
4. Sign in as the selected account (with record of original actor)
5. Redirect to authorize endpoint
6. Issue tokens and redirect back to client application

How are steps 4. to 6. done in practice? Any suggestions on that?

Answer 1

I have a question about the problem in your Approach 2. The essence of user impersonation is actually to use "pseudo-token" to impersonate a user to verify some operations or permissions. Or maybe you just want to log all actions performed by the impersonated user?

I think maybe you can intercept on login like in this link. But I think it may be better to add some specific identification to it when the interception is successful, instead of directly using the user's information to log in. I think logging in the customer instead of the Support Engineer might not be a user impersonation anymore (just a personal opinion).

In addition, acr_values is mentioned in the link you provided. From your description, acr_values seems to have some fit:

acr_values allows passing in additional authentication related information - identityserver special cases the following proprietary acr_values:

idp:name_of_idp bypasses the login/home realm screen and forwards the user directly to the selected identity provider (if allowed per client configuration)

tenant:name_of_tenant can be used to pass a tenant name to the login UI

For the usage of acr_values, you can refer to this link.

Other link:Impersonation workflow.

This is just my understanding and a suggestion, if I have any understanding wrong, please correct it.