Home‎ > ‎Oracle Identity Manager‎ > ‎

Manage Identity

As discussed in detail, the Identity Management is primarily focused on end-to-end lifecycle of accounts. These accounts are typically associated with a person, entity or system that owns these accounts. 

The accounts lifecycle events may typically be triggered by
  1. External events - e.g. In case of employee, there might be HR events like on-boarding, off-boarding, or transfer to another events
  2. Person - e.g. A manager may request Unix account for their reportee 
  3. Time - e.g. an account may be disabled in case it has not been used for 6 months. 
These events may result in following type of changes to the account (i.e. lifecycle event)

  1. Creation of an account - e.g. once a request has been made, a new account may be created for the user
  2. Updating account - e.g. a change in user details like last name after marriage or change in manager, due to transfer, for timesheet approval.
  3. Change of access/entitlement associated with account - e.g. upgrade from base user to administrator role in the application
  4. Enabling/Disabling of the account e.g. Account disablement due to non-usage for 90 days
  5. Locking/Unlocking of the account - e.g. Account lockout due to 5 invalid login attempts
  6. Deletion of the account - e.g. deletion of account after person leaves the company

Managing Identity in Oracle Identity Manager

In the real world the accounts and users can be represented by the following diagram where users have different accounts on one or more applications and services that they need access to.





The Oracle Identity Manager can be used to model the real world model described above as follows

In Oracle Identity Manager the users are modelled as User Profile (identified by the person icon on the left) and application/service accounts are modelled as Accounts (identified by the account on right).

Based on the diagram above it is clear that there are three types of mapping that needs to be managed by Oracle Identity Manager
  1. Real world user and Oracle Identity Manager User Profile
  2. Oracle Identity Manager User Profile and Oracle Identity Manager Accounts
  3. OIM Accounts and Actual Application/Service accounts
Let's look at each of these mapping in detail

Users and Oracle Identity Manager User Profile

Most of the time, a digital representation of real world user may already exist in a repository (e.g. an employee will be represented by a record in a HR system like E-Business or SAP) that needs to be mapped to OIM User Profile. Such a repository is called the Golden Repository.


Definition
Golden Repository or Authoritative Source is a system or database that is identified as primary source of data. Golden repository is typically used to manage the information. The data (and associated changes) flows to various downstream systems and overwrite any stale data present in the downstream system. 


Example include SAP, Oracle HR, Ultipro for employee information; Siebel for customer, partner information; Oracle Identity Manager for Consultants)


An enterprise can have separate and/or multiple  golden repository for each type of users (e.g. HR system for employee, CRM for customers/partners, OIM for consultants). In addition to that there can be specific golden repository for a specific attribute of the user (e.g. Exchange server may be golden repository for Email address).
The user details from golden repository must be reconciled with the Oracle Identity Manager User Profile to ensure that OIM has latest information about the users and to trigger downstream processes (more on this in next section - Oracle Identity Manager User Profile and OIM Accounts) if any. This involves comparing the entries in OIM and the source, determining the difference between the two, and applying the latest changes to OIM. This is referred to as trusted source reconciliation.

Trusted Source Reconciliation

Definition
If data is reconciled from a system that drives the creation of users, roles, role memberships, or role hierarchies in Oracle Identity Manager repository, then that reconciliation mode is called identity reconciliation, or authoritative source reconciliation, or trusted source reconciliation.

The trusted source reconciliation can be 
  1. Push based - i.e. the Golden repository (or appropriate middleware) provides the new data as soon as the change is made.
  2. Pull based - i.e. OIM connects to golden repository at regular interval and pull the data for reconciliation. This is typically done using a Scheduled Task (TODO: Fix this) 
The pull-based reconciliation may be performed in following modes 
  1. Full Reconciliation - in this mode, all the users from Golden repository are retrieved and compared with OIM entries and any changes identified are updated.
  2. Incremental Reconciliation - in this mode, the users that have changed since last time the reconciliation was run are identified, retrieved and compared with OIM entries and any changes identified are updated.

Implementation Approach

If the number of users is very large in the system being reconciled, it is recommended that an incremental reconciliation should be performed more frequently (at-least once every day) with full reconciliation being performed over long duration (e.g. once per quarter or half-yearly depending up on the volume of users and impact on business due to stale data).

This is primarily done to ensure that any changes that we missed due to infrastructure/data updation/processing issues get synchronized with the Oracle Identity Manager.

In some scenario when we are either dealing with very large data or with a very good incremental reconciliation algorithm, regular full reconciliation may be skipped completely. In such a scenario, tools like Bulk load(TODO: Add details) may be used to upload the data once (typically as part of bootstrapping the environment, also referred to Day 0 load) instead of developing tools for full reconciliation.

For more details about how to build a trusted reconciliation solution, please check out Trusted Source Reconciliation.

Oracle Identity Manager User Profile

OIM User Profile is user's account in OIM and is used to represent the user within the OIM data model. The Oracle Identity Manager User Profile consists of the following
  1. Attributes
  2. Roles
  3. Accounts
  4. Administration Roles
In addition to that Oracle Identity Manager User Profile goes through a simple lifecycle that is driven by following events
  1. User Creation
  2. Modify User
  3. Delete User
  4. Disable User
  5. Enable User
  6. Lock Account
  7. Unlock Account
  8. Reset Password

Under the hood

The above list of lifecycle events come from the Audit Event details defined in $OIM_HOME/server/apps/oim.ear/META-INF/component_events_oim.xml

More details about OIM Profile and associated attributes and operations are available at OIM Profile.

Oracle Identity Manager User Profile and OIM Accounts

One of the core functionality of OIM is it's ability to track the User Profile to Account mapping and manage it on receiving external events/triggers and processing them using standard and configured rules. These events are typically triggered by changes in User Profile's attributes and roles, request for account changes or target reconciliation. The system uses the configured membership rules, access policy, provisioning task, reconciliation profile to process these triggers and perform the defined operations.

More details on this can be found at User Profile Account Mapping.

OIM Accounts

OIM account represents the actual Application/Service account within the OIM model. An account is always assigned to a user within OIM and can not exist independently (except as a reconciliation event in case of orphan accounts). 

Implementation Approach

Due to the basic deficiency of the model where an Application/Service account must exist within scope of a user, there is no easy way to model service accounts, Distribution Lists, Shared folders and other shared entities within OIM.

OIM provides an extensible model to represent Application/Service accounts and allows developer freedom to respond to various triggers. The developer can put in place appropriate tasks and adapters that would perform the actual change on the target system based on the various events that trigger creation, update, disable, enabling and revocation of the account.
These events would typically involve
  1. Direct request for operation through API or UI by end-user
  2. Target reconciliation 
  3. Other triggers as identified in User Profile Account Mapping
In addition to that OIM also maintains a snapshot of the account details (through a process form) that can be used to define a model of target system's account, identify the changes that is being made without reaching out to target system to get the details. In case administrators or users make any change to a user's account on target system, the detail in OIM will be out of sync with actual detail. This can have significantly impact the automation in place (for example if the account has been deleted in target system, any update through OIM may re-create the account in the target system since OIM is not aware that account should not be present in target system). This disconnect is addressed in OIM through target system reconciliation. 

More details on how the OIM Accounts can be designed and implemented is available in OIM Accounts.

Disqus for Google Sites