Propagating OIM attributes: Isn’t there a better way?

Author: David Cline, Director of implementation services

If you’ve worked on any Oracle Identity Manager project, you’ve likely come across a common question,“When OIM user attributes change, can I copy their values to one or more target system accounts?”  For example, if a person’s last name changes, can I copy that change to their Active Directory account, EBS account, Peoplesoft account, etc.?

Researching the Question:

If you take a few moments to do a short Google search, or spend some time researching, you’ll find that yes, of course you can!  It’s easily done with out-of-the-box configuration via process triggers. Sounds pretty easy, right?

Now, the natural next step is to dive into the requirements a bit further. As you peel away layers of the onion, your needs get more complex. You’ll discover that this process is not as simple as just copying values:

• User attributes should be conditionally copied based on the values of other user attributes.
• The values may have to be transformed.
• If the user has multiple target system accounts, only the primary account should receive the updated attribute values.  Secondary, shared, and service accounts owned by the user should not be updated.
• The exact rules for each attribute will change by the time you get them documented.  Then, they’ll change again because of a department reorganization or new approach to licensing. Then they’ll change again…and again…
• We don’t just need to copy user attribute values; in some cases, we need to automatically calculate the correct value.  For example, we need to automatically specify which out of dozens of Active Directory OUs a new account should be assigned to.  The decision needs to be based off of the values of several user attributes, such as department name and location.

So what do you do now?

Solving the Problem: A Helpful Utility

Out-of-the-box process triggers aren’t conditional, so you’ll obviously need to include some custom code.

Some prepopulation adapters and event handlers should do the trick.  You just need to write the code that matches the business rules…which can become like a vortex of endless code.

As your eyes glaze over when contemplating writing all the if-then-else rules, you realize that it will quickly become unmanageable, especially if the rules change often.  So, what option does that leave?

At Zirous, we’ve run into these complex attribute propagation requirements many times.  They can be addressed through code as described above, but that approach means developers will be required for any future business rule changes.  Process changes become less agile, and process owners or target system owners can’t easily make changes without involving development resources.

Zirous developed a utility to address all of these concerns.  Some features include:

• Attribute propagation rules are defined through a spreadsheet that can be reloaded into OIM at will.
• Any number of user attributes can be used to define filter rules for when to propagate a value to a target system account.
• Simple references allow any user or account attribute to be included in filter or propagation expressions, including concatenating user attribute values to other strings.
• Easily define whether a value should be propagated just when the value is created, when it is updated, or both.
• The custom code is prepackaged and can be reused across many environments with little to no changes.

The ease of defining values in a spreadsheet, combined with standard Zirous code, means that attribute mapping can be achieved without the need for customer-specific code.  Development time is reduced to nearly zero, and business process experts can independently define their own mapping.

Does that sound like something you could use?  Contact us to learn more!