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:
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:
- 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.
- 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.
- 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.
- If the request is approved, then the workflow will use the update auth user endpoint to assign the requested user level.
- 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.
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.namefor 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.reasonForAccessfor the variable.
- Desired Expiration Date: Change the option from “Enter Value” to “Choose Variable”. Use
$.form.formData.removeDatefor 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.
- Add the ORG_ADMIN access to the identity
- Wait until the specified end date
- 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.
- Use the OAuth 2.0 authentication type, and specify the token URL, client ID, and client secret appropriate for your tenant.
- Set the “Request URL” to
https://{tenant}.api.identitynow.com/v3/auth-users/{{$.trigger.requestedFor.id}} - Set the “Method” to “PATCH” and the “Request Content Type” to “JSON Patch”.
- 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.