Add/Remove operations on Beta Patch Roles/Access Profiles endpoints

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi all, I’ve been trying to make use of the Beta Patch endpoints for updating Role / Access Profile properties, specifically in order to update the underlying access items (access profiles for roles and entitlements for access profiles) using the add/remove operations.

However, even though the calls seem to go through correctly, the result of the operation always reflects a replace, rather than an add. For example - trying to add an access profile to a role that already has 1 other access profile attached to it results in the original access profile being replaced with the new one.

Am I missing something here or are these endpoints not working correctly?

Thanks in advance.

API endpoints in question:

Payload example:

[
    {
        "path": "/entitlements",
        "value": [
            {
                "type": "ENTITLEMENT",
                "id": "2c91808478180476017825f6d4423f8b",
                "name": "Entitlement name"
            }
        ],
        "op": "add"
    }
]
2

Hello @Prooxie,

I just got the same results myself using the sample payload defined in the documentation for Access Profiles specifically to add an entitlement.

[
  {
    "op": "add",
    "path": "/entitlements",
    "value": [
      {
        "id": "2c9180857725c14301772a93bb77242d",
        "type": "ENTITLEMENT",
        "name": "AD User Group"
      }
    ]
  }
]

I suspect this is a defect. :frowning:

4

The PATCH operation can be tricky when trying to modify arrays of data. The RFC docs for the add operation are a little sparse. Based on the payload example you provided, you are correct that the outcome of the operation is essentially a replace. This is because you are adding a brand new array to the /entitlements array, which will overwrite the existing array. If your intention is to add an entitlement to the existing array, then try the following payload.

[
    {
        "path": "/entitlements/0",
        "value": {
                "type": "ENTITLEMENT",
                "id": "2c91808478180476017825f6d4423f8b",
                "name": "Entitlement name"
        },
        "op": "add"
    }
]

There are two differences in this payload.

  1. I specified where the new entitlement should be inserted into the existing array, in this case at index 0 (i.e. the beginning of the array). Not all collections honor a specific ordering of array elements, so it may not matter where you place it.
  2. I changed the value from a list of entitlement objects to just a single entitlement object.
3 Likes
5

Hi @colin_mckibben ,

thank you very much for your detailed reply.

Indeed, you were right and I have since successfully managed to make the add work correctly based on your recommendation.

That being said, I am now struggling with the other side of the same coin - removal of an access profile / entitlement.
More specifically, I haven’t found a reliable solution for identifying the position of a specific access profile or entitlement within the nested array.

I am retrieving a single object (in this example a role) using the Beta GET endpoint (get-role | SailPoint Developer Community) and looking at the array stored within the accessProfiles property.
However, it seems that the order of this array is completely arbitrary, as adding/removing an access profile completely re-shuffles the array.
Furthermore, even if I do try and follow that order and use the position within the array as the path for the PATCH call (patch-role | SailPoint Developer Community), I somehow end up removing a different access profile than expected.

Example payload (should be following the spec):

[
  {
    "path": "/accessProfiles/3",
    "op": "remove"
  }
]

This ends up removing a different access profile than the one returned on the 4th position of the nested array retrieved by the GET request.

6

Hey @Prooxie,

This is definitely an issue, and would impact any patch calls being used to update the entities.

I was able to replicate this issue on both role, and access profile api calls in my tenant.

I am having the defects looked into internally, and I will update this comment when I have more information.

Thank you so much for posting!

1 Like
7

Is this still true? I am attempting to use /v3/roles to remove specific Access Profiles from a large number of Roles. Every operation I have attempted so far either removes all Access Profiles or gets a 400 response in return.

Is the removal of a single access profile from a Role not currently supported?

8

Hey @Prooxie, @Kurt_Ramsey,

I wanted to follow up here and just let you know that internal case is still ongoing, I do not have any substantial updates yet that I can share regarding the status of the case, but it is still open.

I hope you are all having a good week.