Request an entitlement to replace existing

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

We have this scenario where the application (web service connector) can only accept 1 group/entitlement at a time.
The attribute is configured like this in the schema:

{
            "name": "UserGroupId",
            "type": "STRING",
            "schema": {
                "type": "CONNECTOR_SCHEMA",
                "id": "",
                "name": "group"
            },
            "description": "UserGroupId",
            "isMulti": false,
            "isEntitlement": true,
            "isGroup": true
        },

The problem is when we try to send a request to change the user group, IDN keeps both, therefore not reflecting the actual account on the target and it sometimes retries too. How can we enforce the “Replacement” of the entitlement vs the “Addition” of one.
Also, a user can never be in a state where he doesn’t have a UserGroupId.

2

Hi Veronique,
This can be achieved using a Before Provisioning Rule. If you want to keep it internal then user workflow with the trigger of Access Request Decision

3

Hi Veronica,

If I understood correctly, then it is a sticky entitlement issue. Basically, if the access is requested through IDN, then it takes the IDN source as authoritative for the entitlement, hence it will not replace it easily. If you try, then it will try to re-add.
To handle this, you may need to write the logic to handle the stickiness in the Before Provisioning rule.
AttributeRequest attrRequest= new AttributeRequest(entName,ProvisioningPlan.Operation.Remove,ent);
attrRequest.put(“assignment”, true);
accRequest.add(attrRequest);

Thanks

4

Hi @veroniqueb I have recently the same issue (with jdbc connector, but this happens at the instance prior to provisioning). In this application, I had an entitlement marked as single-valued on schema, but asking new entitlements continues adding entitlements to account.

My solution was totally manual, tell client to first revoke old entitlement, and just there request the new one. Also, an aggregation from source removes the invalid entitlementes, but user will see until aggregation occurs.

Perhaps this manual solution can be solved with a worflow, acting after a provision is made, and deleting the old entitlement.

5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.