WebServiceAfterOperationRule for Deleting No Last Login Date

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

Hi All,

I have recently implemented a workflow to delete accounts of users with last login date after each aggregation of that specific application, however, the workflow has a lot of limitations especially when there are more than 250 accounts. Recursive workflow is also not an option in this case since I would need to have context defined inside the loop which is a limitation of recursive workflow.

With that, I am thinking if the Webservice After Operation rule could be utilize for this use case. Is this possible and if so, could anyone please share the basic logic or at least a template on how to do this since this is my 1st time using a web service after operation rule for such use case.

Thank you so much!

2

Hi @jasmedina ,

I think the key here is to have an appropriate trigger for HTTP Delete operation Web service connector source. Since workflows has its limitation, you can explore using attribute sync + Before provisioning rule approach.

Lets say -

  1. You have a generic attribute in your web service connector - deleteAccount and same identity attribute with its default value is false. You can enable attribute sync for this attribute.
  2. Configure HTTP Delete operation in your web service connector source config.
  3. When application aggregation happens, deleteAccount identity attribute value should be modified and set to true for the users with no last login date. An appropriate transform should be able to achieve this.
  4. Since attribute sync is enabled on this attribute, Modify event for deleteAccount is triggered.
  5. Deploy a Before Provisioning Rule which receives this request as Modify for deleteAccount. If the value of deleteAccount is true change the plan to have Account Request Delete operation instead of Modify. If you use Before Operation Rule instead of Before Provisioning Rule, you will need to change the request endpoint from Modify to Delete in this case.
  6. This will trigger the HTTP Delete operation for the required case

Just a word of caution that deleting accounts have a significant impact and usually disabling accounts is recommended. It is better to design and test the approach thoroughly.

HTH

Thanks,
Shailee

1 Like
3

Thanks for the idea, Shailee! I will check this out.

4

Hi @shaileeM,

I have done steps 1-3 but for step 1, I do not have a generic attribute that I can use in our web service connector so what I did was just create a new identity attribute deleteAccount and using a transform, it will set the value to true or false.

For step 4, I do not think it is possible to sync the attribute because I am getting this message:

image
image948×135 3.34 KB

For step 5, do you have a sample provisioning rule for such use case? I have tried updating our Before Provisioning Rule to check if the value of deleteAccount is true then it would proceed to change the plan to have Account Request Delete operation instead of Modify. I have tested this rule before without the deleteAccount condition and it was working as expected. I am just not sure if the update I did is correct or not since it is not giving any error in the Rule Validator but after aggregating the source, the identity with the deleteAccount attribute set to true is not getting deleted.

Am I missing something in the configuration?

Thank you!

5

Hi @jasmedina , you will have to add this new attribute in the Create Account mapping, mapped to the Identity attribute.

6

Hi @shaileeM! I added the new attribute in the Create Account mapping and mapped it to the Identity Attribute:

image
image769×435 12.9 KB

I configured the Before Provisioning Rule as well:

import sailpoint.object.*;
        import sailpoint.object.ProvisioningPlan.AccountRequest;
        import sailpoint.object.ProvisioningPlan.AccountRequest.Operation;
        import sailpoint.object.ProvisioningPlan.AttributeRequest;
        import sailpoint.object.ProvisioningPlan;
        import sailpoint.object.ProvisioningPlan.Operation;
        
        
            for ( AccountRequest accountRequest : plan.getAccountRequests() ) {
                Identity identity = plan.getIdentity();
        
                String deleteAlertOps = identity.getAttribute("deletealertops");
                
                if (deleteAlertOps == "true")  {

                     if ( accountRequest.getOp().equals( ProvisioningPlan.ObjectOperation.Disable ) ) {
                     accountRequest.setOp( ProvisioningPlan.ObjectOperation.Delete );
                     }   
                }   
            }
        }
    }

But when I tried aggregating, the accounts are still not getting deleted. I am not sure what seems to be missing in my configuration.

7

Hi Jasmine,

I believe deletealertops is the correct technical name of the new identity attribute which you created. The letter casing matters.

Also, you can try processing the identity once above is verified.

Thanks,
Shailee

8

This is the technical name in the Identity Profile
image

9

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