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.
Best Answer
Update to your update.
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:
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.
The original answer.
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.
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.