Remove requested entitlements on termination

We have a requirement to remove all AD groups from a user account on termination. We are currently handling this through the Service Standard Before Provision rule.

What we are seeing, however, is that any AD entitlements that were added to the user’s account via the Request Center are immediately getting added back to the account after termination processes.

We do receive a provisioningPlan with each of the ‘remove’ attributeRequests, but seconds later, we get a second provisoningPlan adding them all back.

Is there a way to remove these entitlements from the account on termination without making a separate API call to IDN backend? Or at least to be able to prevent their being added back?

I guess you are removing the entitlements but not the Roles.

You can make use of workflows.

We may need to remove requested roles, access profiles, and entitlements. In this case, the entitlements were requested directly (not through a role or access profile).

By using workflows, do you mean trigger a workflow on termination, loop through every entitlement, role, and/or access profile on the identity and submit an HTTP request back to IDN to remove each?

Is there no way to do this through standard lifecycle changes and beforeProvision rule?

Hello @dopstrick , I believe your issue is happening because those removed entitlements are either mapped to requestable roles or access profiles for the terminated users.

I also feel workflow is best suited for this use cases.

Hello @gauravsajwan1 ,

In this case, the entitlements are not mapped to a role or access profile. I requested the entitlements directly through Access Request center for this user. The user in question has no roles or access profiles associated with them. This is a test user in our Sandbox environment that was created for testing termination operations.

Hi Dylan,

What you can do is create a new method in Service Standard Rule with the name removeStickyEntitlements and have the following added.

public void removeEntitlementsStickiness(Identity identity, AccountRequest accountRequest, String attribute)
{
log.debug("Enter removeEntitlementsStickiness: " + attribute);
if(accountRequest == null)
{
log.error(“RemoveEntitlements: Invalid Arguments: accountRequest is null”);
return;
}
if(attribute == null) {
log.error(“RemoveEntitlements: Invalid Arguments: attribute is null”);
return;
}
if(identity == null) {
log.error(“RemoveEntitlements: Invalid Arguments: Identity is null”);
return;
}

	Account account = getAccount(identity, accountRequest);
	AccountRequest.Operation op = accountRequest.getOperation();
	if(null != idn.getRawAccountAttribute(account, attribute) && op!=null)
	{

		List ents = asList(idn.getRawAccountAttribute(account, attribute));
		if(ents != null) 
		{
			for (String ent:ents)
			{
				AttributeRequest attrRequest= new 
                                    AttributeRequest(attribute, ProvisioningPlan.Operation.Remove,ent);
				attrRequest.put("assignment", true);									
				accountRequest.add(attrRequest);									

			}	

		}
	}
	log.debug("Exit removeEntitlementsStickiness");
}

Once done please configure a trigger like below

[

{

    "op": "add",

    "path": "/connectorAttributes/cloudServicesIDNSetup",

    "value": {

        "eventConfigurations": [

            {

                "eventActions": [

                    {

                        "Action": "RemoveEntitlementsStickiness",

                        "Attribute": "memberOf",

                        "Value": null

                    }

                ],

                "Identity Attribute Triggers": [

                    {

                        "Attribute": "cloudLifecycleState",

                        "Value": "inactive",

                        "Operation": "eq"

                    }

                ],

                "Operation": "Disable"

            }

        ]

    }

}

]

Let me know if you face any issues in the same

Thank you, Rakesh,
This is fantastic. I wasn’t sure how the ‘sticky’ was represented on the object.

One question, does this now create the reverse scenario, where the removal is now sticky?

Is there a way to remove the ‘assignment’ flag entirely?

Regards

Hi Dylan,
The assignment flag is something internal to Sailpoint IdentityNow which we cant remove by default. If you are requesting some entitlement from request center it gets added automatically.

Thanks
Rakesh Bhati

Hi Rakesh,

Sorry, I meant in the Service Standard rule update, if I add an ‘assignment’ flag to the removal attributeRequest, does that removal then become sticky? If so, is there any way to prevent that?

Regards,

Hi Dylan,
No it does not. You can add it

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