restrict crud operations when impersonate user
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-29-2023 07:43 AM - edited 11-29-2023 07:54 AM
When an user impersonating another user, he cannot perform the create, update and delete operation in the time of impersonation.
Please help me to do this requirement.
- Labels:
-
Architect
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-29-2023 07:50 AM
Hi @Nihar2
sorry, this makes no sense. "CRUD" stands for (c)reate, (r)ead, (u)pdate, (d)elete
If an impersonating user is not even able to read anything, so why should he impersonate?
And apart from that. The reason why we have the impersonating functionality in ServiceNow is to be able testing exactly what the impersonated user can. If you want to restrict that anyhow you are not able anymore to understand the issues of your users!
Maik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-29-2023 07:53 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-29-2023 07:57 AM - edited 11-29-2023 07:58 AM
Hi @Nihar2 ,
As Maik mentioned, is not much clear what you are trying to achieve.
Are you trying to restrict specific users to perform any CRUD operation?
Or restricting CRUD operation when anyone is impersonating another user? If that is the case, you may need to review your processes as restricting impersonators to perform such actions would break the functionality of that feature.
I should also mention that in Production instances, no one (except admins) should have impersonator role.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-19-2024 10:24 AM
Hi @Nihar2
I think both @Maik Skoddow and @Luiz Lucena raised valid concerns. Detailed review of your instance and processes is in order and later on you could try reworking your ACLs with usage of GlideImpersonate to block some operations based on result of isImpersonating() (there are some OOTB ACLs that are consuming this class). Warning: messing up ACLs will have huge impact on instance so caution is advised.
Looking at this from a different angle - I'm assuming that this requirement comes from some Data Security / SecOps /Auditor - to introduce a control over "unwanted" data changes. Have you considered going into "monitoring mode"? In the past I've seen solutions that upon impersonation impersonated user and SecOps team were notified (there are events "impersonation.start" and "impersonation.end" )
