Consolidating identity information in Oracle Identity Manager

In part 1 one this article we saw several options for managing identities in an environment where multiple sources for identity information are used. In this part, you’ll find more information on how to set up Oracle Identity Manager in a scenario like the one described in the Swift&Safe Inc. use case.

First of all, the identities based on the input from CUST1 will be placed in dedicated organizations in Oracle Identity Manager so these identities and their authorizations can be managed separately. Regarding HR1 and HR2, these systems use their own internal identifiers for user records. These identifiers must be provided to Oracle Identity Manager as user attributes in the feeds from HR1 and HR2. In Oracle Identity Manager an UDF (User Defined Field) must be created for the identifier attribute (for instance, the personnel number) from HR1 and a separate UDF for HR2. During reconciliation, Oracle Identity Manager can match users in HR1 and HR2 by comparing the unique identifiers in the feeds with the UDFs in Oracle Identity Manager. You can add an attribute to the Oracle Identity Manager user by creating a sandbox and opening the user definition in the Identity System Administration interface. Depending on the version of Oracle Identity Manager you can find it in the ‘Form Designer’ under the Configuration section or ‘User’ under System Entities.

Figure 1: Opening the user field definition.

Figure 2: Adding a user field.

Next, additional UDFs can be created to store source specific information from the HR1 or HR2 system, for example about the persons manager and department, and any other information that needs to be present in Oracle Identity Manager. The additional UDFs can then be used in request, approval and review procedures and as attributes of accounts that are provisioned to target systems.

After this has been set up, measures must be implemented to prevent the creation of multiple identities for individual persons. The best way to do this is by adding an event handler in the orchestration that deals with all creations (no matter the source). The logic in the event handler can also be implemented in the connectors, however from an operational standpoint it’s easier to implement the logic once, in a central location. The event handler will add a check in the workflow by taking a number of attributes (first name, last name, birth date, etc.) and trying to find a match in Oracle Identity Manager on some or all of the attributes, skipping identities in the CUST1 organizations. If there is a match, the create event will terminate and a notification is sent to someone in your organization who can verify that the create event indeed concerns someone who already has an identity in Oracle Identity Manager. Once verified, the unique identifier of the second HR registration must be added to the existing identity, so the next time the source is reconciled the user is linked to the existing identity based on the unique identifier of that source.

Figure 3: assigning an event handler to an action using the Design Console.

The reason people should be involved when there is a possible match, is to make sure that it is in fact the same person. If you have enough information in the feeds from HR1 and HR2, and are able to apply sufficient logic in the event handler, you can consider triggering automated actions instead of requiring user input. And if the person has different managers in the HR sources, they need to be updated on the situation. Since the manager plays an important role in Oracle Identity Manager, and identities have only one ‘manager’ field, it can happen that tasks for a manager get routed to the wrong manager. If this happens often it may be wise to adjust approval and certification workflows to look for manager information in the source specific UDFs of the user instead of the regular Oracle Identity Manager ‘manager’ field, or configure workflows to not use the manager but specify an approver or certifier based on organization or other attributes. You can also modify the user creation and update process to choose from manager information in the HR1 and HR2 feeds to fill the regular Oracle Identity Manager ‘manager’ field.

An event handler should also be added to the orchestration involved when someone leaves the company. A check must be done to see if the identity is linked to multiple sources. If so, the identity should not be removed or disabled and only the link to the trusted source that was reconciled must be removed.