Issue overview
The "impersonator" role allows anyone having it to impersonate any user they can see in the platform. This isn't a problem if is granted to users in instances that don't have the domain separation plugin enabled. However, it is quite common for Managed Services Providers (MSPs) to require to grant the "impersonator" role to their customers so that a "super user" in a given domain can impersonate their peers within that domain to validate whether what they are experiencing is a bug or simply a lack of training.
If the MSP grants the role to a customer user this customer user will not only be able to impersonate their peers in the same domain but also any "global" user. MSPs usually have their employees visible by each of the customers so that these can see who is dealing with their tickets when those are assigned to the MSP, so hiding the users would not be an option.
Hiding them in the impersonator dialog would be ideal, but the page cannot be found amongst the macros, pages, etc... as it is an element that cannot be customised.
Solution
Does this mean the impersonator role cannot be granted to customers? Well, there is an approach that can be taken to overcome this limitation without heavily customising the instance.
The impersonate dialog page above represented will show users the logged in user can see, and only appears if the user has the "impersonator" role. Given that the "impersonator" role is an elevated privilege, the "gs.hasRole()" method will return false if the role was not elevated, and true otherwise.
This means a Business Rule on Query will suffice to hide those records when the user has elevated the "impersonator" role. The only caveat is that while the role is impersonated they won't be able to see users from the MSP. They will need to stop elevating the "impersonator" role to set the visibility of users back to normal.
The MSP must be careful since disabling this business rule or breaking it with subsequent deployments would mean their customers would be able to impersonate users in the MSP themselves, being able to see all they can.
As this issue would have a big impact, it is highly recommended that the MSP creates a Test in ATF to ensure this feature works fine prior to deploying anything in production or upgrading the instance. If the case doesn't pass the ATF tests then the update set(s) or application must not be deployed in production until the issue is fixed.
If this blog article was useful to you, please click on “Helpful”.
Other blog articles created by me:
- "Adaptive authentication" or how to restrict access to users based on a specific criteria
- Automating SMS texts and phone calls with Notify
- Translating tickets out of the box using the Microsoft’s Azure translation services
- Avoiding time-consuming transactions being automatically cancelled
- How to give your scripts a beatiful aspect in KB articles
- What is the Data Certification Plugin and how can it be leveraged?
- Validating Service Catalog variables following the best practice
2 Comments
