Identity Cloud

Configure access requests

Define resources that can be requested

By default, end users in Identity Cloud can’t request access to a resource. For an end user to request access to a resource, the resource must be marked as Requestable to display in the access catalog. You can make applications, entitlements, and roles requestable in Identity Governance.

Applications

To make applications requestable:

  1. From the Identity Cloud admin UI, go to Applications.

  2. Select an application. The application must be a target application.

  3. In the Details tab, toggle the Requestable box.

  4. For every target application you desire to be requestable, repeat steps 2-3.

Entitlements

To make entitlements requestable:

  1. From the Identity Cloud admin UI, go to Entitlements.

  2. Select an entitlement.

  3. In the Details tab, toggle the Requestable box.

  4. For every entitlement you desire to be requestable, repeat steps 2-3.

Roles

To make roles requestable:

  1. From the Identity Cloud admin UI, go to Manage > Alpha realm - Roles.

  2. Select a role.

  3. In the Details tab, toggle the Requestable box.

  4. For every role you desire to be requestable, repeat steps 2-3.

Add owners to resources

Before an end user can request access to a resource, you must associate it to an owner. Owners are the individual(s) responsible for monitoring who has access to the resource.

When an end user requests access to a resource, Identity Governance sends the request to the owner(s) for approval.

In access requests, the owner is referred to as the approver. When the owner approves the access request, Identity Governance provisions the resource to the end user.

Application owners

To assign owners to applications in Identity Cloud:

  1. From the Identity Cloud admin UI, go to Applications.

  2. Select an application. The application must be a target application.

  3. In the Details tab, click the Owners field, and add as many owners as you desire.

  4. Repeat steps 2-3 for every target application.

Entitlement owners

After you load entitlements into Identity Cloud, they display in the Entitlements section.

To assign owners to entitlements in Identity Cloud:

  1. From the Identity Cloud admin UI, go to Entitlements.

  2. Select an entitlement.

  3. In the Details tab, click the Entitlement Owner field, and select an owner.

  4. Repeat steps 2-3 for every entitlement.

Role owners

To assign owners to roles in Identity Cloud:

  1. From the Identity Cloud admin UI, go to Manage > Alpha realm - Roles.

  2. Select a role.

  3. In the Details tab, click the Role Owner field, and select an owner.

  4. Repeat steps 2-3 for every role.

Optionally, create and configure glossary attributes

Governance glossary attributes enable you to attach custom attributes to applications, entitlements, or roles.

When configuring resources that your end users can request access to, consider creating searchable governance glossary attributes. These attributes enable end users to filter and select a resource when requesting access.

Example of using glossary attributes with access requests

An example of using a governance glossary attribute would be to assign a risk level to each role, indicating the level of sensitivity associated with the resources granted to end users. This risk level attribute lets end users efficiently filter and search for roles based on their desired risk level when requesting access.

  1. From the Identity Cloud admin UI, click Glossary.

  2. Click Role > + Role Glossary Item.

  3. Enter the following values:

    Field Value

    Name

    riskLevel

    Display Name

    Risk Level

    Description

    The level of risk associated with granting this resource to a user. The higher the risk, the more sensitive the resource.

    Type

    String

    Enumerated Values

    Enable and create the following in the text and value fields:

    • Low

    • Medium

    • High

    Show advanced settings > Searchable

    Enable. This enables the end user to search and filter on the attribute when requesting access to the role.

  4. Click Save.

  5. Populate each role in Identity Cloud with either Low, Medium, or High.

    To do this, navigate to Manage > Alpha realm - Roles and populate newly created role attribute Risk Level.

Optionally, manage access request workflows

When you configure access requests, you can manage the default workflows, also referred to as identity orchestration workflows.

Identity Governance has default workflows that function as-is. You can also customize the workflows to align with your organizational requirements.

To manage access request workflows:

  1. Understand the access request types.

  2. Define approval and script tasks for each access request type workflow.

  3. Create the configurations using JSON and REST APIs.

  4. Optionally, review and modify the default access request email templates.

Access request types

In Identity Governance, various types of access requests exist, and each type has a corresponding identity orchestration workflow.

The following table displays the different access request types:

Access request type Name in REST APIs Description

