Hi Experts,
Is there an option to delete entitlements from the source other than using source reset
What is the type/connector of the source you are referring to ?
@rajeshs I’m trying to delete entitlements from Linux connector.
Thankyou @Sivakrishna1993
In our case, we are not doing entitlement aggregation explicitly to pull groups, instead the entitlements come from account aggregation. So i will be updating the Linux source with new IP address and will run unoptimized aggregation to only have new accounts. But my source will end up having old entitlements as well.
Hence I’m looking for some options other than reset to clear entitlements that gets created through entitlement aggregation.
Hey @chandramohans27!
Here’s the solution for deleting Entitlements on a Source (without resetting the Source) that I have been using.
Note: Don’t get attached to it, since it will be deprecated soon (POST /api/source/reset/)
Also Note: This has to be done in Postman directly. For some reason, it’s not working in the VSCode extension.
-
List all the Sources in your tenant using the List all sources in IdentityNow API:
GET {{baseUrl}}/beta/sources -
Get the ID of your Source and input it into the Get Source by ID API:
GET {{baseURL}}beta/sources/:id -
Search for cloudExternalId
-
Copy and paste the cloudExternalId into the cc/SourceReset API URL:
POST {{baseUrl}}/cc/api/source/reset/60***9<<This is the piece being deprecated soon -
NOTE BEFORE HITTING SEND: This will reset Account AND Entitlements on the Source!!!
i. Use the following endpoint to only reset ENTITLEMENTS:
POST https://{tenant}.api.identitynow.com/cc/api/source/reset/{cloudExternalId}?skip=accounts
ii. Use the following endpoint to only reset ACCOUNTS:
POST https://{tenant}.api.identitynow.com/cc/api/source/reset/{cloudExternalId}?skip=entitlements
iii. I would also like to NOTE, that when I tried using the ?skip=entitlements and ?skip=accounts flag on my requests, they didn’t work for me so I’ve just been resetting all the data on the Source for my tests.
-
Hit SEND, and the Entitlements should be reset and you can get back to testing!
Let me know if this works for you! Cheers!
3 Likes
@chandramohans27 have a look at this topic and the linked APIs that Colin updated in the first post. There was a lot of discussion around that original endpoint in the topic that you can review. It looks like there are now replacement APIs in the Beta collection that can be used, as on 4/11: POST /api/source/reset/
Here are the links that Colin referenced in the above post for faster access:
To reset all entitlements on a source, use reset-source-entitlements | SailPoint Developer Community .
To reset all accounts on a source, use delete-accounts-async | SailPoint Developer Community
1 Like
Hello @chandramohans27,
Maybe just try this API: delete-tagged-object | SailPoint Developer Community
- Tag the entitlements you tend to delete
- Collect the id of the objects
- Call the API: https://sailpoint.api.identitynow.com/v3/tagged-objects/ENTITLEMENT/:id
I think this might just work, and you do not need to reset all entitlements.
Best regards,
Hi, here for my two cents.
I tried the suggestion mentioned by @mike818148 as the documentation of that API does suggest that this would be the effect, but unfortunately the API DELETE v3/tagged-objects/ENTITLEMENT/:id only deletes all tags from the entitlement and removes the entitlement from the GET v3/tagged-objects API result. It does not actually delete the entitlement itself, so it is not a valid solution.
The solutions mentioned by @Bakhari and @gmilunich are the closest options I can find so far to delete an entitlement from the knowledge of Identity Security Cloud, but it is quite a nuclear option as it will then reset ALL entitlements from that source, not just the ones you wanted to be removed. This can have all kinds of nasty side effects such as:
1: You have to do another round of full entitlement aggregation to get the entitlements again
2: You lose all data on the entitlements added from Identity Security Cloud such as owner, description, approval flow. You have to add this back again.
3: You have to again map these entitlements to the corresponding access profiles and roles, since the mapping was removed as a consequence of the source entitlement reset. (I believe access profiles that lost the last entitlement will be disabled by default, so you would have to enable the access profiles again after adding the entitlements back, if you remembered which ones were supposed to be enabled)
4: All the entitlements that appear again during a next entitlement aggregation have a new entitlement id. I can imagine this will have an effect on searching for any history on this entitlement, like who had it or who changed it.
5: Roles can have membership criteria based on having a specific entitlement. If this entitlement was now temporarily absent during the entitlement reset (just because I wanted to delete a different entitlement that happened to be on the same source), and an identity that does (not) have this role will get an identity refresh, what will happen? I can imagine this having a bad effect on deciding whether the identity should have the role or not. I haven’t tested this myself.
So I am a strong advocate for having a dedicated API just like DELETE v3/entitlements/id and potentially a POST v3/entitlements/bulk-delete that allows us to give a bunch of ids of the entitlements that should be deleted.
Kind regards,
Angelo
6 Likes
Hello @angelo_mekenkamp ,
Thanks a lot for testing this out, I was browsing the API Spec, and thought that API might helpful in this case, unfortunately not…
And great summary on the case, and totally agree with you that there should be a possiblity to delete single entitlement or bulk-entitlement-deletion.
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.