Temporary Admin Access in Identity Security Cloud using Roles, Forms, and Workflows

[colin_mckibben]

If you ever find yourself needing to temporarily grant elevated admin privileges in Identity Security Cloud (ISC), you may wonder how you can automate the process of granting and revoking these privileges to users. You can manually set user level permissions when a user asks for a temporary elevation, but then you are on the hook for revoking those permissions once they are no longer needed.

One way to solve this problem is to install the IdentityNow Management Connector, which is a loopback connector that makes your IDN tenant a source itself with the ability to aggregate user levels as entitlements. You can then setup roles that will grant the appropriate user level entitlement, and make those roles requestable from Request Center. This approach has the advantage of being able to discover all available user levels, but it does take some effort to install and configure the connector.

This blog post will discuss another solution to the temporary admin access problem by leveraging roles, forms, and workflows. The advantage of this solution is that it can be configured to work with any user level permissions that are available, and it can be highly configured to fit your process. In most cases, it is preferable to use one of the two options above, but if this solution interests you, please continue reading.

You can also watch a video of this content here:

Building advanced workflows

[Building advanced workflows] Description Interested in getting advanced with workflows on the Identity Security Cloud? Join Colin as he teaches us best practices, tips, and tricks to master the art of building workflows in IdentityNow. Whether you’re a novice or an expert, join us to learn just how advanced your workflows can be! Additional Resources Here is the blog post that provides links to the workflows JSON and a step-by-step guide on how to implement the use case I demonstr…

Overview of the Process

In order to implement temporary admin access, we will need to leverage roles, forms, and workflows. The process for requesting, granting, and revoking admin privileges will be as follows:

1. Create a role for each user level you want to allow to be requested. This could be a role for Admin, Source Admin, Report Admin, etc. These roles will not have any access profiles or entitlements. Allow each of these roles to be requestable, but don’t configure an approval chain, and don’t require comments or a remove date. We will leverage forms and workflows to implement the approval chain.
2. When a user requests one of the admin roles, the request will be automatically approved since there are no assigned approvers. We will create a workflow that will trigger on completed access requests for the specific roles we have created, and a form will be sent to the requester to capture additional information.
3. The workflow will send a form to the requester asking for the reason they need the access and the date they no longer need the access. Once the user submits the form, the workflow will send forms to one or more approvers, such as the user’s manager and/or an existing IDN admin. This form will contain the user’s name, why they need the access, and when they will no longer require access. The approver can either approve or deny the request. If they deny the request, then the workflow will send an email to the user to inform them of the denial.
4. If the request is approved, then the workflow will use the update auth user endpoint to assign the requested user level.
5. The workflow will implement a wait step that will resume the workflow on the date and time that the user indicated they no longer need the access. The final step is to revoke the user level by using the update auth user endpoint.

Workflow Files

The code for this workflow is available in the Colab. Please see the topic below for instructions to download and install the workflow file.

Temporary Admin Access Workflow

[Marketplace-Gradient] Description A workflow for temporarily granting admin access to ISC users Legal Agreement By using this CoLab item, you are agreeing to SailPoint’s Terms of Service for our developer community and open-source CoLab. Repository Link github - temporary admin access New to Workflows in the CoLab? Read the getting started guide for Workflows in the CoLab. Supported by Community…

Creating the Role

You will create one role for each of the user levels you want users to be able to request. In this example, we will create a role for requesting admin access, the highest level of access in ISC.

You can modify the description to fit your needs. I chose a default expiration of 8 hours, but this may be different depending on your needs.

You will leave “Manage Access” and “Define Assignment” alone. The only other option you need to set is the “Allow Access Requests” option in the “Access Requests” tab.

Make sure the role is enabled so you can test your workflow.

Creating the Requester’s Form

Since the event trigger for completed access requests does not provide the revocation date, and the APIs for looking up information about an access request are difficult to work with, we will send a form to the requester asking them to provide the reason for this temporary access and when they expect to no longer need it.

