IGI Internal Events

Monday, 16 April 2018
IGI gurus should understand that adding rules to Live Events is really the only way you are going to get maximum value from your IGI deployment. Out of the box features within identity tools are rarely sufficiently detailed enough to allow for production deployment and there is always a need to enhance these processes with organisation-specific rules and definitions.

IGI gurus will also be aware that the firing of rules can be somewhat hit and miss. Placing objects into the USER_ERC table will fire a Live Event on the IN queue, but writing an advanced rule to perform a SQL update of the same database table using the internal scheduler will NOT fire a Live Event!

Similarly, modifying a user in the Administration Console will not fire an event either unless you specifically "Enable Internal Events" on your Settings tab.



Enabling Internal Events, however, will only allow a handful of events to trigger a rule, For example, you can add business logic to the Add Entitlement event, but you cannot add business logic to the Publish Entitlement event or the Add Entitlement to an OU event. Maybe one day this will be enabled (and I really hope some of the IBM Development Team read this)!

Anyone who has ever enabled internal events, then clicked on the Monitor/INTERNAL tab to view the events may be sorely disappointed. I call it the "Tab of Disappointment" and why? Well, it will be empty. No matter what events are being fired, it will be empty. That is, until you add this little gem to your system:

when
    event : EventBean(  )
then
/*
 *  Version: 1.0
 *  Date   : 2018-02-28
 *  Purpose: Saves the event so it is viewable in the logs
 */
    event.setState(1l);

This piece of code should be added to the BEFORE ruleflow within Rules/Live/Internal. This code instructs the platform to always save the event within the database tables which makes the event visible in the Monitor/INTERNAL tab.

Now you can see what is going on in your system and maybe even replay events.

NOTE: Should you wish to look in your log files for anything you may be spewing out from your rules within Rules/Live/Internal, you may have to look at the accessgovernancecore_event_out.log file. Don't ask why!

Déjà Vu - IGI Handling of AD Dormant Accounts

Monday, 15 January 2018
I know I had this problem years ago with ISIM. Why do I have this problem again with IGI?

Years ago, the ISIM adapter for Active Directory would reconcile the Last Logon Date that was specific to which ever Domain Controller the adapter connected to. That meant, of course, that the REAL last logon date for a user was not being reconciled and any life-cycle rule built to query that attribute and act upon the value contained therein would, in all probability, cause a major "hoo-ha".

IBM resolved the issue by adding erADLastLogonTimeStamp which returned the domain replicated last logon date (albeit, the date could be +/- 14 days in accuracy for reasons which Bill Gates would be best to explain).

IGI is a new product but uses the ISIM adapters. However, the internal IGI mapping for of Last Logon is using the old erADLastLogon date rather than the slightly more reliable erADLastLogonTimeStamp.

Doh!

What are these crazy kids thinking? Did the ISIM guys not talk to the IGI guys? (That said, I've checked the latest resource.def file for the ISIM adapter and I'm disappointed to report that the erLastAccessDate mapping is set to erADLastLogon!).

In any case... if you want to run any kind of dormancy rule on Active Directory accounts in IGI, make sure you do this BEFORE you reconcile your service:

update itimuser.entity_schema_mapping set custom_attribute_name='eradlastlogontimestamp' where custom_class_name='eradaccount' and system_attribute_name='erlastaccessdate';

This little gem will ensure that the correct AD attribute is used as the last access date rather than the pitiful erADLastLogon attribute which is borderline useless.

Maybe IBM will update their configuration and resource.def file and documentation at some point (again).

IGI Default Account Attributes

Tuesday, 19 December 2017
DISCLAIMER: This article is not applicable to IGI v5.2.3 or later!

Setting account defaults in IGI is rather like setting account defaults in IBM Security Identity Manager (ISIM). For those familiar with both products, you will recognise that the ISIM screens were copied/pasted into the IGI platform with very little alteration. (One difference, of course, is the ability to set enforcement on attributes, but dealing with that is one for another day!)

Provisioning a new account can be tricky to troubleshoot, however. It seems that the logging levels can be less than helpful in certain circumstances. Consider the dreaded java.lang.NullPointerException! This can be thrown by the provisioning engine when the account defaults code is problematic.

Consider that we have a need to set an attribute in a provisioning target to the value of ATTR2 on our identity record, but only when ATTR1 is set to Y. You might consider using the following code:

if (subject.getPropertyAsString("attr1") == "Y") {
  return subject.getPropertyAsString("attr2");
}

The code looks great, but this code will throw our dreaded NPE in certain circumstances. Not only that, but our logs won't actually tell us which attribute and therefore which section of code is causing our NPE. Why does this happen?

Well, the provisioning engine MUST get an object returned from our code in ALL circumstances and the above code only returns a value if ATTR1 is set to Y. To avoid our NPE, we need to complete the code as such:

if (subject.getPropertyAsString("attr1") == "Y") {
  return subject.getPropertyAsString("attr2");
} else {
  return "";
}

The addition of a return statement within the ELSE clause will ensure we always return something. Our NullPointerException won't appear again...