CODEWITHSUNDEEP
c#asp.netasp.net-mvc-5asp.net-identity
David Dury
David Dury

Reputation: 5717

ASP.NET MVC 5 Membership impersonate specific user

There are many examples about impersonating a user in c# but the thing is you have to provide the domain, username and password of that user.

What I need is a bit different. If we build an app in ASP.NET MVC 5 using membership, let's assume we have the following roles in place:

and users whom belong to different roles.

Now if a user from role User has some issues with the application, how can I allow a user from Admin role to impersonate that specific user, without that specific user to give the Admin his username and password?

The main thing is that the Admin should be able to impersonate any user from the application and be able to browse the application as the user himself.

Is this possible to achieve in MVC?

There are many applications out there that offer this possibility, one of them is Salesforce. And Admin in Salesforce can impersonate any user, and browse/see the application as the user himself. This will allow them to identify and solve possible problems in the application.

Upvotes: 13

Views: 6997

Answers (3)

Devin Prejean
Devin Prejean

Reputation: 626

All I do is pass the current user id in a session and read the session throughout the application. If the current logged in user is different from the session object I know impersonation is going on. I set all this in the global.asax file on session start. Seems to work great for my apps.

Upvotes: 0

danludwig
danludwig

Reputation: 47375

Now if a user from role User has some issues with the application, how can I allow a user from Admin role to impersonate that specific user, without that specific user to give the Admin his username and password? ...Is this possible to achieve in MVC?

This can be accomplished without knowing the password of the user to be impersonated, but you do have to know the username of the user to be impersonated.

You can do this with the following using normal Forms Authentication:

FormsAuthentication.SetAuthCookie("username-to-be-impersonated", false);

Of course you would want to protect the entry to this block of code, so that only admins can do the impersonation. You will probably want to do something else like save the admin user's username in session or cookie to help the system know that an impersonation is in progress, and give the user the ability to reverse it when they are done impersonating.

Bottom line is, all the membership system cares about is the auth cookie, and you can write an auth cookie for any username without knowing the user's password.

The process is the same for ASP.NET Identity 2, the difference is just how you write the auth cookie. Note the code below is a snippet based on the comment that @trailmax left in the OP:

// assume you already have references to a UserManager and HttpContext
var userToImpersonate = await userManager
    .FindByNameAsync(userNameToImpersonate);
var identityToImpersonate = await userManager
    .CreateIdentityAsync(userToImpersonate,   
        DefaultAuthenticationTypes.ApplicationCookie);
var authenticationManager = httpContext.GetOwinContext().Authentication;
authenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie);
authenticationManager.SignIn(new AuthenticationProperties()
{
    IsPersistent = false
}, identityToImpersonate);

You should also have a policy that allows you to somehow get the user's permission before having an admin impersonate their account.

Upvotes: 10

James Gaunt
James Gaunt

Reputation: 14783

I don't think the solution lies in the membership system itself. I would probably implement the impersonation within the application logic. The membership system tells you the identity of the user and what roles they have, but your application is free to ignore or interpret those roles as you like.

EDIT: To elaborate...

You can look at this not as an issue with membership but simply as a set of features built into the application. An administrator has the ability to see what a user sees simply by being an administrator - this is build into the application logic.

Trying to hack this feature into the membership system so the application is somehow fooled into treating the administrator as a different member seems hacky - and any abuse of the membership system is going to open up security holes.

If you really wanted to go down this route perhaps you should look at giving administrators short term tokens tied to their IP address for say 10 mins that let them login as anyone - again this isn't tied to membership - it's tied to password checking which you can factor out.

So I'm not really giving a solution here - just suggesting that it's not to be found in hacking the underlying membership system. If you do this then you weaken the security of the membership system but you also limit what you can achieve. For example maybe you want to show administrators what users see + some extra information for diagnostics - if the application thinks the administrator is a user how would this work?

Upvotes: 3

Related Questions