2

Together with IdentityServer 4, we've successfully implemented impersonation.

Implementation details

  • From our MVC application there are ACR values provided as "Impersonate:" while connection the IdentityServer.
  • At our IdentityServer there is a component, deriving from AuthorizeInteractionResponseGenerator. It filters the ACR-impersonate value and does a sign in with the provided userid.
  • After the sign in, it returns to the MVC application and a cookie is being set there.

This all works very well so far.

What do we want

For security reasons, we want add an extra claim actor to the token/cookie, which always tells that one is acting as someone else.

Challenge we are facing

At our MVC application, we are using refresh tokens to renew expired access tokens. The IdentityServer is being connected with providing a client id, client secret and the refresh token. The profile service at the IdentityServer isn't aware of the actor claim and provides only the regular claims.

How can we achieve that?

Peter
  • 743
  • 5
  • 26
  • Pardon me asking, but what is "ACR"? I have not come across the term anywhere while working with OIDC. – Dai Aug 24 '21 at 14:30
  • What is the lifetime of your `access_token` with impersonation? FWIW, when I implemented impersonation in my OIDC system using IdentityServer4 there wasn't any need to renew/refresh impersonated sessions (the default for human-users was 1 hour, which was long enough for every use-case of impersonation) - if you're doing impersonation for longer than that then you should look at supporting `delegation` grants instead. (If a 1-hour `access_token` lifetime seems long, it's okay because we had "live" session revocations) – Dai Aug 24 '21 at 14:48
  • You can implement your own IProfileService within IDS4. – GH DevOps Aug 24 '21 at 19:52
  • @Dai The "ACR" value variant for impersonation was recommended in some blog post by Brock Allen. Short description: https://identityserver4.readthedocs.io/en/latest/endpoints/authorize.html – Peter Aug 25 '21 at 06:32
  • @Dai You're absolutely right. We are also using default, 1-hour which should be far enough for doing all things demanded for impersonation. – Peter Aug 25 '21 at 06:34
  • Pardon me asking, how exactly do you sign in in the AuthorizeInteractionResponseGenerator component? I'm facing the same problem right now. – Pete Feb 08 '23 at 14:38
  • We are having our custom _ProfileService_ which implements _IProfileService_. There we're checking whether a request contains a specific claim type for that purpose. If yes, we add it to the requested claims of the context. Those are in turn being resolved by the `UserStore`. – Peter Feb 09 '23 at 08:49

0 Answers0