- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-05-2024 08:22 AM - edited 08-05-2024 09:25 PM
Hi all,
I would like to bring to your attention a recent requirement that necessitates the restriction of user permissions, including those of administrators, with the exception of the "security_admin" role. The objective is to prevent all users, aside from the "security_admin," from having the ability to add or remove users from any group classified as an "entitlement" type.
Below configurations has been done to achieve this requirement
- Modified Create ACL (OOB) on sys_user_grmember table
- Role: user_admin
- Condition: Group Type is not Entitlement
- Admin Override: False
- Created new Create ACL on sys_user_grmember table
- Role: security_admin
- Condition: Group Type is Entitlement
- Admin Override: False
- Modified delete ACL (OOB) on sys_user_grmember table
- Role: user_admin
- Condition: Group Type is not Entitlement
- Admin Override: False
- Created new delete ACL on sys_user_grmember table
- Role: security_admin
- Condition: Group Type is Entitlement
- Admin Override: False
The configuration is functioning correctly for the addition of users; that is, only individuals with the "security_admin" role are authorized to add users to groups of the "Entitlement" type.
However, I have observed that the removal of users from these groups is not restricted in the same manner. Users lacking the "security_admin" role are still able to remove others from the groups, which is not the intended behavior.
Could anyone provide insight into what might be missing from my current setup? Any guidance on this matter would be greatly appreciated.
Please note that the solution must be confined to Access Control Lists (ACLs). Modifications to Business Rules (BR) or List Controls are not permissible for this scenario.
Thank you in advance for your assistance.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-08-2024 07:51 AM
Hi @Paige Duffey ,
Thanks for the response.
There is another OOB ACL in HR scope where admin override was checked, when I unchecked, it worked.
Initially I thought since the scope is different and conditions are not matching it will not impact but somehow it impacted.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2024 11:08 AM
I tested a similar setup as described above in an out of the box Washington instance and it worked as expected. A user without the security_admin role was not able to remove users from groups with a specific type, though they maintained the ability to remove users from other groups. It was not the best user experience, because it still appears that I was able to remove the user (the info message at the top of the screen states that the add/remove role from users had been queued), and there as no indication nor error telling me I was prevented from doing so.
If you've confirmed that users without the security_admin role can still remove users from those groups, I'd recommend running security debugging to see what's granting that user access. The ACLs you've modified and created should do the trick if there's not another security rule allowing the user to bypass them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-08-2024 07:51 AM
Hi @Paige Duffey ,
Thanks for the response.
There is another OOB ACL in HR scope where admin override was checked, when I unchecked, it worked.
Initially I thought since the scope is different and conditions are not matching it will not impact but somehow it impacted.