Temporary Access: Time-Limited User Roles!

Have you ever wanted to provide temporary access to a specific user inside of the ServiceNow platform? Well, the time has come for the creation of this feature – time-limited user roles!

What is this capability, you ask? Great question – this is the only article at the time of this writing. As a ServiceNow partner, our practice has witnessed this and I have personally experienced this situation quite a few times on a project where a specific role is needed for brief moment in time. Do not think of this as a project-duration worthy feature – there is a mechanism in place to check for lengthy end times. Keep reading to learn more about this.

This is an extremely powerful feature that honestly could’ve been used a long time ago for many ServiceNow customers. At its core, this feature allows a user to be assigned to a specific role. The module can be found under the “User Administration” application menu and will require an administrator, user admin, or role delegator to view the module.

Sample Use Cases

1. Elevated access (from itil to itil_admin)
2. Brief development periods
3. Delegating work to others
4. Additional triage, thus preventing convoluted role inheritance.
5. Temporary reporting access

Fields/Data Model

Here is a quick look at the fields that come with the table: Time-Limited User Role [sys_user_has_role_time_limited]

• Active
  • Type: True/False
  • This is more of a data maintenance no check for duplicate and doesn’t turn off once end time is reached.
• Role
  • Type: Reference [Role]
  • This is very straightforward, the role that will be granted to the user based on the start/end time.
• Start time
  • Type: Date/Time
  • This is the specified time of when the role applies to the user.
• *End time
  • Type: Date/Time
  • This is the specified time of when the role no longer applies to the user.
• Comments:
  • Type: String, Length = 4000
  • Ideally, capture the business requirement of why this is occurring and treat this as the “justification” field.

*This feature is included with impersonation.

*There is an out-of-box business rule preventing an end time longer than 2 weeks (time-limited roles 2 weeks limit). The idea with this capability is that it truly is “temporary” and should not be applied for the length of a traditional project duration.

Findings/Closing Thoughts

At the core, think of what this is doing. This allows a user to have a new level of access within a temporary time window. Use caution with the role given to the user – having more “power” should come in the form of something that is controlled. Only provide elevated access to those who you trust, and when it makes sense to do so.

Findings

• Security admin is not selectable as a role (that would be a vulnerability)
• User admin can only view records. The New button is shown on the list view, but the user is unable to provide dates that drive the process.
• Depending on where you are in the platform will determine which color-coded message is shown. The green message below was from a dashboard; however, forms/lists have blue informational messages shown.
• When the start time begins, a message will be displayed to the user informing them that their roles have been changed.

• When the end time is reached, a message will be displayed to the user informing them that their roles have been unassigned.

• Updating the User from the list view is not allowed as an UPDATE operation.

Closing Thoughts

• Is this breaking “best practice” with respect to groups to roles, and users to groups? Realistically, yes – but there’s no cleanup involved. Keep your organizational security the way it is and use this as an extra channel for access when it doesn’t require a permanent change to security. This table provides a service to someone with the thought being that it will eventually undo itself.
• Should this be automated? Or should this remain a manual effort? Given your organization’s security posture and control around data integrity, this likely should be a service desk function so that it is audited in some fashion. From a service request perspective, this could be automated with multi-level approvals to ensure that proper access is provided.
• One item to note is that I noticed that there isn’t a check for the user’s current roles. This feature is likely the beginning with more to come down the road. There could be a reference qualifier to filter out the user’s current roles so the administrator can accurately target and provision temporary access.
  • I would also like to see a UI policy/data policy created for the following fields being mandatory; user, role, start time, end time. The form could use a bit of formatting design, but let’s not be picky here given that the feature has come to life. 😊