We've run into a situation where we want IDM to log privilege adds/removes, even when that privilege already exists (for add) or doesn't exist (for remove) on a person. Let me give some background.
We are a small team working on an IDM project, each team member with 6-30 months of experience with the IDM product. We're using 7.1.
We have two systems, one of which is queryable and (certain) privileges updatable via REST API -- we'll call this system REST. The second system of course is IDM.
When an IDM privilege is added or removed, the business requirement is to always keep IDM and REST in sync, privilege-wise. This is no problem and we have provisioning set up to make the API call, and it works great. However, if there is a problem with the REST API (network issue, just plain down, etc.) this sync can't happen. So, within the provisioning framework, if there is a failure, the failure is logged and the privilege is reverted, keeping REST and IDM synced. A job runs regularly to check this log table and re-attempt the appropriate action, which of course will trigger provisioning again, hopefully successfully.
The problem occurs in a situation like this, where each point comes in chronological order.
1. User X gets privilege Y granted within an IDM UI.
2. Provisioning triggers, but for some reason the REST API call fails (twice, because of retry).
3. The failure task for the REST API call removes privilege Y from user X. The error is logged.
4. After a while, some job runs which removes privilege Y from all users whose names begin with X. Even if the job explicitly removes privilege Y from user X, this is not logged in the system in any way, doesn't trigger provisioning, etc.
5. After another while, the "retry job" runs and attempts action #1 again. This time, the provisioning succeeds. Now user X has privilege Y on both IDM and REST. However, because of step 4, clearly user X should not have privilege Y.
The same (well, reverse) issue occurs when removing the priv in step 1 and doing a grant in step 4. During tests, one can just set up a To Identity Center step and remove/assign a privilege to an arbitrary person, then run the job containing this step repeatedly. If the action has no net effect, there's no record (in, for example, sentries, oentries, or indeed in mxi_(old)values). It would be great if there was a generic way to cause these actions to be logged, and we've actually thought of a couple other cases where this logging would be useful as well. Is there some simple way? Is it already logged in some esoteric table we haven't thought of?
Any thoughts on this interesting scenario would be appreciated. Thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.