For detailed documentation on creating forms, please see Forms - SailPoint Identity Services.

Header

Start by giving the form a name and description.

Next, add a section header to inform the recipient’s about the purpose of this form.

Reason for Access

Add a text area field to the form with the following configuration.

Remove Date

Add a date field with the following configuration.

Final form

Your form should look like this.

Creating the Approver’s Form

We need to create a form that will be sent to identity’s that will need to approve the request. This form should contain the following information:

• Who is requesting access?
• What user level is being requested?
• What is the reason for requesting it?
• When is the access no longer needed?

For detailed documentation on creating forms, please see Forms - SailPoint Identity Services.

Header

Start by giving the form a name and description.

Next, add a section header to inform the recipient’s about the purpose of this form.

Name of Requester

Next, add a text field to display the name of the identity requesting access.

We want our workflow to be able to supply the name of the requester to the form when it is sent. Click “Apply” to save your changes, and then click on “Condition” → “Manage Conditions”. This will bring up the “Conditions” view where you will create a new condition.

Select “Inputs” from the sidebar and add a new input for the name variable.

Next, we want to disable the name field on the form so the recipient doesn’t get confused as to whether or not they are supposed to modify the name field. The name field is for display purposes only. To disable the name field, click on “Conditions” on the sidebar and create a new condition.

Configure the “Rule” as follows.

Scroll down and configure the “Effect” as follows.

Make sure to click “Apply” at the bottom to save your condition.

Requested User Level

The requested user level is going to follow the exact same procedure as the “Name” field above. It will be a text field with a corresponding input variable and a condition to disable the text field if the input variable is not empty.

Create the text field with the following information.

Create a new input with the following information.

Create a new condition with the following rule and effects.

Reason for Request

The reason for requesting the access will be a text area with a corresponding input variable and a condition to disable the text area if the input variable is not empty.

Start by creating a new text area field.

Create a new input with the following information.

Create a new condition with the following rule and effects.

Desired Expiration Date

The desired expiration date will be a text field with a corresponding input variable and a condition to disable the text field if the input variable is not empty.

Start by creating a new text field.

Create a new input with the following information.

Create a new condition with the following rule and effect.

Decision

We need a field for the approver to either approve or deny the request. Add a new select field to the form with the following configuration.

Comments

We need a comment field to capture the comments of the approver. We will make this required so the approver must leave some sort of comment for either approving or denying the request, which will help with auditing purposes.

Add a new text area field to the form with the following configuration.

Final Form Details

After configuring the four fields and conditions, your form and condition list should look like this.

Creating the Workflow

With the role and the form configured, it’s now time to create the workflow that will handle the logic of granting and revoking the temporary access. Start by creating a new workflow called “Temporary Admin Access”. Your fully configured workflow will look like this once it is finished.

Trigger when access request is completed

Add the “Access Request Decision” trigger to the workflow, which will start this workflow when an access request has been completed. Add the following filter to this trigger to ensure that this workflow only triggers when the completed request is for the “Temporary Admin Access” role.

$.requestedItemsStatus[?(@.name == "Temporary Admin Access")]

Get the attributes of the requester

We will need the email address of the requester for some of the emails we will send out later in this workflow. Configure a “Get Identity” action to retrieve the requester’s information by using $.trigger.requestedFor.id as the identity variable.

Send a form to the requester

When there is a request for the admin role, we need to send a form to the requester asking for additional information, like the reason for the request and when they no longer need it. Add a “Form” action below the trigger and configure it to send the “Temporary User Level Permissions - Requester” form to the identity that will be receiving the access. Add an appropriate subject and notification body to the form so the requester will know to complete the form to continue with their request.

Send a form to the approver(s)

Once the requester submits their form, we will need to send a form to each approver in the chain. In this example, we will just send the form to one approver, but you may have more.

