REVOKE_ACCESS request is failing

[shreyas_nitturkar]

We are using a workflow to remove the entitlements assigned to a user when a particular event occurs.

The trigger is working well but the REVOKE_ACCESS request submitted using the Submit Access request API is not consistent in removing the entitlements.

We have ENSURED that the entitlement being removed is:

1. Passed one at a time in the request
2. the entitlement being removed is revocable i.e not assigned via any role/ birthright / via access profile.
3. user submitting a request is an ORG_ADMIN

The behaviour is highly inconsistent and mostly works if retried 2-3 times. How to ensure that the access request when submitted is 100% revoking the entitlement?

[KRM7 (Krishna Mummadi)]

What is the error you are getting, 400 error ?

[shreyas_nitturkar]

No error. it says request processed but the entitlement is not removed.

[nhassan (Noor Hassan)]

Hi @shreyas_nitturkar

Could you try using the ‘Send Email’ action after ‘HTTP Request’ step to see what’s the output or error message/status code?

In the ‘Send Email’ action,
set ‘Body’ to $.hTTPRequest.statusCode

OR set ‘Body’ to $.hTTPRequest.body

Also, try setting the JSON Request Body in the HTTP Request as below.

{
“requestedFor”: [
“Id-of-the-Identity”
],
“requestType”: “REVOKE_ACCESS”,
“requestedItems”: [
{
“type”: “ENTITLEMENT”,
“id”: “Id-of-the-Entitlement”,
“comment”: “Revoking access via workflow”
}
]
}

[margocbain (Margo Bain)]

Any chance this is for AD and you also have an OU move happening around the same event? I’ve seen this behaviour before in cert workflows with auto-revoke steps because the DN is changing in the middle of the REVOKE_ACCESS step. ISC can interpret the access as already removed because it can’t locate the account

[shreyas_nitturkar]

I was able to resolve other syntax related issues in Workflow but for one of the entitlements is still failing with the attached error:

[nhassan (Noor Hassan)]

Regarding this one entitlement that is still failing to be revoked, did you check this might have been granted via birth right access i.e a dynamic role or access profile having this entitlement or the entitlement itself tied to a role and the user is a member of that role, in which case this would fail?

The basic rules of ISC access management still apply i.e only requested roles (not auto-assigned ones) and entitlements that exist outside of roles and access profiles will be revocable.