Log in as another user
Ability to log in as another user to test a change in this user's configuration or try reproducing an issue only this user is seeing.
With SSO enabled environments, this is not doable
The system should keep track of this action for audit purposes

-
Stephen commented
We do the same as @mray@absolute-fs.com. Each week we copy our production data to our training DB (and of course we have a training tomcat) and turn SSO off and update all users to one password. This allows us to log in as anyone to see what they are seeing and train anyone on other roles. Our data is never older than one week in the training DB.
-
David Blaha commented
Why has Eptura not actually commented on this for almost five years?
-
Dalton commented
Alternative strategy to "test a change in this user's configuration or try reproducing an issue only this user is seeing" could be a process that allows you to temporarily assign all the same processes, security groups, work teams, VPA, etc of one user to another. This could prevent the impersonation issue but still allow the emulation of their user-assigned permissions.
Would need to save a backup for the user doing the troubleshooting so they can easily return to their own configuration once done "acting" as the other user's role/permissions.
-
mray@absolute-fs.com commented
Chris, this is a time consuming process that requires approvals and should not be the solution. Referencing... "we clone PROD to test env, where SSO is disabled. Set a users password, and then login as them"
-
Chris M commented
We have a separate environment that does not use SSO. If we need to replicate an issue or test as another user, we clone PROD to test env, where SSO is disabled. Set a users password, and then login as them.
-
Tony Weber |The Building People commented
Here are some other products that have this feature...
https://support.atlassian.com/user-management/docs/log-in-as-another-user/
https://www.replicon.com/help/logging-in-as-another-user/ -
Tim Callis commented
Building on the previous idea about a security group maybe it’s a onetime button that right then logouts you out and then automatically logs you in as “the selected user”. Later upon logout or timeout your next connection would be via your normal process (Name/Role/etc).
High Security environments would definitely see this as a potential threat vector, to help mitigate that it might be wise to additional have file property that allows/disallows this as a feature, in the security.properties for example defaulting to NotAllowed seems like a good choice. This allows organizations to choose if they want to enable such a feature Always/Never/Sometimes and while it’s not dynamic it is still a diagnostic possibility when required.
I’ve run across this type of situation at almost every customer at one point or another. Sometimes it can be a nightmare trying to work through solutions without someone available to “reset” your role/account. I’m not tied up in how it gets done, almost anything would be better than nothing.
-
Tony Weber |The Building People commented
Jira has this feature... https://confluence.atlassian.com/cloud/log-in-as-another-user-776994835.html
So does Replicon... https://www.replicon.com/help/logging-in-as-another-user/
-
richard.martin@jll.com commented
With SSO and LDAP authentication it is difficult for System Admins to troubleshoot errors that their end-user experience. The only option they have is to work with the user to find a time that works for both parties to have a working session, A lot of times these end up being fact-finding sessions which are followed up with another session for implementing resolution and testing. To work with another System Admin to set their Role to match the user having issues, which is not ideal. The last option is to hope that the same issue exists in the Development or Staging environment if they are not protected by SSO/LDAP. It would be nice for a future release to have the ability, as a System Admin, to proxy as another user/role in these secure environments.
-
Timothy J Robinson commented
Yes, it would be nice to have this for troubleshooting. I've thought it through before and for security reasons you might want to require that someone signed in with a certain security group, would then be able to "impersonate" any user.
-
Kevin.Zimmer@am.jll.com commented
The concept of mix mode authentication needs to be thought through a little more, but I agree that this would be helpful. We also see this use case on higher education campuses and hospital campuses where some users need to be setup as SSO users and other groups need to be configured as Archibus Auth.
-
mray@absolute-fs.com commented
Often Business Partners and internal IT staff need access to Archibus for troubleshooting. This sometimes requires logging into Archibus as that actual user in order to see what they are seeing. With SSO turned on, this is not possible without creating a secondary instance. There are actually 2 needs here.
1-A means for logging in as a non-AD user when SSO is turned on and without having two instances to maintain.
2-having a means to login with SSO on, but as a different user. I've seen other systems offer access tokens. As a user I can click on a button and get an access token (256 char code) and send that to anyone that needs temp access. It's only active for a max of 24 hours and the user is asked how long to make it. When a tech accesses the system with the token, they are seeing everything as if they logged in as that actual user. Something like this would be helpful.