POST /api/user/updatePermissions

Identity Security Cloud (ISC) Non-Public API Deprecations
1

Replaced by

https://developer.sailpoint.com/idn/api/v3/patch-auth-user

Add capabilities

Use the following patch body to add one or more new capabilities to a user.

[
  {
    "op": "add",
    "path": "/capabilities/-",
    "value": "HELPDESK"
  },
  {
    "op": "add",
    "path": "/capabilities/-",
    "value": "REPORT_ADMIN"
  }
]

Remove capabilities

To remove capabilities, it is recommended to first get the list of capabilities the user has by calling https://developer.sailpoint.com/idn/api/v3/get-auth-user. This will provide you with an array of capabilities that the user currently has.

{
    "tenant": "devrel",
    "id": "2c9180867dfe694b017e208e354c57c0",
    "uid": "aaron.nichols",
    "profile": "c1b86aa411764a11b7851f281e5d6ee9",
    "identificationNumber": "1c",
    "email": "[email protected]",
    "phone": null,
    "workPhone": null,
    "personalEmail": "[email protected]",
    "firstname": "Aaron",
    "lastname": "Nichols",
    "displayName": "Aaron.Nichols",
    "alias": "Aaron.Nichols",
    "capabilities": [
        "HELPDESK",
        "ROLE_ADMIN"
    ],
    "lastPasswordChangeDate": null,
    "lastLoginTimestamp": 0,
    "currentLoginTimestamp": 0,
    "lastUnlockTimestamp": null
}

Then, craft a PATCH request that uses the replace operation. This will require you to provide the full list of capabilities you want the user to have, minus any you don’t want them to have. It’s best to copy the capabilities from above and use them in your replace operation, minus the ones you don’t want. For example, if you wanted to remove the “ROLE_ADMIN” capability from the user above, you would use the following PATCH request payload.

[
  {
    "op": "replace",
    "path": "/capabilities",
    "value": [
        "HELPDESK"
    ]
  }
]

You can also use the remove operation, but it requires you to know the index of the item you want to remove.

[
  {
    "op": "remove",
    "path": "/capabilities/0"
  }
]
1 Like
2

Not sure if it’s just me but patch operation is not working properly for remove operation.

I have identity with helpdesk and cert admin capabilities. If I use below body for removing helpdesk access , it is removing all existing capabilities and not just helpdesk.

[
  {
    "op": "remove",
    "path": "/capabilities",
    "value": ["HELPDESK"]
  }
]

Further testing shows add is not working for addition but it is actually replacing whatever you pass in body.

3

We have detailed documentation on how to properly configure a patch request. The specifics of the remove operation are documented here:

In short, remove does not consider the value, only the path. So in your example above it is the expected behavior that you will remove all capabilities. If you only wanted to remove a single capability, you have to provide the index to that capability, but I wouldn’t recommend this since not all of our APIs guarantee the same order in a list.

Instead of remove, I recommend you use replace, and specify the list of capabilities you want the user to have.

1 Like
4

Yup! … due to the change in functionality we are now dealing with race condition when trying to add/remove multiple entitlements!!
As each “Add/Remove Entitlement” is processed independently but concurrently, so it’s a luck of the draw as to when each operation retrieve “current” state to update to new state. Most of the time the end result is incorrectly overwritten.

We have had to introduce (in WSBO rules) specific “Sleep X seconds” delay unique to each entitlement to ensure that they get process sequentially!

5

We are also using this in webservice source and you can stop race condition by using option

addRemoveEntInSingleReq

to true. Get current entitlement list using api in before rule and then setting new list based on add/remove option.

1 Like
6

Wow - Thanks @chirag_patel for that! :+1:
I did look for it in the UI, but of course didn’t check the documentation for a backdoor setting :stuck_out_tongue: doh!

1 Like
8

Hello all.

We have a problem with the new API, and the way in which we configure in a specific “webservices” source.

We are managing the internal permissions through a dedicated Source: the permissions (capabilities) are translated into “entitlements” , and they are then aggregated through this source that connects to IdentityNow itself. We created Roles around them, and a standard approval process.

When it comes to REMOVING capabilities, however, we were able to associate in the source the Remove Entitlement action with an API call to actually remove the capability in scope. In the old format, we were able to specify what we wanted to have removed. Now, however, we need to specify what we want to keep instead… but a provisioning plan for a Remove Entitlement action does not contain that… it only contains the actual entitlement to remove.

So, in short: in order to fire off an effective API call, associated to a Remove Entitlement action, we would need “a priori” knowledge of what a user needs to keep instead (not in the Plan), or knowledge or the index of the array to target (also, not in the Plan).

How can we get out of this situation?

Thank you
Fabio Carraro

1 Like
9

Same problem here :eyes:
I don’t know if there is a simple solution, or need to migrate to something like IDN loopback connect (not tested on my side)

10

You could use replace instead of remove when executing the PATCH auth user endpoint. First, you would need to get the current list of capabilities assigned to the user by running get-auth-user | SailPoint Developer Community. Save the array of capabilities as a new variable, and then remove the capability in that array as per the entitlement you received in your “Remove Entitlement” action. With the capability removed from the array, you know have an array of capabilities that the user should have, minus the capability the user should not have. Then, you can invoke the PATCH auth user endpoint as follows, passing your modified array of capabilities into the value field.

PATCH /v3/auth-users/:id

[
  {
    "op": "replace",
    "path": "/capabilities",
    "value": ["CAP1","CAP2","CAP3"]
  }
]
11

You need to update your Web Services source to use multiple calls and a rule when removing an entitlement:

  1. Get Current Capabilities
    • Hits GET /v3/auth-users/$getObject.nativeIdentity$ to get current capabilities
  2. Remove Capability
    • Hits PATCH /v3/auth-users/$plan.nativeIdentity$ where you either perform replace passing in the list of capabilities to retain OR perform remove passing the index of the capability to remove (i prefer this method)
    • Either option will require a WebServicesBeforeOperation rule to inspect the response from the first call where you get the list of current capabilities to remove from. In this rule you can calculate the index of the capability to remove or build the new list of capabilities to retain and set the body of the HTTP request in the requestEndPoint object
1 Like
12

Wow - Thanks for this…

13

I am also using this in webservice source in one of calculator base website, it’s great fr…