Creating pre-requisite conditions for access request

[ugochuik (Ike Ugochuku)]

REQUIREMENT

We want users to request entitlement C only if they already have entitlements A and B. A Separation of Duties (SoD) policy won’t help here, as it’s meant to block access—not require it. Similarly, organizational policies in ISC are designed to restrict access, not to enable it based on prerequisites.

SOLUTION

STEP 1: Create AD groups

Open ADUC

Create 2 AD groups (SGIdentityNow1 and SGIdentityNow2) and add the user to the 2 groups. Write down the distinguished names of the groups

Create another AD group (DLIdentityNow2) which will be the Target group

Sync up the information to SailPoint

STEP 2: Create Identity Pre-req attribute

Go to the Identity profile

Create an attribute called “SaganPrereq”

STEP 3: Create and upload Transform rule

Create the following Transform rule to check if user is member of the two groups created. If so then set SaganPrereq to complete else notcomplete. The group DN is case sensitive so it must match exactly what is in AD

{
  "attributes": {
    "group1Match": {
      "attributes": {
        "values": [
          {
            "type": "accountAttribute",
            "attributes": {
              "attributeName": "memberOf",
              "sourceName": "MYAD",
              "accountPropertyFilter": "(memberOf.contains(\"CN=SGIdentityNow1,OU=MYIdentityNow,OU=SailpointUsers,DC=mydomain,DC=net\"))"
            }
          },
          "false"
        ]
      },
      "type": "firstValid"
    },
    "group2Match": {
      "attributes": {
        "values": [
          {
            "type": "accountAttribute",
            "attributes": {
              "attributeName": "memberOf",
              "sourceName": "MYAD",
              "accountPropertyFilter": "(memberOf.contains(\"CN=SGIdentityNow2,OU=MYIdentityNow,OU=SailpointUsers,DC=mydomain,DC=net\"))"
            }
          },
          "false"
        ]
      },
      "type": "firstValid"
    },
    "value": "#set($out = 'noncomplete')#if($group1Match != 'false' && $group2Match != 'false')#set($out = 'complete')#end$out"
  },
  "type": "static",
  "name": "MYSetSaganprereq"
}

Go to Postman

Go to Create Transform on the V3and Post the code

STEP 4: Update identity attribute

Go to Identity Profile

Update the seganprereq attribute with the transform rule uploaded

• Source: MYAD
• Attribute: memberOf

STEP 5: Create an access request profile

Create an access request for the third group created in Step 1.

Go to Access Profiles

Click Create New

• Name: MY Access DLIdentityNow2
• Owner: Myself
• Source: MYAD
• Manage Entitlements: DLIdentityNow2
• Access Request: Enabled

STEP 6: Create an access request segment

Go to Access Model/Segments

Click New

• Name: IdentityNow2 Prereq
• Description: Declare pre-req to request for DLIdentityNow2
• Click Define segment
• Attribute: Saganprereq
• Value: complete
• Access: MY Access DLIdentityNow2
• Enabled: Yes

STEP 7: Make a request

1. Login as a user
2. Go to request access and make sure you cannot see the Access Profile for DLIdentityNow2
3. Add a user to the two in scope groups
4. Aggregate the information to SailPoint MYAD
5. Verify that saganprereq attribute is updated to “complete”
6. Go to request access and make sure you can see the Access Profile for DLIdentityNow2

[TheOneAMSheriff (Amar Sheriff)]

Hi @ugochuik,

Very interesting use case and solution. Thank you for sharing your expertise.

I would like to understand if you also had disable Enable Request On Behalf Of in system features of Access Request? As I understand segmentation do not apply on the recipient but the requester as of now in SailPoint ISC. Which imply if I am having the pre-requisite groups, I would be eligible to request the additional access/entitlement for anyone in the tenant if Enable Request On Behalf Of is enabled.

Regards,
Amar Sheriff

[ugochuik (Ike Ugochuku)]

Hi @TheOneAMSheriff
No I did not disable enable request on behalf of (will affect all requests). Segmentation only filters out the access request if you don’t meet requirements, so if I have met the requirements, the access request shows up and I can request on behalf of someone else who does not meet the requirements. Which can be good or maybe not-so-good. There are exceptional instances when the requirement might be to bypass the requirement filter. But, you raise up a potential gap and should be discussed with the customer to educate the users.

[moises_proof (moises roth)]

Hi everyone!

I’d like to share another suggestion for restricting access to a group based on certain prerequisites:

• The idea is to create a role with the condition: the user must be part of My_Group_A, My_Group_B, and My_Group_C_Dummy.

• This role will then grant the group My_Group_C.

In this setup, My_Group_C is not requestable — only My_Group_C_Dummy is. So even if someone tries to request access, they can only ask for the dummy group.

I know this doesn’t completely hide My_Group_C from being visible (especially if the naming is similar), but it does prevent users from gaining access directly. They’ll only get My_Group_C if they meet all the conditions — which adds a nice layer of control.

To streamline this process, a script could be developed to create these roles automatically, especially if we have a large number of groups requiring this type of control.

Let me know if anyone has tried something similar or if this was helpful in any way!

Regards,
Moisés Roth

[ugochuik (Ike Ugochuku)]

That is not the desired goal, we are talking about 2 different use cases. You do not get Group_c because you have Group_b and Group_a, but you get the ability to ask for Group_c. Not everyone who has group_b and group_a should get group_c. Group_c access request must still go through request review an approval. The group_c dummy you presented can be requested by anyone and so does not meet the desired goal.

[moises_proof (moises roth)]

Hi Ike,

Thanks for the feedback!

I believe there might have been a misunderstanding regarding the proposal. The goal is not to grant automatic access to My_Group_C just because someone is in My_Group_A and My_Group_B. The idea is that access to My_Group_C should still go through an approval process (through the My_Group_C_Dummy group).

The idea is that only users who are pre-approved (after a proper review, of course) would receive My_Group_C_Dummy, and only then, if they also have My_Group_A and My_Group_B, access to My_Group_C would be granted automatically through a role.

Apologies if I mixed up the topics or didn’t explain it clearly enough at first.

I believe segments remain the best option, though I’m unsure how practical this approach is when managing dozens or even hundreds of “restricted” groups.

[ugochuik (Ike Ugochuku)]

I get your idea and its a solution option. I dislike the extra work of an approval for a false positive since this can be requested by anyone. If you are dealing with say Top secret access then the ability to request for access may be a gap even though it will be reviewed.
In terms of scalability, yes it can be setup for any set of folders to be restricted. A form workflow request piped to a webhook will use api to set everything up and also to make amendments.

[rahulb635 (Rahul Reddy)]

in step 6, shouldnt value be as
Value:Complete ?

[ugochuik (Ike Ugochuku)]

You are correct Rahul. I have updated the post. Thanks