Before Provisioning Rule to Change Modify Operation to Delete

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

We have webservice source that does not support entitlement removal. Accounts only get 1 entitlement, and if that entitlement would be removed (either by role assignment change or access review revocation) the account needs to be deleted instead.

We are using the “Services Standard IdentityNow BeforeProvisioning Rule” successfully already to change disable operation to delete when a user changes to inactive with this eventConfiguration:

{
                    "eventActions": [
                        {
                            "Action": "ChangeOperation",
                            "Attribute": null,
                            "Value": "Delete"
                        },
                        {
                            "Action": "RemoveEntitlements",
                            "Attribute": "Admin_Type",
                            "Value": null
                        }
                    ],
                    "Identity Attribute Triggers": [
                        {
                            "Attribute": "cloudLifecycleState",
                            "Value": "inactive",
                            "Operation": "eq"
                        }
                    ],
                    "Operation": "Disable"
                }

I have tried adding the below to change any modify operation to a delete operation, but I am not seeing the expected results.

                {
                    "eventActions": [
                        {
                            "Action": "ChangeOperation",
                            "Attribute": null,
                            "Value": "Delete"
                        },
                        {
                            "Action": "RemoveEntitlements",
                            "Attribute": "Admin_Type",
                            "Value": null
                        }
                    ],
                    "Operation": "Modify"
                }

Has anyone run into anything similar?

2

I’ve used the Services Standard IdentityNow BeforeProvisioning Rule on AD and Okta sources, but never on a Web Services source. It may be supported, but the documentation says to use a Web Services Before Operation Rule to change the operation to delete.

Also, make sure to define the Delete Account operation in the HTTP Operations.

Matt

3

Hi @aberkey!

For the Standard Service Before Provisioning rule, you need Trigger(s) and Action(s). In your first configuration, you have the “Identity Attribute Trigger” defined with the “Disable” operation. The operation is one component of the trigger, and you also need to define the trigger itself.

For your second example, you do not have a trigger defined, only an Operation and the Actions. Given your use case, I think you would either want to use the “Entitlement Update Triggers” trigger or the “Entitlement Cardinality Update Triggers” depending on what works best for you.

Entitlement Update Triggers:

{
    "eventActions": [
        {
            "Action": "ChangeOperation",
            "Attribute": null,
            "Value": "Delete"
        }
    ],
    "Entitlement Update Triggers": [
        {
            "Attribute": "groups",
            "Operation": "Remove",
            "Value": "*"
        }
    ],
    "Operation": "Modify"
}

In the above configuration, anytime there is a Remove operation for the specified entitlement type (in my example, ‘groups’), the account will instead be deleted.

Entitlement Cardinality Update Triggers:

{
    "eventActions": [
        {
            "Action": "ChangeOperation",
            "Attribute": null,
            "Value": "Delete"
        }
    ],
    "Entitlement Cardinality Update Triggers": [
        {
            "Attribute": "groups",
            "Operation": "LastRemoved",
            "Value": null
        }
    ],
    "Operation": "Modify"
}

In the second configuration above, this checks if the last entitlement is being removed for the defined type (again using ‘groups’ as an example), and then instead changes the operation to Delete the account.

The “Entitlement Update Triggers” option seems sufficient for your use case since accounts should only have one entitlement, but in case there is the chance they can have more than one, you may want to use the “Entitlement Cardinality Update Triggers” configuration instead.

Additionally, the “RemoveEntitlements” action in your original configuration doesn’t seem necessary since this rule is already being triggered on a Modify operation to remove the entitlements so having another action to remove the entitlements would be redundant (unless there is an additional requirement for this not specified).

Please let me know if this helps!

  • Zach
4

Ah that makes sense. I knew I was missing something about the triggers. We currently use this for lifecycle changes to modify disable to delete operations. So am confident that the rule/source can do what I want it to.

Here is an example of that changes disable to deleted when a user’s cloudLifecycleState changes (this is currently operating as intended):

                {
                    "eventActions": [
                        {
                            "Action": "ChangeOperation",
                            "Attribute": null,
                            "Value": "Delete"
                        },
                        {
                            "Action": "RemoveEntitlements",
                            "Attribute": "Admin_Type",
                            "Value": null
                        }
                    ],
                    "Identity Attribute Triggers": [
                        {
                            "Attribute": "cloudLifecycleState",
                            "Value": "inactive",
                            "Operation": "eq"
                        }
                    ],
                    "Operation": "Disable"
                }

However when I try with your suggestion below, its acting a bit strangely.

                {
                    "eventActions": [
                        {
                            "Action": "ChangeOperation",
                            "Attribute": null,
                            "Value": "Delete"
                        }
                    ],
                    "Entitlement Update Triggers": [
                        {
                            "Attribute": "Admin_Type",
                            "Value": "*",
                            "Operation": "Remove"
                        }
                    ],
                    "Operation": "Modify"
                }

The account drops off the identity, but the source account is unimpacted. After aggregation, the ‘deleted’ account gets re-correlated to the identity…

5

Thanks Matt. We are using this rule already for this source. On lifecycle changes, it will change disable to delete operation.

6

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