Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on How to properly deal with impersonation in a Web application? (security vs. usefulness for tech support)
Parent
How to properly deal with impersonation in a Web application? (security vs. usefulness for tech support)
Context
Our team has begun migrating a pretty old internal application and one aspect that got my attention is the impersonation. This is implemented as follows:
- only administrators are allowed to impersonate someone else
- impersonation means setting the current session user to the impersonated user
- the result is that ALL operations are done as if the impersonated user is acting (entities created with that id, logs indicate that user etc.)
This is very convenient for technical support because they can easily "see" through any user reporting an issue.
The security model is quite complex: many roles and rights, fined grained security based on multiple dimensions (country, business units, categories etc.)
However, my reaction was that is uncompliant and will fail any decent audit, because administrators can do actions with other users and nobody will know. The PO agreed that this is not OK and that the migrated version should tackle it.
The issue
Now I am looking for a solution about implementing the impersonation and get a good compromise between security and usefulness for the technical support.
The big picture that I have in mind right now is the following:
-
all actions (queries, commands and their results) will be logged to minimize the need for impersonation. Logging in the legacy application is very poor.
-
all records generated by an impersonator will get their user identifier. This ensures that impersonator cannot abuse their role, but might prevent some flows from being checked (e.g. security rules that rely on the actual user identifier like "I am not able to see non-shared documents created by another identity")
-
all rights checks (e.g. can edit a document) will be executed against the impersonated user. This ensures that the impersonator see the restrictions applied to the impersonated identity and all rules that do not rely on the actual user identifier
-
having multiple test users is hard because everything relies on Azure A/D authentication tied up to the domain account
-
alternative: allow the old fashioned impersonation to work on test environments, but I find this particularly risky and I generally dislike having any functional differences between prod and non-prod, except for the work in progress developments
How should I balance the security and usefulness for technical support-related activities?
Post
My first instinct would be to track both identities, using one for access control, and the other for audit purposes.
For instance, rather than storing:
User createdBy;
you'd store
User createdBy; // for auditing
User createdOnBehalfOf; // for access control
All access control logic would use createdOnBehalf, but the UI would show both, for instance like "created by ArtOfCode on behalf of meriton".
This makes impersonation transparent, while allowing the impersonator to use the application exactly like the impersonated user.
This is a pretty standard approach. For instance, when you send a mail in outlook on behalf of someone else, you see something like "From: Sue on behalf of Joe". Similarly, git tracks both the author and committer for every commit, clearly separating the person responsible for the content from the person responsible for its existence in a particular branch.
Of course, if tech support is the only reason for the existence of this impersonation feature, simpler solutions may exist. For instance, tech support could remote control the user's desktop using team viewer, thus ensuring impersonation happens only with the knowledge and consent of the person being impersonated.
0 comment threads