Add a new form action to the workflow and configure it to send the “Temporary User Level Permissions - Approvers” form. Configure the following fields.

• Requester Name: Change the option from “Enter Value” to “Choose Variable”. Use $.trigger.requestedFor.name for the variable.
  
• User Level: Enter “ORG_ADMIN” into the text field.
  
• Reason for Access: Change the option from “Enter Value” to “Choose Variable”. Use $.form.formData.reasonForAccess for the variable.
  
• Desired Expiration Date: Change the option from “Enter Value” to “Choose Variable”. Use $.form.formData.removeDate for the variable.
  
• Recipient: Add the identity of your choice. This could be the user’s manager, the role owner, or a hardcoded value. For simplicity, this example will use a hardcoded value.
  

Configure the remaining notification options to your desired values.

Handle Approver’s Decision

When the approver submits their decision, we need a conditional operator to determine which set of actions to take. Add a “Compare Strings” operator to the workflow and configure it as follows.

If Approver Denies the Request

If the approver denies the request, then send an email to the requester with the comments from the approver. Use a “Get Identity” action to get the email address of the requester so we can send them the email.

Next send the email to the requester.

If Approver Approves the Request

If the approver approves the request, then we need to perform a couple of actions.

1. Add the ORG_ADMIN access to the identity
2. Wait until the specified end date
3. Remove the ORG_ADMIN access from the identity

Add the access

To add the ORG_ADMIN access to the requesting identity, we will use the update auth user endpoint. This will require an “HTTP Request Action” configured as follows.

1. Use the OAuth 2.0 authentication type, and specify the token URL, client ID, and client secret appropriate for your tenant.
2. Set the “Request URL” to https://{tenant}.api.identitynow.com/v3/auth-users/{{$.trigger.requestedFor.id}}
3. Set the “Method” to “PATCH” and the “Request Content Type” to “JSON Patch”.
4. Set the request body to [{"op":"add","path":"/capabilities/0","value":"ORG_ADMIN"}]

Wait for the remove date

After the access has been granted, we’ll use a wait step to pause the workflow execution until the end date has been reached. Add the “Wait” action to the workflow, set the “Wait Type” to “Wait Until”, and set the “Date” to $.form.formData.removeDate. Set the “Time” to 12:00 AM.

Remove the access

Once the remove date is reached, the workflow will resume and we need to remove the admin access. This is a little bit tricky since a user has a list of capabilities, and we cannot guarantee that the list of capabilities didn’t change between when the access was granted and when we need to remove it. We added the admin access to the beginning of the capability list, but if the user was also given another capability later, then the first item might not be the admin access we added. As a safety check, we will first get the current access of the user and then do a comparison step to see if the first item is still the ORG_ADMIN capability. If it is, then we will remove it. If it is not, then we will send an email to another admin asking them to manually revoke the access since we don’t know where in the list it is.

Start by creating a new HTTP Request action to get the current access of the user. It will be configured the same as the request to grant access, but the Method will be a “GET” instead of a “PATCH”.

Next, add a comparison operator to check if the admin capability is still the first item in the list. Use $.hTTPRequest2.body.capabilities[0] as the JSONpath expression for Value 1.

For the False path, send an email to an admin asking them to manually revoke the admin permissions for the user.

For the True path, duplicate the HTTP Action that granted access. Keep the configuration the same, but change the request body to the following.

[
  {
    "op": "remove",
    "path": "/capabilities/0"
  }
]

You should also send an email to the user to inform them that their access has expired and the admin privilege was removed.

[atarodia (Animesh Tarodia)]

@colin_mckibben,

Another option: With the direct Entitlement to Role functionality, you can directly add the User Levels as Entitlements to Role natively and that provisions and deprovisions based on Role Access Request. Adding the sunset time would deprovision the user level automatically.

[colin_mckibben]

Does that require the loopback connector, or are the user level entitlements natively available?

[atarodia (Animesh Tarodia)]

