Skip to Content
avatar image
Former Member

Looking for a way to log privilege adds even when the user has that priv

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!

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

2 Answers

  • avatar image
    Former Member
    Sep 28, 2011 at 06:42 PM

    Does anyone have any thoughts whatsoever on this situation?

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Oct 03, 2011 at 09:16 AM

    Hi Chris,

    If I understand correctly, since you are using the log to ensure that the privileges are synced.

    Any chance you could enhance step 4 to remove information about the failed assignment from the log, so that it will not be retried?

    Note also, that this is improved in IdM7.2 and the framework. You will only get the privilege assigned after the add-member task has successfully assigned the privilege in the back-end system (which is what you are trying to achieve).

    Best regard

    John Erik Setsaas

    Development Architect IdM

    Add comment
    10|10000 characters needed characters exceeded