When you are implementing Oracle Identity Manager to manage the identities within your organization, you may have to use multiple sources for identity information. For instance, there might be different departments with their own HR system and there might be separate sources for customers or business partners. In this article I’ll discuss 4 options to manage multiple sources and prevent issues like double identities. I will also present a use case to explain how to configure Oracle Identity Manager to use multiple sources.
Use Case
Swift&Safe Inc. is an organization that specializes in logistics. Swift&Safe Inc. uses Oracle Identity Manager to provide employees and customers with appropriate access to company resources. They use two different HR systems: one for employees who work in at the office (mostly administrative staff, but also some who work the logistic processes), and one for employees on the road. Let’s call these systems HR1 and HR2, both will be used by Oracle Identity Manager for importing identities. In addition, the company uses a third system (CUST1) to register customers and Oracle Identity Manager will also import identities from this system.
Figure 1: Swift&Safe Inc.
In this case people can have several positions within the company concurrently and can therefore exist in both HR1 and HR2, but Swift&Safe Inc. only allows one identity in Oracle Identity Manager per employee, so that any entitlements a particular person has can be checked against segregation of duties (SoD) policies. In addition, an employee can also be a customer and in that case needs a separate customer identity because access to customer facing resources is managed separately.
Swift&Safe Inc. is working on connecting Oracle Identity Manager to these three sources so employees and customers will have the correct identities in Oracle Identity Manager.
How does it work?
First I’ll tell you a couple of things you need to know about how the importing of identity information works in Oracle Identity Manager. After that, we can look into possible implementation options.
Source systems are integrated with Oracle Identity Manager by use of connectors. A connector is installed for every source and holds information about the format of the data in the source system (meta data), and a mapping table specifying which attributes of entries in the source correspond to which attributes of an identity in Oracle Identity Manager. The meta data and mapping table tell Oracle Identity Manager how to interpret the flow of data coming from a source so Oracle Identity Manager can build identities with the provided information.
Figure 2: Example of attribute mapping.
Oracle Identity Manager uses its reconciliation engine to handle the process of importing information. Reconciliation can be done in trusted mode and target mode. In trusted mode the imported identity information is used to create, update and delete identities in Oracle Identity Manager. In target mode, the imported data is regarded as information about accounts that are present in the source system. These accounts are assigned to identities in Oracle Identity Manager.
The reconciliation engine first uses the information of an entry in the source to try to match the entry to an identity in Oracle Identity Manager, based on matching rules. Depending on the result of this matching process, an action is then assigned to handle the imported entry, based on action rules. The matching and action rules are defined at connector level so these are specific per source. The entry and assigned actions (for example “create identity”) are stored in an event that is placed in the event queue. Items in this queue are then processed in so called orchestrations, which are workflows that take care of the job at hand.
Figure 3: Action rules define actions for each type of matching results
Implementation options
- Integrating HR sources
One way to prevent issues, is to make sure only one system is authoritative for the lifecycle of identities. A trusted reconciliation is set up with this source. Additional target reconciliations can be set up with any number of sources to augment Oracle Identity Manager identities with additional attributes that are not present in the trusted reconciliation. In the case of Swift&Safe Inc. this option requires the consolidation of identity information at HR system level, because information from all three systems must be present in the trusted source defined in Oracle Identity Manager.
- Using a staging area
This option involves setting up a system that acts as a staging area between the HR sources and Oracle Identity Manager. This may be in the form of a database or directory where information from multiple sources is combined (and maybe scrubbed, enriched or anonymized) in order to create a single trusted source for Oracle Identity Manager. In some situations this may be an option because of the complexity of the data, the amount of changes in meta data, the skill set of the support team or responsibility for data sanitation. But it may not be technically possible or too costly to maintain an extra system.
- Allowing multiple identities per person
Technically you can use multiple trusted sources in Oracle Identity Manager, and these sources will be authoritative for the lifecycle of ‘their’ identities. In this case multiple identities will be created for a person if this person is registered in more than one trusted source, and this results in multiple accounts on target systems. This can be useful for keeping accounts related to different job functions separated. Having multiple accounts on the same company resources can also be confusing to end users while perfoming their daily dutties and when they review information in request or review processes. Or maybe only one identity will be created and creation of subsequent identities for the same person will fail, depending on the configuration of Oracle Identity Manager for instance regarding the uniqueness of attributes.
- Consolidating identity information in Oracle Identity Manager
Using Oracle Identity Manager to consolidate identity information. This is the option that Swift&Safe Inc. will be implementing. They will use the capabilities of Oracle Identity Manager to combine identity information and centrally manage accounts and access rights. In part 2 of this article we’ll take a look at the basic configuration that is needed to achieve this.
Conclusion
There are several options for managing identities in an environment where multiple sources for identity information are used. Which one fits best in your organization depends on several factors such as technical feasibility, costs, maintainability and reliability, and data quality responsibility. Swift&Safe Inc. decided on option 4 because they need to keep their HR systems separated and do not want the burden of maintaining an extra system needed for a staging area. Oracle Identity Manager provides them with an excellent option by providing a central platform with configurable connectors, reconciliation options and workflows which allows them to accommodate the flow of identity information. In part 2 of this article you’ll find more information on how to set up Oracle Identity Manager in this scenario.
Is it possible to provide an Identity Management solution that will support awareness of individuals with multiple identities and support authentication using all identifiable identities?
Hi Ravi,
Thanks for your interest.
Basicly yes, it’s possible.
Let’s split your question in two parts.
First the identity part. The ‘identity’ is the basic unit in the system to differentiate individuals. So it’s not possible to link multiple identities with one individual. The link that is made is between entries in the trusted source systems and identities in OIM. That said, it is offcourse possible for one individual to use multiple identities, the system doesn’t have to know if Ravi1 and Ravi2 are the same person in terms of provisioning. But that requires the individual to be present in the source systems more than once, so more than one identities are created (implementation option #3 in my post). Or, additional identities are added in OIM manually. Or even, the source system which holds a unique entry for this individual is defined in OIM twice as trusted source with different sets of matching and action rules. Keep the managebility and automation in mind when looking into these options. Depending on your use case it might make more sense to have a 1:1 relationship between individuals and identities, and set up OIM to create multiple accounts in target systems where needed.
The second part, authentication to a system can be done with any of the valid accounts in the user store that is used by that system. However some systems may not support using two different logins at the same time (remember your OIM course where you’d have to log out a couple of times and switch user accounts). Things may get specially interesting when you’re using a SSO system that can decide for you what account to use for logging in.
Hope this helps.