Web Applications: Allowing super users to impersonate other users - Is there a design pattern for this?
T

2

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.

Thermotherapy answered 4/2, 2011 at 18:25 Comment(14)
Don't do this. It has security and privacy implications. You could even say it's unethical.Melloney
@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.Cotswolds
@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.Damnatory
Are your system users authenticated with AD? Or forms auth? Have a user object/identity sitting in Session? These will be important.Cotswolds
@Sean; @Kirk Woll: The solution to these problems is not to impersonate the users, but to give sufficient authorizations to the super users.Melloney
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.Cotswolds
@Sean: The fact that others are doing this does not mean that it's right to do it.Melloney
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".Melloney
@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?Boisvert
@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.Thermotherapy
@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?Boisvert
@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).Thermotherapy
@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 ;-)Boisvert
@Nauman: Yes! Hence my original question.Thermotherapy
S
3

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.

Syncopate answered 4/2, 2011 at 18:34 Comment(0)
W
0
[Authorize(Roles = "Admin")]
public ActionResult Impersonate(string username)
{
    FormsAuthentication.SignOut();
    var cookie = FormsAuthentication.GetAuthCookie(username, false);
    Response.AppendCookie(cookie);
    return RedirectToAction("index");
}
Wildman answered 4/2, 2011 at 18:30 Comment(2)
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?Thermotherapy
@Jim G., this will depend on your requirements, whether you need to track such thing.Wildman

© 2022 - 2024 — McMap. All rights reserved.