Dynamically Add/Remove Roles

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.


    • Hey, don’t think I’ll have time soon to post it as it was a bit long. I’ll add it to my list of things to post. But from a high level, the solution comprised of the following:

      1) Created a new role called admin_elevate.
      2) Created a service request which was only available to people with the admin_elevate role.
      3) When submitted, it would do a gliderecord to add the admin role to the sys_user_has_role table and then run the above script to immediately provide them access.
      4) The service request would also create a scheduled job called rmadm + users_sys_id. The system ID set as ALL NODEs (blog post coming in an hour or so about what that is).
      5) The scheduled job would be scheduled for when the role was due to expire, and would do a gliderecord on the logged in users table to find out if the admin was logged in on that node. And if it found it, it would kill it (theres a business rule on the logged in users table you can copy to see how to do that).
      6) On login, created a synchronous script action on session.established. It would do agliderecord to see if there was an active rmadm + users_sys_id scheduled job. If not, it meant the user shouldn’t have the admin role, and it would remove it from the sys_user_has_role table and then run the above script to remove that access

      Hopefully that should get you going in the right direction


    • A lot (and a lot) of trial and error. You can loop through the scriptable names like any javascript object. I add a condition in there to only get me keys that aren’t all upper case. Usually upper case keys are constants and not functions. Saw the get function in there, and then tried that. Then did the same on the returned value of get, and then went through that. Has a similar syntax to GlideSession. Sometimes you get lucky and stumble across something working. The real difficulty is figuring out the inputs and their types because Java is a far more structured language than Javascript and will only accept the correct type of data to be passe din.

      var x = GlideSecurityManager;

      for (k in x) {
      if (k !== k.toUpperCase()) {
      gs.print(‘Glide Security manager: ‘ + k);


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.