4

We currently have an Identity server 4 application. Using entity framework core and asp .net identity.

We have a group of supporters who need to be able to access our users accounts in order to help them with issues over the phone. Our users are not able to figure out how to use team viewer. As most of them are mobile and will only have a cellphone at the time.

I know all the security ramifications of allowing other people to sign into your account however there is really no way around this. Our customers have accepted that our supporters can connect to their account when they request it. We trust that our supporters only do this when its requested.

Current solution and its issues

The current hack creates an api endpoint which only our supporters can use as it has been locked down so that only those with supporter permission can use it. They send the users email and we hack create them an access token which is then used by the application (Web version) to act like its the user who is having issues.

This solution was created by my predecessor basically by taking the supporters access token and replacing all of the claims with this supporters id to the users id and returning it to the application. I hate this solution on a number of levels and its very unstable every time i look at this method it breaks. currently its not working because audience clams are incorrect for some reason.

What i want to do

I would really like to do this in a less hack way. So is there a way to sign in a user to the application without it actually being them thats doing the signing in and return an access token?

I have tried doing

await _signInManager.SignInAsync(user, false, null);

But i cant seam to figure out how to get that to return an access token.

What i would really like to do is have the ability for supporters to login to any ones account but do it securely somehow.

Community
  • 1
  • 1
Linda Lawton - DaImTo
  • 106,405
  • 32
  • 180
  • 449
  • Could I kindly ask you why you hate this solution ? I mean, if it is correctly coded and if it does not break. I could have another solution to provide, but I don't know if you will find it cleaner than what your predecessor already tried to do. – Skrface May 23 '19 at 11:50
  • I just find hacking an access token messy. I would rather go though the signin flow everything else uses and have that build the tokens for me properly rather thank hacky. – Linda Lawton - DaImTo May 23 '19 at 11:54
  • Part of my solution was going throw the signing flow too. It would also be an hack. However, the solution Ruard provided seems far greater than what I was about to propose. – Skrface May 23 '19 at 11:58

2 Answers2

3

The problem with the user account is that it's not bound to one application. So by allowing others to login using the account, you give them also access to other applications. As a workaround you could use 'public' accounts, like engineer_01, engineer_02, etc.

But, this may not be necessary at all. What you really want IMO is to impersonate the user, instead of 'hacking' the account.

One way to do this, is to extend IdentityServer with a custom grant type using extension grants.

How this could work:

A signed-in user, who is allowed to impersonate users for the particular client/resource, requests an access token at the new impersonation endpoint.

The user sends the sub from the user to impersonate to the endpoint, where the user and (combination of ) sub are verified.

When access is granted a new (short-lived) access token is returned which can be used to impersonate the user, without having to know the credentials of the user.

The access token should contain information of the endpoint so it can be determined whether the user is impersonated.

3

We implemented an impersonation feature that is integrated into the browser-based sign in flow. If a user with permission chooses to sign in as another user then we add additional claims to their IDS4 authentication cookie which then supports issuing extra claims in the resulting token that reflect that it's an impersonation session and who the original actor is.

  1. Navigate to client application
  2. Sign in using whatever credentials
  3. Check if any impersonation permissions exist (how these are defined is entirely up to you)
  4. Prompt for impersonation account selection (or just continue as self)
  5. Sign in as the selected account (with record of original actor)
  6. Redirect to authorize endpoint
  7. Issue tokens and redirect back to client application
mackie
  • 4,996
  • 1
  • 17
  • 17
  • This must be the answer as the subject was how to **sign in as another user**, not how to issue a bearer token with a different identity. I'm now about to implement something very similar. – d_f Jul 10 '19 at 12:47
  • How do you do step 5. "Sign in as the selected account (with record of original actor)"? Which mechanism do you use for this? – Pete Feb 23 '23 at 13:53
  • 1
    @Pete as in specifically what code? Ultimately you'll likely be using the normal ASP.Net cookie middleware so the mechanism is signing into the primary authentication cookie scheme with a set of claims that represent the impersonated user and also including additional info about the impersonator. Once done, when you redirect back to the authorize endpoint it will pick up the impersonated user's claims and issues tokens as it you were them. I'd recommend including additional info in said tokens so that client apps are aware that impersonation has been used (for audit logging etc). – mackie Feb 24 '23 at 16:49