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.
