Becoming inSenSitiVe
by Deborah Volk on March 26th, 2009

Every software package has its flaws. But, in the grand scheme of things, it is about how you can get around the flaws. Having been intimately (!) involved with Thor Technologies and having had a hand in many of the first and second wave IDM implementations, I've learned that software is only part of the solution, not the entire solution. Nevertheless, it's important to know how to, well, do things in software. The level of effort when it comes to implementation and maintenance of a live system is directly proportional to the foundation that was built. As for Oracle Identity Manager (OIM), I've seen just about every issue, bug, gap, problem and so on and there are always ways of getting around them but one of the most confusing aspects of the software has been fixed in the recently released version of OIM.

If you have never had to deal with reconciliations, a short intro is in order. The term reconciliation came from the accounting world where it refers to a part of an audit process where (usually) bank records are compared with the company's financial records. If your books say that you've earned $100 and spent $25 in the month of March, your bank account should have $75 at the end of the month. If it doesn't, there's a transaction that's not accounted for and auditors will get this creepy smile on their face when they find it. Somewhere in the 90s the accounting auditors discovered that not everything is well in IT kingdom and much advice should be proffered (along with stern looks and knuckle-rapping with a ruler); reconciliation became an IT term.

In OIM, reconciliation is the process of retrieving data from other systems (aka sources), comparing it to what's in OIM and acting upon differences (if any). Usually this data has to do with user accounts and associated information such as roles or entitlements. For example, if OIM created a Siebel account for me when I joined the company but at some later point, a friendly Siebel administrator accidentally granted me a VP role so I could see financial reports on the entire division, this would be something reconciliation from Siebel to OIM might catch and flag as an issue. Reconciliation can be used to deal with many other scenarios as well, anything from initial data load of users and applications into OIM to periodic refresh of application metadata.

The method of retrieving data (database? web services? ferrets?!) from some application to OIM is half the reconciliation battle. The other half and probably a much bigger half (I am thinking in non-Euclidean terms here where halves are not equal!) has to do with matching or linking the record coming in from the source to the identity in OIM. If your identity management implementation is dealing with all these reconciliation scenarios and multiple source systems, the rules for deciding whether a record from a source really belongs to some identity in OIM quickly become complex.
Enter Set Theory (you saw this coming, right?). The intersection between two sets must be done based on a property (or properties) that all elements of the set share. In the diagram above, the user record in different source applications (RACF, PeopleSoft and Solaris) has the "User ID" property so it would seem that we can easily link these user records to an identity in OIM. After all, the records have a "User ID", OIM identity record has a "User ID" so we're done.

Unfortunately, the sets are disjoint. Even though records in all 4 sets have a "User ID" property, each application thinks of the "User ID" in a different way so with data "as is" in these sets, the records coming in from PeopleSoft, RACF and Solaris will not link to an identity in OIM. We have to normalize the "User ID" space which translates to being able to control transformation from some value (e.g. jsmith) to another value (e.g. JSMITH). In an ideal scenario you'd like the software that you are using for your IDM implementation to help manage the transformation rules.

One of the most common (if not THE most common) transformation rules is case conversion, e.g. going from jsmith to JSMITH. If your source system does not impose strict rules on the User ID (or other key properties like first and last names) property (lower vs upper vs mixed case being one example) or case is changed after the fact, this could cause problems with reconciliation in previous versions of OIM and lead to misrepresentation of user-application relationships. In, Oracle made a change that allows for case-insensitive comparisons on key properties coming in from source systems during reconciliation. This seemingly minor change will drastically cut down on customizations and extensions that will have to be done for systems that don't follow or enforce a naming convention.

Have you upgraded yet?

Posted in Oracle Identity Manager    Tagged with oim, reconciliation


Leave a Comment

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)