Role assignment and removal

[dellyou088]

We have to assign privileged roles including security_admin and revoke when end time reaches, what if time-limited user has role table is not to be used.

Both answers are needed.

[Dr Atul G- LNG]

Hi  

As SN provides time-based roles, it is better to use that approach as it is easier and supports end-to-end tracking. Other ways changes can be logged and managed through change requests or service requests.

[dellyou088]

But OOB SN doesn't give security admin in that table as roles, Only 4 roles were there which can be granted and revoked.

[Tanushree Maiti]

Hi @dellyou088 

I would recommend against automating this process. The main reason is that the number of users with the security_admin role is typically very limited in any instance.

Unless an admin explicitly elevates their privileges to security_admin, they will not be able to add or remove the security_admin role for other users.

You would also need to ensure the script runs under a system-level context (for example, using gs.getSession().elevateRole() in a Business Rule or configuring an appropriate “Run As” user for a Scheduled Job) so it has sufficient privileges to modify highly restricted roles.

In my opinion:

1. The security_admin role is an elevated-privilege role. Automated background processes cannot reliably replicate the manual role-elevation mechanism required in interactive sessions.
2. Automation in this area can introduce security risks. A misconfigured or exploited process could unintentionally grant persistent elevated access.
3. Elevated roles cannot be delegated by a standard admin account alone. A user must already have the security_admin role in order to grant it to others.
4. Automated role assignments can weaken auditability and compliance, since organizations may not be able to clearly track who approved or authorized temporary privilege elevation.