Best Practice to Prevent Delete Operations

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

A customer was receiving a 302 error when aggregating using a Web Services connector. I believe the root cause might be due to the lack of a sticky session, or not using a client credential grant type.

The result is that it returned zero results on the get opperation due to the 302 error and started deleting accounts. This was a few months ago, they turned off deletions and haven’t seen the problem.

Because a get request may fail and SailPoint ISC interprets this as the source deleting the account, is it safe to consider that your authoritative source should never allow deletion events?

As a possible solution have a second authoritative source that would aggregate all users based on criteria of those that would be for a delete event and process them?

How are you handling these use cases?
Anybody know if SailPoint has considered a parameter that prevents any deletions when 0 accounts are returned? Is there a way to intercept delete events or send them to an approval flow first?

2

Isn’t this essentially what the account deletion threshold setting is for?

image
image425×309 6.3 KB

3

@ts_fpatterson
Yes, you can achieve it using the configuration below:

  1. Navigate to your respective Source.
  2. Navigate to Account Aggregation Tab under Account Management.
  3. Select 0 here or do not Enable the Account Deletion in the Source,

image
image924×326 6.98 KB

4

right, but we still want to delete accounts for actual delete operations rather than a get returning zero accounts.

5

Set it to 10%. 100% will be skipped while normal deletions will work. If you have more than 10% expected, increase it.

6

So for my customer’s scenario where accounts were deleted, it returned zero accounts. The delete threshold would have had to of been 100%, correct?

if the threshold was even 90%, it should have prevented any deletions?

7

No, it is only allowed to delete 10% worth of accounts or less. If it is told to delete more, it does not delete any and throws a warning for the aggregation.

Here is a test example from WS connector:

image
image937×577 20.3 KB

Second option would be to play with HTTP errors config Additional Settings

8

So really, before going to production someone should know what an expected deletion ratio may look like for the given source. But they should also make sure that the error handling is right for the source. But in this case it was a 302 error, which is not a standard expected error as it is based on the authentication which didn’t arise during testing and has only happened one or two times.

  • The Web Services source returns the HTTP status code: 200, but the response payload contains an error. Without the manually entered HTTP error, the source won’t know that it must fail the request and retry the operation.

If it is required to understand all perceived issues that might cause a source to presume a delete operation, we should have a way to intercept those delete operations on the Identity side for further checks. If I was the customer, I wouldn’t ever want to have to go to an executive and have to explain why a given percentage of accounts couldn’t work because we missed an error condition. It seems way too aggressive for such a destructive operation.

My assumption at this point is to investigate a before provisioning rule to discard delete events on an Identity if the Identity is not in a given lifecycle state. Example: if the HR data changes have not moved someone from a separated LCM state to a separated plus 30 LCS state, the Identity is not ready for a deletion. If the LCS needs to be “separated plus 30” to be deleted and it isn’t, then we ignore all Identity Deletions…