They are natively available now

[colin_mckibben]

Would you be willing to write a Blog Posts or ISC Show and Tell detailing how to do this? That would greatly simplify the process of temporary admin privilege.

[atarodia (Animesh Tarodia)]

Sure, I will do that

[lchaganthi (Lakshmi Chaganthi)]

Continuing the discussion from Temporary Admin Access in Identity Security Cloud using Roles, Forms, and Workflows:

How do we handle when we don’t use Access Request Module and want to integrate the approval process using a service management tool like service now or Remedy

[colin_mckibben]

@lchaganthi

How do we handle when we don’t use Access Request Module and want to integrate the approval process using a service management tool like service now or Remedy

The simplest solution would be to replace the trigger with the “External Trigger” and have service now or Remedy invoke the workflow via the External Trigger with the necessary info.

[abeltran (Andres Felipe Beltran)]

Is it possible to use a governance group as an approver and send the approval form to the members of this group so that any of them can make the approval? This to avoid placing several people as approvers and each one must approve in order to continue with the process.

[colin_mckibben]

I don’t see a way to send a form to governance group at this time.

[PK001055736 (Priyanka Katyan)]

Hi Team,
I want to add the workflow for the API in BETA
{{baseUrl}}/access-requests
Can you please suggest the workflow. I want to enforce the sunset in the same.

{
  "requestedFor": [
    "2caef0e1221d4af48610f735d809f7ab"
  ],
  "requestType": "GRANT_ACCESS",
  "requestedItems": [
    {
      "type": "ROLE",
      "id": "ae1e5d988c8944b29bb627b0c7a45d77",
      "comment": "Requesting Temporary access profile for Priyanka Katyan",
      "clientMetadata": {
        "requestedAppName": "Active-Directory",
        "requestedAppId": "8c454698459642529e254ef95e82a5d7"
      },
      "removeDate": "2024-10-04T00:00:00.000Z"
    }
  ],
  "clientMetadata": {
    "requestedAppId": "8c454698459642529e254ef95e82a5d7",
    "requestedAppName": "Active-Directory"
  }
}

[joC11 (Joanna Clapka)]

Were you able to get a writeup done on how to achieve this? You mentioned in a different comment that this is now natively available in ISC however when I tried it just now the only entitlements I could find were those linked to our existing sources…

[colin_mckibben]

Animesh wrote up a blog post here: Temporary Admin Access with Roles in Identity Security Cloud

However, this method of temporary admin access does not work as described. While the entitlements for user levels are available, they do not actually grant the user level permissions. The method above that uses workflows is the only way I know of that works at this time.

[sindelre (Robert Sindelar)]

@colin_mckibben
You are creating Roles with no Entitlements or Access Profiles assigned to them. Doesn’t a role need to have at least one Entitlement or Access Profile for it to appear in the Request Center?

[colin_mckibben]

I am able to see my role in request center. However, with the introduction of interactive triggers, there is no longer a need for a role to trigger this workflow. At some point I will update this blog to use the interactive trigger to kick off the workflow.

[sindelre (Robert Sindelar)]

@colin_mckibben thanks for the quick response! Looks like this is just an issue with one of our Sandbox tenants. It’s working in other tenants.

[sagar_kamalakar]

@colin_mckibben, Thanks, This article provides a lot of valuable information, especially regarding workflow. The most challenging part to grasp is how to construct the JSONPath filter for the Access Request Decision trigger. I mean what is the reference point to build filter e.g. $.requestedItemsStatus[?(@.name == “Temporary Admin Access”)]
requestedItemsStatus

[colin_mckibben]

@sagar_kamalakar

I mean what is the reference point to build filter e.g. $.requestedItemsStatus[?(@.name == “Temporary Admin Access”)]

Hi Sagar,

JSONpath takes practice to learn, but you can start with this document to help you get oriented.

Filtering Events | SailPoint Developer Community