7
  • In my web application, I'd like to allow super users to impersonate other users.

My Question:

Is there a generally accepted design pattern that I could use to make this happen?

  1. Generally speaking, I can imagine that I'll need to keep track of the current user and the impersonated user inside of the session.
  2. But you can understand that I'd like to minimize the complexity attached to this change.

  3. Incidentally, my application is an ASP.NET MVC 2 application, so if I could take advantage of any existing infrastructure, that would be great.

EDIT: I'm using Forms Authentication.

EDIT: I'll also need to track the fact that a super user is acting on behalf of another user. I'll need to do this for two reasons:

  1. Logging should log the fact that a super user acted on behalf of another user.
  2. It's conceivable that the super user would want to return to the impersonation screen to "switch context" and impersonate another user.

EDIT: @Jordão proposed a mostly workable solution. My only concern is the following - If the super user (while impersonating another user) navigates to the home screen, and the top of the screen says 'Hello [User]', I want it to say 'Hello [Impersonated User]' as opposed to 'Hello [Super User]'. And I'm afraid that @Jordão's solution would make the implementation of this screen and other screens with similar requirements more complex.

Community
  • 1
  • 1
Jim G.
  • 14,056
  • 19
  • 94
  • 153
  • 1
    Don't do this. It has security and privacy implications. You could even say it's unethical. – Jordão Feb 04 '11 at 18:26
  • @Jordão for intranet applications we do this all the time -- it's very helpful if someone is away or has been terminated to allow someone else to go in as them and take care of something in their queue. – Sean Feb 04 '11 at 18:30
  • 2
    @Jordao, there are tons of customer service scenarios where you *really* need to know what the customer is seeing. You can't just wag your finger at those business requirements. – Kirk Woll Feb 04 '11 at 18:31
  • Are your system users authenticated with AD? Or forms auth? Have a user object/identity sitting in Session? These will be important. – Sean Feb 04 '11 at 18:31
  • @Sean; @Kirk Woll: The solution to these problems is not to impersonate the users, but to give sufficient authorizations to the super users. – Jordão Feb 04 '11 at 18:32
  • Unless you're using a component that doesn't allow that. Or a user says "I'm seeing X, Y and Z" and you are simply not seeing that. Facebook has this functionality, by the way, so it's not like it's just nobodies doing this. – Sean Feb 04 '11 at 18:40
  • @Sean: The fact that others are doing this does not mean that it's right to do it. – Jordão Feb 04 '11 at 19:08
  • I really think that the requirement to show "Hello [Impersonated User]" is not right; _it's simply a lie_. If you really need this kind of information, use "Hello [Super User], you're currently seeing [Other User] data". – Jordão Feb 04 '11 at 19:12
  • @Jim G. What was your final solution? I am having a similar issue to solve. I am more curious to know, how did you handle the session object(s) after impersonation. What if the user impersonates multiple users, by opening different users in multiple browser tabs? – Numan Apr 17 '13 at 19:36
  • 1
    @Nauman: I actually followed Jordão's advice and urged management to consider another solution. Fortunately, we were able to sell them on the benefits of exclusive super-user interfaces. We emphasized that the impersonation feature would be extremely expensive and risky. – Jim G. Apr 18 '13 at 18:46
  • @JimG.: Thanks for the update. It still keeps me wondering, that even in that case, you must rely on session variables to keep track of which user the super-user is making modifications for? Or I am missing something? – Numan Apr 19 '13 at 10:58
  • @Nauman: I think you're right. But it gets messy really fast. And even if you get everything perfect the first time around, that sort of architecture will remain a risk for the lifetime of your application (if you continue to make modifications). – Jim G. Apr 19 '13 at 13:42
  • @JimG.: Totally agree with you, that is exactly the situation, I am in. And surprisingly, haven't found a known/proven pattern to handle this! On the lighter side, maybe it is time to invent one ;-) – Numan Apr 19 '13 at 14:01
  • @Nauman: Yes! Hence my original question. – Jim G. Apr 19 '13 at 18:52

2 Answers2

2

Don't impersonate other users, but give the super users enough authorizations and exclusive interfaces so that they can act on the other users' data.

If you then have logging or auditing data, you know which user (normal or super) acted on the data.

Jordão
  • 51,321
  • 12
  • 105
  • 132
0
[Authorize(Roles = "Admin")]
public ActionResult Impersonate(string username)
{
    FormsAuthentication.SignOut();
    var cookie = FormsAuthentication.GetAuthCookie(username, false);
    Response.AppendCookie(cookie);
    return RedirectToAction("index");
}
Darin Dimitrov
  • 960,118
  • 257
  • 3,196
  • 2,876
  • OK. And I suppose that you just need another field in session to track the fact that this is a super user acting on behalf of the user specified with username, correct? – Jim G. Feb 04 '11 at 18:32
  • @Jim G., this will depend on your requirements, whether you need to track such thing. – Darin Dimitrov Feb 04 '11 at 18:34