Disable account via transformation

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

Hi everyone, I created a transform that checks if an identity has entitlements from a specific source (using the source ID).
The idea is that if the transform returns false, the account gets disabled via the account deactivation policy; however, it doesn’t seem to be working.

transform:
“value”: “#set($links = $identity.getLinksByAppIdOrName(“ID_SOURCE”, null))#set($hasEntitlements = false)#foreach($link in $links)#if(!$link.getEntitlementAttributes().isEmpty())#set($hasEntitlements = true)#end#end$hasEntitlements”

I apply this policy, for example, to the IIQDisabled attribute within the AD disable provisioning policy:
{
“name”: “IIQDisabled”,
“transform”: {
“type”: “static”,
“attributes”: {
“hasAccess”: {
“type”: “static”,
“attributes”: {
“value”: “#set($links = $identity.getLinksByAppIdOrName(“ID_SOURCE”, null))#set($hasEntitlements = false)#foreach($link in $links)#if(!$link.getEntitlementAttributes().isEmpty())#set($hasEntitlements = true)#end#end$hasEntitlements”
}
},
“value”: “#if($hasAccess == ‘false’)true#{else}#end”
}
},
“attributes”: {},
“isRequired”: false,
“type”: “string”,
“isMultiValued”: false
}

However, it isn’t working. Has anyone encountered a similar issue?

2

The IIQDisabled attribute accepts only true or false values. The source account will be marked as disabled when the IIQDisabled attribute is set to true. Could you please verify your code and confirm what value is being returned? If the returned value is true, the source account should automatically be marked as disabled.

3

Hello Guilherme. A transform inside the Disable provisioning policy cannot initiate a disable on its own. The policy only runs when ISC is already processing a Disable request, so the transform only calculates the attribute values included in that request. (Transforms in Provisioning Policies)

If the entitlement removal is provisioned through ISC, you could try a Provisioning Completed workflow filtered for successful Remove operations from that source. The workflow can use Get Accounts to check hasEntitlements for the account on that source and, when none remain, use Manage Accounts with the Disable action for the AD account.

This runs after the provisioning action completes, so it should not interfere with the original entitlement removal. I would suggest testing whether hasEntitlements reflects the removal immediately for your connector; if it only updates after aggregation, the Account Updated trigger may be a better fit.