Access Request Overview

Users can submit access requests to get access to the applications or business roles they need to perform their jobs. As an administrator, you’ll set up access requests for users and configure approval processes for these requests.

Configuring Access Requests

Complete these tasks to configure access requests for your site. These configurations impact system behaviors, user options, and data in the access request process.

1. Configure which items can be requested from your roles, access profiles, and entitlements.
2. Set each item's required approval process. For roles and access profiles, set the approval process individually for each. For entitlements, set the global configuration and optionally specify overrides per entitlement.
3. Define segments if you need to restrict who can submit access requests for certain items.
4. Specify whether users can make requests for others in addition to themselves.
5. Set global site settings like email reminders and escalations for the review process.

Understanding Access Requests

The access request process includes these key steps.

1. Users submit access requests.

   Users can submit access requests to obtain access to entitlements, roles, and application access profiles. All users can make requests for themselves.They may also be able to request for others. Requests can optionally include an expiration date for the access.

2. Reviewers approve or deny access requests.

   If access requires approval, reviewers review the access requests submitted by other users. The requests include details about the user the access was requested for to help the reviewers make their decisions.

   Note

   By default, the user's display name and their manager's email display in the Identities tab. You can add up to 5 additional attributes using the Update Public Identity Config endpoint.

3. If approved, the access item is provisioned.

   The user retains this access until the access expires or is revoked.

4. If an expiration date was specified, the system initiates revocation as scheduled.

   If Identity Security Cloud is directly connected to the source system, the access is automatically deprovisioned.

   Notes

   • The expiration date is not sent to the source system as an account attribute.

   • The Request Center supports specification of expiration dates but not times. On the specified date, Identity Security Cloud triggers the deprovisioning process at 12:00 AM in the time zone set on the requester’s browser.

     • Requests submitted through Identity Security Cloud's API using the Submit an Access Request endpoint can include a time component as part of the removeDate attribute to control the deprovisioning time.

   If Identity Security Cloud is not connected to the source system, a manual task to remove this access is created and assigned to the source owner. The source owner removes this access in the source.

Troubleshooting Access Requests

A user submitted a request but it does not appear in their My Requests list.

When a request encounters an error that prevents it from being processed, the requester receives an email notification, and the request is not included in their My Requests list. For example, the user may already have the requested access or have multiple accounts on the source.

An access request's Account Activity record in Search contains the warning, "Delayed provisioning due to an existing provisioning request for creating an account on the same source with the same nativeId."

When a user does not have an account on a source where an entitlement is requested, Identity Security Cloud will automatically create the account. If multiple entitlements are requested on that source for the user at or around the same time, only the first entitlement is turned into an account creation request. Provisioning for other entitlements is paused until the account creation request completes so they can be added to the new account through update operations.

Reviewing Access Request History

You can review the history of access requests and their approval decisions through search by querying Event records.

Use the search string “Request Access” (include the quotes to search for both words together) to see a number of different event records related to access requests. Add additional criteria to narrow down your search to specific actors or access recipients. Search for events that include a specific user by adding either && or AND, then the username. For example, to search for access requests associated with user Alice.Carter, enter “Request Access” && Alice.Carter.

Search results include events such as:

• Request Access Started – The original submission, including who requested what for whom.
• Request Access Approved – User who approved the requested item for the user.
• Request Access Rejected – User who denied the request.
• Request Access Cancelled – User who cancelled the request before the approval or processing was finished.
• Request Access Processed – The actual provisioning of the item.

Search records also include Request Access Escalated, which lists the new owner of an escalated request. This is not listed by access recipient, but if the new owner completes the approval you can trace the request to a Request Access Approved entry.

By default, the event records display the action as named above, the Actor who completed the action, the Target who the action was focused on, and a timestamp of the action. Use the Column Chooser icon to customize your view. Adjust the columns to display Details and Source Name so your search results will include item name and source.

Select the Download icon to export search results to a CSV for offline analysis, sorting, and filtering.

Documentation Feedback

Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.