IGI - Careful With Those Hierarchies

One of the beauties of IBM Security Identity Governance & Intelligence (IGI) is the ability to create custom "hierarchies" which I've discussed elsewhere in this blog. So much power, yet so much frustration too. These things need a LOT of tender love and care.

How so? Well, for two reasons:

• Batch only rebuilds rather than "on-the-fly" insertions; and
• Non-completion of a rebuild

Batch Only Rebuilds
Hierarchies are rebuilt by a batch process handled within the Task Planner. This rebuild iterates over every PERSON object in the data repository and re-evaluates the hierarchy location for each and every user which is fine for re-synchronisation of a hierarchy against the PERSON objects.

But if a new PERSON appears in the system, they won't inherit their birthright entitlements until the hierarchy is regenerated. If there are a large number of PERSON objects in the system, a hierarchy rebuild may take some considerable time and may be scheduled to only execute once a day! Hardly ideal.

Fortunately, the upcoming latest and greatest version of IGI is supposed to address this inadequacy and should support "on-the-fly" insertion of PERSON objects into any hierarchy (and not just the Organisational Unit Hierarchy).

Non-Completion of Rebuilds

The lack of "on-the-fly" insertions of PERSON objects into a hierarchy is doubly troublesome because a hierarchy rebuild may fail! Remember, a rebuild iterates over every PERSON object in the underlying repository. A failure to process any one of those PERSON objects could result in the hierarchy rebuild stopping.

In other words, in a system of 20,000 people, a failure to process person number 19,999 will mean that person number 20,000 will not get processed at all! To put that another way, the system does not FLAG the failure to process a person and basically abandons processing all subsequent users.

Oh dear! So what can cause a failure and should our custom hierarchy construction code be more robust? Unfortunately, our custom hierarchy construction code probably has nothing to do with any failure as there are a myriad of other reasons why a hierarchy build would merely stop (after a bout of hissy-fitting). Take these two examples:

• Insertion of a user into a hierarchy triggers the creation of an account as a result of a birthright entitlements attached to the hierarchy node; but the account creation throws an error because it attempts to re-use the Master UID of the user to create the account but an account with that ID already exists!
• Insertion of a user into a hierarchy triggers the addition of an entitlement to a user's account as a result of a birthright entitlement attached to the hierarchy node; but the user seems to already own two accounts for that service - something which should not be possible with IGI in the current version (v5.2.2) but seemingly IS possible under certain circumstances!

In other words, it doesn't matter how robust your hierarchy construction code is, the quality of the underlying data could throw quite a major spanner into the works! Of course, a better approach would be for the core IGI engine to handle such issues and at least move on to the next PERSON object to be processed. Maybe in the next release!

Meantime... take care of that data! Get a handle on your orphan management processes and check for duplicates. The following  SQL command will help you with that particular diagnosis:

select pw.pwdcfg,pw.person,p.code,count(*)

from pwdmanagement pw

left join person p on pw.person=p.id

where pw.person is not null

group by pw.pwdcfg,pw.person,p.code

having count(*)>1;