SAP IdM 7.2: Pending delete vs. inactive entry.

[Former Member]

I decided to jump to it and give this SDN blogging a try, sharing some insigth and thoughts on Identity Management. For this blog I wanted to take a look at user deletion. Which as you may know is often a complicated process; systems may have different requirements on how user deletion should be handled, which in consequence means you may have to clean up the assigments. So all the users privileges and inherited privielges for roles need to be dealt with.

You may know in 7.1 that if you deleted a user this would immediately delete the user and you would not have any mx_person object for doing the cleanup process on. So the concept of inactive was introduced. The inactive entry would work seemingly like a delete user where delete events where fired. Inactive entries are however only viewable with special views and for tasks processing you need to be enabled the 'use inactive entries' option .This creates extra context switching of the views which in turn does not boost up performance. Also since user deletion requires inactive views and account removal does not you basically have to duplicate the deprovisioning workflow to handle this properly or add some additional logic for context switching (...and handle it "poorly", as you still need use inactive entries on tasks) .

Fortunately in 7.2 deletion works perhaps as deletion should worked in first place. Delete operation is now a pending delete process.Pending delete requires no special views nor context switching so it is much faster, and there no need to duplicate the deprovisioning workflow.So how to do it? just as always, delete the user with a toIdentityStore passs w/changetype=delete.The different is now that events will be fired for deprovisioning of assignments. The user will be in pending delete state and remain so until the fired events complete processing.

Basically I just want to delete the user. This will kicks of pending delete.

We are expecting deprovisioning task in the framework to execute, so lets disable the first available job to do some inspections.

Go!!

The user had two privileges initialy (forgot screenshot) PRIV:NOTES:ONLY (23) and the PRIV:SYSTEM:NOTES (22)

Looking at the entry table and link table.We only see one privilige, because the PRIV:SYSTEM:NOTES only has modify task it was immediately unlinked.The entry has mcEntryState 3 meaning pending delete. On the link table we see the mcLinkState 2 on PRIV:SYSTEM:NOTES, which means deleted. And no mcDelAudit set. (no deprovisioning task fired)But for PRIV:NOTES:ONLY it is still in linkState 0 and mcDelAudit is set.Looking at this audit we see the deprovisioning task in the provisioning  framework has fired.

And the provisioning queue our disabled job is set ready-to run. We can enabled it and complete the deprovisioning against the backend.As soon as the workflow has been executed, the entry will be copied to the old values and deleted.

My conclusion:

For 7.2 pending delete should be your default option for user deletion. It is faster and requires less implementation.Audit information is of course preserved in old tables, so the only reason for not doing pending delete would be if you need to reactivate the user at a later point. But even then, you do not get back your assigments so you might perhaps be better of extracting the user info and still use pending delete.