Grant Application

BasicApplicationGrant

Request access to an application.

Remove Application

BasicApplicationRemove

Request to remove access to an application for an end user.

Grant Role

BasicRoleGrant

Request access to an Identity Cloud provisioning role.

Remove Role

BasicRoleRemove

Request to remove access to a role from an end user.

Grant Entitlement

BasicEntitlementGrant

Request access to an entitlement (additional privilege inside an application).

Remove Entitlement

BasicEntitlementRemove

Request to remove access to an entitlement from an end user.

Tasks in identity orchestration workflows

Each workflow for an access request type involves the following tasks:

Create your own approval and script tasks to meet the business needs of your organization.

All approval and script tasks in a workflow must be completed for Identity Cloud to grant access.
The following sub-sections explain approval and script tasks. For information on how to create the configurations, refer to Manage workflows using JSON and REST APIs.

Approval tasks

In each workflow, approval tasks require user input, such as an approver granting approval for a requested item.

Example

You can create the following approval tasks in the identity orchestration workflow for the application grant access request type:

  • Approval task 1 — The application owner must approve the request item. For this approval task, the following configurations are set:

    • An email is sent starting two days after the request is submitted and repeats every 2 days until the request item is complete or expires.

    • The expiration date is two weeks from the access request. If the request expires, send the 'Request Expired' email template to the application owner and the manager of the end user who submitted the access request, and then reject the request.

    • When the request is one week from expiring, escalate the request to the manager of the end user who submitted the request.

  • Approval task 2 — The manager of the end user who submitted the request must approve the request item. Task two only initiates if task one is complete. For this approval task, the following configurations are set:

    • An email is sent starting three days after the request is submitted and repeats every 3 days until the request item is complete or expires.

    • The expiration date is three weeks from the access request. If the request expires, reject the request.

The following table lists the items you can configure in each approval task:

Item Description

Approvers for a review item

Identity Governance uses the owner you define for each resource as the default approver.

You can specify as many approvers as you need for an access request type.

For example, you can specify that both a resource owner and a manager must approve the access request before the item(s) are provisioned to the end user.

Specify the email to send when a review item gets assigned to an approver.

The default email template is Request Assigned.

Specify the email to send when a review item gets reassigned to another approver.

The default email template is Request Reassigned.

Configure approval tasks expiration settings

Set up expiration-related tasks for each approval task associated with an access request type. These tasks should encompass the following elements or actions:

  • Email to send when the access request expires. The default email template is Request Expired.

  • Expiration date of the approval task.

  • Action to take after an approval task expires (if an end user defines an expiry date in their access request). The options are:

    • Reject the access request

    • Reassign to another user or role

    • Do nothing

Configure approval task escalation settings

Set up escalation-related tasks for each approval task associated with an access request type. These tasks should encompass the following elements or actions:

  • Email to send when the approval task is escalated. The default email template is Request Escalated.

  • When to start sending the email.

  • Individuals to escalate the approval task to, for example, an end user’s manager.

Configure approval task reminder settings

Set up reminder-related tasks for each approval task associated with an access request type. These tasks should encompass the following elements or actions:

  • Email to send as a reminder to complete a request item. The default email template is Request Reminder.

  • When to start sending the email.

  • How frequently to send the reminders.

For more information on the default access request email templates, refer to Review default email templates and modify.

Script tasks

Script tasks are similar to approval tasks in that they’re both required steps in the identity orchestration workflow; however, there are no user inputs with script tasks. Use script tasks to write custom logic for an access request type.

For example, after a request item is approved, you can specify Identity Governance to perform additional actions before provisioning access to an end user, such as populating an attribute in Identity Cloud to keep count of all resources a user has access to.

The default script tasks are:

  • Validate the access request:

    • If the access request is approved, give access (provision) to the application, entitlement, or role.

    • If the access request is rejected, remove access (de-provision) to the application, entitlement, or role.

  • If an approval task is rejected, reject the access request.

Split conditions and if-else paths in workflows

When you create a workflow definition for an access request type, you also define the paths that the workflow takes based on its conditions. Conditions are used with Script tasks.

