I was working on a requirement recently where the customer didn’t want any admin to have permanent admin rights to the system.
The administrators could fulfil most of their work using other lower roles (itil, user_admin, knowledge_admin etc.). A bad experience where an admin accidentally did something they shouldn’t have, meant they wanted more rigour around the admin role.
What they asked for was if it was possible that admins could request the admin role via a service request and so it could be audited and then automatically removed after a set time period.
I’m not going to talk about the whole solution that was implemented here (maybe another time), but what I do want to show is how I added and removed particular roles on login and as part of the workflow. The usual approach to giving someone a role is to add it to their user record and then ask the user to log off and on again.
When trying to dynamically change their roles on login, this wasn’t an option.
What I discovered was a bit of code that essentially resets the user’s security profile. I added it as part of a script action that ran on the session.established event (look here for an example of how to set that up Reverting The ‘Modern Cell Coloring’ Back to Pre-Eureka).
So on login, it would check if the user had the rights to have the admin role, and if not would remove it from the sys_user_has_role table and then run:
var sm = GlideSecurityManager.get();
Now without logging off and on again, the system recaches the user’s roles and they will no longer have the admin role.
The reverse happened on the service request where it would add the admin role to the sys_user_has_role table and then run the code snippet and the user would immediately have the admin role again.