0

I am building an intranet web app with ASP.NET. We are using Windows authentication for granting access to different web pages. We grab your Windows login server side, then build web pages accordingly. I have a need for a group of tech users to be able to impersonate business users so that the tech users can see the same page the business user sees and confirm that the app is correctly configured for the business user. Is there a good pattern to use for this? We are talking about seeing payroll data for different departments. SSL is not an option here (long story).

My server side language, where I get the Windows login, is C#. I am using jquery on the client side for manipulating the DOM.

In response to Flater's really good points: I'm trying to come up with a way for a business user, who would be a member of a support team, to be able to see the same thing an end user sees in their browser for this one web app. I'm not trying to fool Windows that I am someone else for all things. So I am looking at building something into my web page that allows the business user to pick an end user from a list of names, then pass that login name along to the web server and have the web server render a page with the info the end user should see. In the past, I have done this with a config file or database record; that's fine for devs but not so much for business users. Since all our permissions are based on AD groups, I think the best solution would be to show a separate list of AD groups of which the user is a member, then show a matrix of what the web server should be rendering for that user.

  • why the C# tag? I don't see any connection to C#? Same with the JQuery tag? – esoterik May 30 '18 at 18:09
  • 1
    Is impersonation even the correct solution to your problem; it seems like over kill to verify configurations, shouldn't the the tech user group have different abilities and permissions, enough to verify but not look at sensitive data? – esoterik May 30 '18 at 18:13
  • Does your system has Users, Profiles, Account data model? Only Users? Only Accounts? None of them? Looks to me you need to segregate the concept "Account" (security, access, authorization, etc) from "User" (session, business rules, etc). While most of the Accounts will only be bound/linked to a single User, Accounts with special Profiles will be able to switch the User in session. You have two concerns to keep separated who really I'm and who I'm impersonating to. – Laiv May 31 '18 at 6:56
  • Have you tried to run the browser as the desired user? – Flater May 31 '18 at 14:42
  • I've done this sort of thing before using a "membership factory" that is responsible for logging a user in via AD, or just faking it. Faking it was a config setting, coupled with a compiler flag and a system environment variable on the server, and as one last final check, a white list of host names. Looking back at it, I think I would go with separating the Account from the User. It actually might have been easier. – Greg Burghardt May 31 '18 at 15:18
3

Update to your update.

So I am looking at building something into my web page that allows the business user to pick an end user from a list of names, then pass that login name along to the web server and have the web server render a page with the info the end user should see.

The issue here is that your backend is currently set up to take a Windows identity. Windows identities for an IIS app should not be configurable from the client's side, as that is granting an obvious backdoor for malicious clients.

There are several ways to approach this without compromising the backend's current authentication setup:

  • On the client computer, you run the browser under the desired user's account.
    • Go to the browser .exe
    • Shift + right click it
    • Select "Run as different user" and log in with his credentials (this obviously requires knowing their password).
    • This browser should correctly send the chosen user's credentials to the backend server.
  • On the backend IIS configuration, you can set the app pool to impersonate a user. Note that this affects all requests. This is an easy approach if you're e.g. debugging locally, but you should obviously never do this on production (or any environment with multiple concurrent users).
    • You can find this in the advanced settings of the app pool.
    • This also requires knowing the user's password.

Needing the user's password is a recurring feature here, for good reason. No one except the user is allowed to perform actions on the user's behalf. Even those with more rights than the user can still not pretend to be the user (in Windows' internal security, at least).

However, I'm still on the fence whether impersonating the user is a good approach. It seems like an overzealous approach. If there's any auditing on the application (which I would expect from a payroll application), then a developer is effectively able to hide his actions.
What's stopping a developer from pretending to be someone else and possibly updating the payroll data? If they can choose to be whoever they are, then you're giving them the keys to the castle.

A better approach would be to retain the user's actual identity, but mock their settings. That way, you still get the same mocked output, without messing with any audit security. You mention different departments, so I'll assume that this is the setting you want to mock.

  • Give your developers a special privilege in AD or assign them to a special group (e.g. CAN_MOCK_DEPARTMENT)
  • The backend renders an additional "select your department" dropdown list on the webpage if the current user is part of the CAN_MOCK_DEPARTMENT privilege/group.
  • When such a developer sends a request to the backend, instead of taking the current user's department; the backend will use the value of the "select your department" dropdown. For all other users, the backend will always use their actual department.
  • Make sure that the backend doesn't rely on the department dropdown for non-developer users! A clever user can change this dropdown's value even if it is disabled (via jQuery in the F12 console)!

The original answer.

I have a need for a group of tech users to be able to impersonate business users so that the tech users can see the same page the business user sees and confirm that the app is correctly configured for the business user.

This raises a massive red flag for me.

There is a very meaningful difference between impersonating an authenticated identity, and having the ability to mirror a user's privileges or settings.

We are talking about seeing payroll data for different departments.

Your developers should have explicit rights to mock which department they belong to, in the payroll application (not on the AD level itself). This is nowhere near the same as impersonating a user account across the network.


Think about what you're asking. You're asking for the ability to pretend to be any user, at will, without logically provable permission from said user, at all times, which will give you access to highly confidential payroll information.
If you have the user's password, doing so is trivial (just log in as them). If you don't have their password, but were somehow able to pretend to be them anyway, then what's the point of having a password?

You're effectively asking "how do I lockpick all front doors because I sometimes would like to test the TVs of some of my neighbours".

The direct answer here is that you either need to get a similar TV (just like how you get a similar privilege/department), or you simply do it with the owner's express permission (i.e. having them log you into their account, or remotely taking over their machine).

If you were able to do what you expect to be able to do; then security is meaningless.

  • Flater: Boy, I did not describe my goal very well. I'm just trying to appear as a different user in one app. I'll edit my question with more detail. – Nolo Problemo May 31 '18 at 16:22
  • It is incorrect to assume by default that this is a security problem. The app in question might be a bulletin board for organizing picnics inside the department, and the risk of abuse quite low. Just logging the event of the emulation, along w/ user IP addresses, might be enough to forensically tell you for any particular action, if the user was an emulated user or not. – Graham May 31 '18 at 18:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.