Hi team,
I am working on JDBC and Web Services Connnector where we have to delete the uncorrelated account after each aggregation. Can you please suggest how we can achieve this use case.
Hi team,
I am working on JDBC and Web Services Connnector where we have to delete the uncorrelated account after each aggregation. Can you please suggest how we can achieve this use case.
When you say delete do you have to delete the actual account or remove it from SailPoint ISC account list for your source.
@Faizan854187 can you please elaborate more on the requirement?
Hi @rajeshs ,
My requirement is simple that we dont want any uncorrelated account in ISC but we dont have any filter or anything to filter out uncorrelated account during aggregation so we want that as soon as aggregation completed in that particular source we can run remove the link of uncorrelated account automatically
Hi @SanjeevIAM ,
Just removing the link of uncorrelated account in Isc automatically once aggregation runs
@Faizan854187 you can delete delimited source uncorrelated accounts by creating a workflow with the trigger as Account aggregation completed. Once that is done use the API - list-accounts | SailPoint Developer Community and use filter uncorrelated eq true and loop through the accounts and use delete-account | SailPoint Developer Community delete account API and pass the account id.
NOTE: The delete API can only delete the accounts of Delimited file source.
What if the aggregation results in more than 250 uncorrelated accounts? You have two problems then - first, your “List all uncorrelated accounts” action won’t contain all the accounts because it didn’t paginate through them.
Second, if you were to somehow get all the correlated accounts into an array of more than 250 and pass them into a loop, the loop would fail
I see a lot of people answering HOW you might do this but nobody really asking WHY you might do this?
What if you have a valid account that for some reason failed to correlate to the identity it belongs to? You then lose line of sight of that account. In my opinion the entire point of an IGA system is to ensure your governance (the G in IGA) extends as far as possible.
There is a reason SailPoint tracks the uncorrelated accounts. From the perspective of SP or any IGA in general, as you aggregate accounts, SP wants to keep the real representation of the aggregated data coming from a certain source.
If the percentage of uncorrelated accounts is (e.g. more than 5% or 10-20%), that means something is wrong in correlation logic, and should be fixed, as ideally, you want to have 0% uncorrelated accounts. Also, if you aggregate 10k accounts, even 5% would be a big number of uncorrelated accounts.
If you still believe that your account is wrongly uncorrelated, even though that correlation logic is correct, you are given the option to correlate the accounts manually (but again, correlating 500 accounts manually out of 10k would be tedious work, which means that correlation logic or source you pull data from should be inspected here as well).
Stripping away uncorrelated accounts doesn’t make sense, as it would lead to inconsistent data representation between SailPoint and the target source, ultimately compromising data integrity between the two systems.
Totally agree with you @mcheek. Deleting or removing uncorrelated accounts is not a good idea and it doesn’t serve the purpose of governance.
Even after suggesting the best practices, I have seen some customers have the requirement of not to maintain uncorrelated account, that is where I believe we can use this workaround of removing them via workflow for delimited file source.
Can’t we mitigate the 250 limit via recursive workflow?
May be instead of having the trigger as “Account aggregation as completed” we can use any other trigger(external trigger) so that someone can review the uncorrelated account manually and process the deletion ? Thoughts?
Hi @rajeshs,
Can you please share the json format of the workflow