You can define the following conditions in script tasks:

  • if-else — Also referred to as an exclusive gateway, an if-else conditional contains two outcomes. If one condition is met, take that outcome. Else, take another outcome.

    Example

    If an end user creates an application access request, and the request is approved, Identity Governance proceeds to provision the application (script tasks) to the end user.

    What happens if Identity Cloud can’t connect to the application at that time?

    To solve this, you use the if-else conditional.

    If the application is available, then automatically provision the application. Else (the application isn’t available), email the application owner that the application is unavailable and they must manually provision the application to the end user.

  • split — Also referred to as a switch or inclusive gateway, a split conditional allows many outcomes based on different conditions. Any condition or all conditions can be true.

    Example

    Lets say that, for high-risk applications, both the manager and resource owner must approve an access request to provision a resource to an end user.

    You can send these approval tasks in parallel, allowing both the manager and resource owner to receive the request item for approval simultaneously.

    The split conditional is added after these approval tasks, and it waits for both approvers to make a decision on the request item before proceeding in the workflow.

JSON example

If you need to create a custom application grant workflow definition, follow the example in the JSON file: Application grant JSON file. For more information on field definitions, refer to the identity orchestration YAML file.

Use the JSON file, for example, in step 3 of Steps to manage workflow definitions.

Manage workflows using JSON and REST APIs

Identity Governance stores and saves workflow configurations in JSON format. You can manage the default workflow definitions for each access request type using REST APIs.

When you create a workflow definition for an access request type, the definition can be in one of the following states:

  • draft — A staging state to validate a workflow definition before publishing.

  • publish — The workflow definition is live.

Steps to manage workflow definitions

  1. Retrieve the current default workflow configurations for access request types using /auto/orchestration/definition(GET).

    Save a copy of the default workflow for the access request type in case of an error with your updated workflow JSON file.

  2. Modify the default workflow to suit your needs.

  3. Create a new default workflow definition for an access request type in a draft state using /auto/orchestration/definition?_action=create (POST).

    Each access request type can only contain one workflow definition in the draft and publish states. One can exist in the draft state and the publish state.

  4. Validate the workflow definition before publishing using /auto/orchestration/definition?_action=validate (POST).

  5. Publish the workflow definition from its draft state using /auto/orchestration/definition?_action=publish (POST).

    You can’t delete workflow definitions in the published state.

  6. Repeat steps 1-5 for each access request type desired.

For more information, refer to identity orchestration APIs.

Review default email templates and modify

When enabled in your Identity Cloud tenant, Identity Governance creates default email templates for access request-related features. Identity orchestration workflows reference default access request email templates. You can modify these email templates if necessary.

  1. From the Identity Cloud admin UI, go to Email > Templates.

  2. View the following email templates and modify as necessary:

    Some access request email templates use configurations set in the workflow definition for an access request type. The Notes column indicates if a template uses configurations.
    Email template name Description Notes

    Request Assigned

    Initial email to the approver(s) of a resource when an end user submits an access request.

    N/A

    Request Reassigned

    Email to the new assignee when an approver forwards a request item.

    N/A

    Request Escalated

    Email to an individual assigned as the escalation point of contact.

    Defines the escalation point of contact, start date of the notification email, and frequency in the workflow for each request type.

    Request Reminder

    Email to the approver(s) as a reminder that they have a request item to act on.

    Defines the start date and frequency of the notification email in the workflow for each request type.

    Request Expired

    Email to the approver(s) when a request item expires. The end user defines the expiry of the access request when they submit the access request.

    Defines the following workflow items for each request type:

    • Duration of the notification email before the request expires

    • Action to take when the access request expires including:

      • Reject the access request

      • Reassign to another user or role

      • Do nothing

    These configurations only apply if the end user defines an expiration date in the access request.

  3. For each email template:

    1. Click the desired template.

    2. View the contents of the email.

    3. If desired, update the email subject and body. For more information on customizing email templates, refer to Email templates.

      To reference access request information in a variable in an email template, use syntax similar to the following:

      request.user.userName

      The variables you can reference depend on your tenant’s configurations; therefore, they’re specific to your organization.

      To reference available attributes, from the Identity Cloud admin UI, go to Email > Template > Select template > Variables.
Copyright © 2010-2023 ForgeRock, all rights reserved.