Skip to content

Configuring Access Requests

To get started with Access Requests, you'll first need to configure the basics. When your foundation data is set up, you can begin configuring access requests for access profiles and roles. 

Configuring Access Profiles

You can create access profiles that represent access to specific data and systems, and each access profile can be associated with one or more apps. When a user requests that access profile, any apps associated with it are added to their Launchpad if that request is approved.

Create an Access Profile

An access profile is a group of one or more entitlements that grants a specific set of access associated with a source. Access profiles provide you with a lot of flexibility when you are provisioning access to your identities, based on various scenarios you need to support. Access profiles serve many functions:

  • For Provisioning: Identities can be granted the entitlements in the access profile and an account on the source the entitlements come from automatically. You can also define and grant roles.

  • For Certifications: Access profiles allow your reviewers to see bundles of access that clearly define what a user can and can't do, so that they can review that access more effectively. Bundling entitlements into access profiles allows you to certify an easily-readable access profile representing a set of access, rather than an individual entitlement.

  • For Access Requests: Assigning access profiles to apps allows your users to request access to an app. If the request is approved, the app and the access profile associated with it are granted to the user.

Prerequisite: Load accounts and entitlements from at least one source.

1. From the Admin interface, go to Access > Access Profiles.

2. Click New.

3. Enter a Name and Description for your access profile.

Best Practice

Be sure the name and description of your access profiles are user-friendly, meaning descriptive and easy to understand. This will allow reviewers to process more easily, make good decisions about specific access profiles, and improve the accuracy and quality of the access granted when the access profile is assigned to an app or included in a certification campaign. The character limit for this description is 2000 characters.

4. Choose the source that contains the entitlements you want to use in this access profile.

5. Select an owner for your access profile. If you have the Access Request service enabled for your site, the access profile owner can be configured to review access requests.

6. If necessary, configure an approval process for your access profile. 

7. Select one or more entitlements for your access profile.

8. Select Save. The access profile appears in your list of access profiles. You can select the access profile to view the entitlements it contains at any time.

Configuring Access Requests for Apps

If you want to require approval for an app before users can add it to their Launchpads, you can assign an access profile that requires approval to that app. The app will appear on the Launchpads of all users who have that access profile or its entitlements automatically.

1. From the Admin interface, go to Access > Access Profiles.

2. Create access profiles, or select existing access profiles to edit them.

3. Under Access Request Approval Process, clear the checkbox beside No Approval Required.

4. Under Required Approvers, select an approver or governance group.

5. Select Add.

This user or group is added to the list of required approvers.

6. Choose any additional approvers or governance group that you want to review the access before it's granted to a user.

Each new user or group will be added to the bottom of the list.

Sometimes, the users requesting access will also be part of the approval process for that access. In this case, you can configure their approval step to be either auto-approved or reassigned to the requester's manager using the appropriate API.

Notes

  • You can add up to 100 access profiles per application. If you reach the limit, you'll need to remove access profiles from the application before adding more. You can reach out to your SailPoint CSM to extend this limit, however, exceeding the limit could negatively impact performance and is therefore not recommended.
  • Access requests assigned to a governance group to review cannot be auto-approved. If the requester is part of a governance group that is responsible for approving the request, the decision will be assigned to the other members.
  • If you have the Separation of Duties service for your site, requesters and reviewers will be automatically notified if granting an access request will put the recipient in violation of an SoD policy. If an access profile doesn't have any reviewers configured, no one is preemptively notified of the violation. It will still appear in violation reports.

An audit event is created for an auto-approval when the approvals are calculated after the request has been submitted.

For example, if there are 3 approvals in the approval chain and the second approver is the requester, the auto-approval audit event of the second approval will be logged before the first approver's decision. So even if the first approver denies the request, the second approval will still be shown as auto-approved in audit events.

7. If necessary, rearrange the approvers to reflect the order you want them to approve the access in.

The list reflects the order that approvers review the request. You can select as many reviewers from this list as you need.

If you select a governance group, anyone from that group may review and approve or deny the request.

Note

To remove a reviewer from the list, select the X icon by their title.

8. If you want to require the user to provide a comment or a reason for requesting the access, select the When User Requests checkbox under Require Comments.

If you select this box, the user will be required to enter a reason for requesting the access before they can submit their request for this access profile.

9. If you want to require the reviewers you selected in steps 5 and 6 to provide comments when they reject a request, select the When Approver Denies box.

If you select this box, when the reviewer of an access request will be required to enter a reason for denying access before their denial can be completed.

10. Select Save.

Note

If the access profile you're editing is assigned to an identity via roles or a lifecycle state, the approval process does not apply.

11. Go to Applications.

12. Select the application you want to edit.

13. Configure it so that only specific users from the source have the app.

14. Under Select Source, choose a source. The source you choose must be enabled for provisioning.

15. Select Save.

16. Go to the app's Configuration tab.

17. In Request Center Options, select the Visible in the Request Center checkbox.

18. Select the Allow Access Requests checkbox.

19. Enable the app for users.

20. Select Save.

The app appears on the Launchpads of all users who already have the access profile you selected in step 11. This app also appears in the Request Center and can be requested by users.

If a user requests an app, each reviewer is sent the Access Request Reviewer email when the previous reviewer approves the request. If any one reviewer denies the request, the requester is not granted access and the approval process stops.

Configuring App Requests for Others

  1. Go to Admin > Global > System Features.

  2. In the System Features menu, under Access Requests, select the box for Enable Request On Behalf Of.

  3. Use the radio buttons to select Managers Only or Everyone, depending on who you want to have the ability to make access requests for others.

Fill out the required fields: Unique name, Role ARN, and External ID. Optionally add the CloudTrail ARN and select Sensitive Tags.

If someone requests access to an app and they're also a reviewer, the following workflow is used instead:

  • The request is delegated to the requester's manager.

  • If the requester is part of a governance group that's listed as a reviewer for the request, they aren't included in the review.

  • If they're the only member of that governance group, the request is delegated to their manager.

  • If the requester doesn't have a manager, the request is delegated to an IdentityNow administrator.