Friday, April 15, 2016

OIM 11GPS2 Basic


An identity is a virtual representation of resource user by including employees, customers, partners and vendors.
Identity Management
Identity Management shows the rights, relationships the user has when interacting with a company’s network.
Benefits of Identity Management
a) Centralized auditing and reporting: Know who did what and report on system usage.
b) Reduced IT generation cost: Immediate return on investment is realized by eliminating the use of paper forms, phone calls and wait time for new account generation and enabling users self-service and password management.
c) Minimized Security Risk: Control access to the network and is instantly and update accounts in a complex enterprise environment including layoffs, acquisition, partner changes temporary and contact workers.
d) Legal Complaints:  Many governments’ mandates require secure control of access.

How does identity Management works?
The process involves creating user/accounts that are able to modify disable or deleted. Delegated work flow, Rules and Policies or applied to the user accounts.
User profile to tell the company who they are, What they are entitled to do, When they are allow to perform specific function, where they are allow to perform functions from and why they have been granted permission.
Identity Management Implemented Solution Steps:
Step 1: Inventory and access investment and processes.
Clean and console date identity data store.
Create virtual identities for enterprise users.
Step 2: Design and deployee the identity infrastructure component (RAM, HARD DISKS, and OS).
Create the identity provisioning and deployee password management user self-service and regulatory complaints.
Step 3: Delivery application and services.
Access management deployee to the clean environment.
Leverage predicated identity for improving supply change and employee efficiency.

2.OIM Architecture

Architecture of Oracle Identity Manager
OIM is based on the n-tire J2EE application architecture.
OIM architecture contains the following teers:
i. Presentation tier.
ii. Business tier.
iii. Data tier.
iv. Middle tier.

Presentation tier:
It consists of oracle identity self-service, oracle identity system administration, OIM design console and system application [JAVA, DOT NET etc…]
User’s login by using OIM client, the OIM client interacts with OIM manager server providing it with the user’s login credentials.
Business tier: -
The core functionality for OIM platform is implemented in JAVA using a highly modular object oriented methodology.
This makes OIM flexible and extensible.
Core Components:-
API Services: API is supported by OIM that allow custom clients to integrate with OIM.
Core Services: OIM offered below core services:
1. User Management.
2. Policy Management Services.
3. Provisioning and Reconciliation Services.
Integration Services: Integration services based on the adaptor factory and connector framework, which dynamically generate the integration code based on the Meta data definition of the adaptors.
Platform Services: OIM offered request management service, entity manager service and the scheduler service.
Business service tier implement the business logic, which resides in the java data object that are manage by the support to the J2EE application server.
(JBOS application server, BEA web logic server and IBM web-spear).
The java data object implement the business logic of the OIM application, however they are not expose to any application from the outside world. Therefore to access the business functionality of OIM, we can use the API with in the J2EE infrastructure which provides the lookup and communication mechanism.
Data tier:
 OIM data tier consist of data repository or database which manages and stores OIM data metadata in an ANSI SQL 92 compliment relational database and identity store.
Data tier consists of following databases:
a. OIM database.
b. Metadata store.
c. Identity store.
d. Integration between LDAP directory and server and OIM database.
This layer is responsible for managing the storage of data.
Middle tier: OIM architecture consists of following:
SOA: Request service and approval workflow design by using SOA.
OES: Authorization service is implemented by using OES (Oracle Entitlement Server).
ADF: UI Customization Implemented  using ADF (Application Development Framework).
SCHEDULER: Scheduler services implemented by JAVA.
BI Publisher: Reporting is implemented by using BI publisher.

OIM Component Architecture

OIM is Self-contained, standalone J2EE compliant application.
Web logic and WAS as J2EE container, JVM as runtime.
SOA for managing workflow and Notification:
OIM connects to SOA managed servers over RMI (Remote Method Invocation). To invoke the SOA EJB’s.
SOA call backs OIM via - > call back service deployee in OIM using front end URL.
Interprocess Communication:
In OIM all the Interprocess communication happens based on JMS queues.
Queues are configured for during installation time.
JMS Queues Names:
OIM Audit Queue.
OIM Default Queue.
OIM Attestation Queue.
OIM Kernel Queue.
OIM Process Queue.
OIM Recon Queue.
OIM SOD Queue.
OES for Authorization:
Policy definition point.
Policy enforcement point.
BI for reporting: No runtime.
Interaction except for condition reports.
BI is configured agent OIM database to fetch audit data.
ADF/Web Center Composer:
Runtime UI Changes.
Upgrade Safe.
Schedule Service: (Trigger Time):
Manages various schedule task in OIM defined in OIM.
Uses database as the centralized storage for picking and running the scheduler activities.
In one of the scheduler instances picks up a job, the other instances will not pick up at same job.
Enterprise Manager:
Monitoring, health check and dash board.
Configuration and diagnostics.
LDAP as persistence identity store:
LDAP sink for data synchronization between OIM database and LDAP directory.
Embedded Libovd for H/A.
DBA’s transactional and metadata repository:
OIM, SOA schema for transaction DB.
MDS schema for storing configuration.
External Dependencies: NEXA web for deployment manager capabilities to import export OIM artifex.
OCS catch and Jgroup and catch management.

3.OIM Terminologies:
1.OIM user
 It is an account which helps in managing the compliance of any organization and helps in providing the access rights according to its identity in the related organization.
OIM user entity describes the user with in the OIM namespace. User entity includes the user’s first name, middle name, last name, the user’s displayed name and user login id to OIM, and Email address for the user. Other attributes also associated to user.
Entity to resources application name (sibyl, Salesforce), Roles accessing (bank update role, invoice process role), organization (company name) and other OIM objects.
A user is associated with a single user entity within OIM environment.
OIM maintains 2 types of status information an user account.
1. Is Identity Status.
2. Account Status.
User entity is tied to the identity status.
The identity status for an account can be one of active, disabled and deleted.
Account status locked or unlocked.
OIM user is an account which helps in managing the compliance of any organization and helps in providing the access rights according to its identity in the related organization.
User types in OIM
There are two types of OIM users. They are:
End User Administrator :  It is a User who has access to both the administrative, user console and design console.
A end user administrator may be tasked with managing access rights for users, changing the status of process task or other task that include managing OIM environment from higher level. These tasks are associated with the system administrator’s, who are responsible for ensuring that OIM continues to be operable.
End User : End Users are normally recipients of resources provisioned to them by OIM by default they can perform self-service tasks from the console.
Life Cycle of the Users:
User entity can be created, managed and terminated in the OIM environment through a concept known as the user life cycle.
The stages of User life cycle:
Create: User can be created if user does not existing in OIM.
User Active: User can be active if to manager the user for modification like update, delete or disabled.
Disabled: A disabled user can be modified, unable or deleted from environment.
Deleted User: A deleted user cannot be modified with in the OIM environment.
An OIM organization is a logical container of entities including users and other organization defined with in OIM.
OIM can have a hierarchical structure which means that an organization contains other organization.
These organizations are called sub organization.
Organizations are closely related to resources and user getting provisioned into.
An OIM roles is used to define access rights that an entity may have.
These defined roles use unique role names to differentiate them with in the OIM environment.
A role may be associated with one or more access rights to OIM function.
Roles are closely related to access rights of users to use resources.
4.Role hierarchy
It describes the relationship between two or more roles defined with in OIM.
A role may be act as a both parent and child to other roles.
5.Role Category
Roles can be grouped into a category, organizing the roles for the purpose of navigation and authorization. Two categories exists by default in an out of the box installation of OIM.
Difference between OIM 10g and OIM 11g
OIM 10g OIM 11g
Reconciliation manager in design console. Event management in admin console.
Object form Request data set
Creation of new IT resource from design and admin console. Create new IT resource from admin console.
Struts based UI ADF based UI
Approval workflow creation from design/admin console Approval workflow creation from IDC using SOA plugin.
Custom work flow engine. Using BPEL as workflow engine.
No notification task Notification tasks which are separate from schedule task jobs.
No approval policies Approval policies
No need of BI publishers Need BI publisher for OOTB reporting
No need of RCU Need of RCU
Groups Roles
No concept of Request template Request template for controlling the attributes of the request.
Entity adaptor on user form Event handlers on user form
Support only old API’s Support old and new API’s

Difference between OIM 11g R1 and OIM 11g R2
OIM 11g R1 OIM 11g R2
For customization sandbox is not required. For customization sandbox is required.
Request is raised by using request template. Request is raised by using catalog.
There is no application instance concept in R1. Application instance creation is required.
Password policies only present in design console. Password policy present in admin and design console.

It is a container that holds the information that OIM needs to reconcile user identity with external source and provisioning using with target resource.
The Connector Components are:
Resource Definition:
This is a virtual representation of target application on which we want to provisioning account.
It is a parent record with which provision process (process definition) and process form.
Process Definition:
It is used to create, update and delete accounts on target system.
It consists of individual tasks that are to perform automated function on the target system. Each connector is packaged with single provisioning process. If we required extra-provisioning process. We can create additional provisioning process.
Process Form:
This form is used to provide information about user accounts to be created, updated or deleted on target system. This form also used to capture data that can be used by provisioning process task.
This form is  also externally used for conducting target reconcilltation.
The table structure associated with this form supports archiving and auditing of user accounts of target system.
Each connector shipped with certain default process form we can manually create additional process forms.
IT Resource:
It provides the all communication details of the resource.
One IT Resource for resource.
IT resource Types:
This is template for all IT resource definition associated with the connector.
IT resource type specifies the parameter that are common to all resource type instances. Such as host name and computes of the particular IT resource type.
One and only IT resource type for connector.
This includes all adapters that are required to perform common functions on the target application. Each adapter is predefined with certain mappings and functionality. These adapters are capable of interacting with the tasks in the provisioning process and the fields of the process form.

Scheduled Task (where applicable)
If the connector that you want to use is shipped with a predefined reconciliation module, then you are provided with a scheduled task definition. You use this component to control the frequency at which the target system is polled for changes to tracked data.
Different types of Connectors in OIM
OIM provides a three tire integration solution strategy for integration with heterogeneous identity aware IT systems.
OIM supports three types of connectors:
1) Predefined Connector.
2) Generic Technology Connector.
3) Custom Connector.
Predefined Connector: When a predefined connector is available for a target resource, these recommended integration method. Because a predefined connector is designed specifically for the target application.
Out of the box integration using predefined connectors and predefined generic technology connector providers.
Example: Active Directory, OID, Seibel and SAP.
Generic Technology Connector: To integrate OIM with target system that has no corresponding predefined connector you can create a custom connector to link target system and OIM.
Connectors created using custom generic technology connector providers.
Example: Flat File GTC, Database Connector GTC.
Custom Connector: If there is no technology interface or accessible user repository in the target system then you can develop custom connector for the target system.
Custom connectors are created using adaptor factory and ICF framework.

This is a small components in IDM which is used to perform particular function in IDM.
It can attached with a form, task depends on its type of adapters. It performs various operations In OIM.
The biggest advantage of adapter is reusable component.
There are 5 types of Adapters. They are:
1) Process task adapters.
2) Task Assignment adapters.
3) Prepopulated adapter.
4) Entity adapter.
5) Business rules generation adapter.
Process task adapter:
As the name suggest it can be attached only in task.
Example: Suppose in our provisioning workflow, we have one task which is used for creating user then we can attach one process task adapter in this work flow which will create users.
Task Assignment Adapter:
It is used for assigning the task to any particular user or group, the task assignment adapter is used when we want to perform some operation to find the user to whom we want to assign the task.
Example: If we want to assign the request to some user based on target system attributes then we need task assignment adapter. In my OIM implementation user has an attribute country, clients wants that it is from India, the request should be processed by “JMD01” if user from USA required approved by “JMD02” so on. In this case we will have to use task assignment adaptor.
Prepopulated adapter:
It is used for populating any attribute on process forms with some data.
Example: I have a process form which have attributes like first name, last name, user id. I want to fill these attributes from user data then we use prepopulate adaptor, while populate the values from user profile to process form attributes. In general terms it copies the user id, first name, last name etc. from user profile and paste it on the process form fields.
Entity Adapter:
When we want to perform any operation on any entity like user group, then we use entity adaptor. It can be attached only with forms.
Before inserting data into database. (Pre insert).
 After inserting data into database. (Post insert).
Before updating data into database. (Pre update).
After updating data into database. (Post update).
Before deleting data into database. (Pre delete).
After deleting data into database. (Post delete).
Business Rule Generation Adapter:
Certain business rules must be applied to perform attribute validation and enter default values into the form, which either can packaged with OIM or created by the OIM users.
Example: For the users form, we might want OIM to generate the user id automatically by creating user first name and last name based on the business rule.
Custom Adapter

1) Create Java code and package into a jar file.
2) Login into design console - > Click on development tools - > Click on Adapter Factory.
Note: Custom adapter is implemented by using the adapter factory in design console.
It will open the adapter factory screen - > Specify the Name, Description and select the required adapter type and save.
3) Go to Adapter factory screen and select the click on variable tab and create required variables.
4) After creating required variables - > Click on adapter tasks and open popup.
5) Select the functional task - > with in the functional task select the Java.
6) Upload your JAVA code Jar file and select the required class and methods and save it.
7) After completing to click on the build on adapter task screen if the build status is OK to save the adapter and use the adapter.

Note: Copy the java code into thee below code:
Middleware home/oracle-IDMI/server/javatasks.

It is a process to create user, modify user or delete user information in target resource is initiated by OIM data flows from OIM to resource.
Provisioning of users can be achieved by using connectors and other configurations in OIM to save their information in target system.
Types of Provisioning:
There are two ways in which the attributes of a custom process form are populated with information and corresponding data used by OIM to provisioning a user with a resource.
Manual Provisioning:
OIM administrator completes the form and saves the values into database. Manual intervention is require by the administrator for provisioning to occur.
Manual provisioning is the process by which an OIM administrator.
Populate the process form of the connector that represents the resource to be provisioned. Save form values to database.
Auto Provisioning:
OIM fills out the process form, saves information to its database and uses this data to provision the user with the resource.
OIM completes these actions (Instead of administrator) with no manual intervention required.
OIM populate the process form through adaptors that are activated when certain rules or conditions are met. OIM itself completes these three actions (Instead of an admin).
Auto provisioning eliminates the manual steps performed by an admin to fill out the custom process form and save form values into database.
Resource Level Provisioning in OIM:
Day 1 Provisioning:
 It involves initial creation of access privileges to resource for users and removal of these privileges.
Day 2 Provisioning:
Modification of privileges with resources based on business needs.
 Different types of User Provisioning
1) Direct Provisioning.
2) Policy Based Provisioning.
3) Request Based Provisioning.

Direct Provisioning:
This provisioning is provided by system administrators if users request any access on target system accounts using OIM self-service console and administrator provide the access as requested by the user.
Policy Based Provisioning:
 When you use access policies for auto provisioning then it is called as policy based provisioning.
There are 3 types of objects required to perform automatic provisioning based on access policies.
The main objects required for policy based provisioning are:
Access Policies
We can use rules for placing users to some specific OIM groups.
Once a user is a number of a group then access policies can be used to perform policy based provisioning in OIM.
Rules get evaluated whenever an update is made to the user attributes (Password Change, Email Address Change) also we can use OIM API update user () to re-evaluate users.
There is a schedule task called “Evaluate User Policies” delivered OOTB (Out of the Box). This task will be useful if you want to provision users by validating all the rules then automatically adding/removing groups, finally provisioning/di provisioning resources by access policy.
Request Based Provisioning:
A request based provisioning operation involves both end users and approvers.
Typically, these approves are in the management chain of the requesters.
Any user raise the request for resource access by using catalog. These request is routed by using catalog. These request is routed to request approver, based on the request, the approver approve the request once the approver  approves ,user gets provisioned to target resource. This is called as request based provisioning. The request based provisioning is implemented using SOA approval work flow

It is the process by which OIM receives information from resources.
Reconciliation is the process by which an action to create, modify or delete an identity for a designated resource in OIM is initiated from another external resource. OIM communicates with this resource to receive user information.
The reconciliation process compares user entries into OIM repository and the target system repository, determines the difference between two repositories and apply the latest changes to the OIM repository.
In terms of dataflow, reconciliation provides an inward flow of user information into OIM by using either push model or pull model, through which it learns about any activity on external resource.
Reconciliation roles, role membership and role hierarchy changes or handle as separate reconciliation events.

Reconciliation Architecture?

Reconciliation is a process of pulling user data from target system into OIM to keep the entity data in consistent state between the two systems.
The reconciliation architecture is described in the following steps:
Each connector as schedule tasks associated with it. The scheduler trigger the connector schedule task, which invokes reconciliation APIS to generate events. The events can be of type regular, Change log or delete.
The reconciliation events are stored in the reconciliation event repository which is OIM database.
When batch size is meet as asynchronous message is submitted which process the batch of events in bulk. At the end of the schedule task another asynchronize message is submitted for processing the events of the last batch.
The processing involves data validation, matching of the entities and action (create, update, delete and so on). This is followed by post processing via kernel orchestrations.
By default the reconciliation event processing happens in bulk and therefore all the steps till post processing are performed by PL/SQL stored procedures.
Event can be processed one at a time in following scenarios:
When events are processed from the event management UI.
When failed events are retrieved by the retry schedule task that runs periodically, for reconciliation single event processing, actions and post processing takes place through a kernel.
Reconciliation events are made available to the event management UI by another API call in the reconciliation management service.
What are the types of Reconciliation?
There are two types of Reconciliation:
1) Trusted Reconciliation.
2) Target Reconciliation.
Trusted Source Reconciliation:
All users are created in the application and OIM reconcile data from application. The application is the authorative source.
Example: HR Application, AD, OUD.
For trusted source reconciliation all user data stored into USR table under OIM schema.
Trusted reconciliation is supported for users and organizations. It  does not support for roles, role membership and role hierarchy.
In trusted resource reconciliation, process form is not used because this is not supported to provisioning process.

Target Resource Reconciliation:
All users are created in OIM and OIM then provision the accounts in application, any changes in application are reconciled back to OIM is also called as Account based reconciliation.
Example: HR Application, AD, OUD.
All accounts information are stored into UD_ Connector_USR table under OIM schema.
Target resource reconciliation support for users, accounts, organizations, roles, role hierarchy and role membership.
Target resource reconciliation is used process form for provisioning of the accounts.

Modes of Reconciliation
Regular Mode: Reconciliation event would contain all data and will be handled without additional processing. Performance benefits.
Change Log: Reconciliation event should contain only that data that got changed and will be handled with required processing. Mode can be configured in reconciliation profile or as a flag with reconciliation event creation API.
create Reconciliation Profile
Reconciliation profile is the configuration define to govern how reconciliation is run for a particular resource.
A particular resource has multiple reconciliation profiles each of which defines multiple matching rules, action rules and field mappings, which can differ in each profile corresponding to the resource.
The reconciliation profile is an XML based configuration file stored in OIM MDS (Metadata store).
The use of create reconciliation button is to update the changes (Adding of new attributes) in reconciliation profile present in the MDS.
Approaches of reconciliation
FULL: This is first time reconciliation.
Incremental: This is based on Schedule time.
Reconciliation Events:
Update Received, Create Received and Delete Received.
Directory Servers: (Basic Concept of LDAP):
Directory: It is a difficult structure database that stores data (user entries), through which we can  search easily for special purpose.
LDAP: (Light Weight Directory Access Protocol).
It is internet engineering task force (IETF) standard, an LDAP directory is organized in the form simple hierarchical tree known as directory information tree.
DAP: It is a protocol to access database directory.
DN (Distinguished Names):
Each user entry in an online directory is uniquely identified by distinguished name. The DN tells you exactly where the user entry resides in the directory hierarchy. This hierarchy is represented by directory information tree (DIT).
Directory Information Tree –

O = Organization
C = Country
OU = Organization Unity
CN = Common Name
SN = Sur Name
DC = Direct Component

The DN for this “smith” entry is (bottom to up). Cn=smith, Ou=server development, c=IND, O=acme.
Attributes: Each attribute consists of attribute type, attribute values.
The attribute type is the kind of information that the attribute contains.
Example: Job Title.
The attribute value is the particular occurrence of information appearing in that entry.
Example: Manager.
Attributes contain 2 kinds of information.
1. Application Attribute.
2. System Configuration Attribute.

1. Application Attribute: This information is maintained and retrieved by application clients or directly clients and is important to the operation of the directory or application.
Example: Telephone Number, Home address, Email Id.
2. System Configuration Attributes: This information pertains to the operation of the directly or application itself. Some operational information is specified by the application or directly to control the server.
Example: Time stamp for creation, Time stamp for modification, Name of the user who create or modifies user entry.
Common LDAP Attributes:
Attribute Type Attribute String Description
Common Name Cn Common Name of the user entry.
Domain Component Dc The DN of the component in a domain name system (DNS). Example: dc=uk, dc=acme, dc=com
JPEG Photo Jpeg Photo Photographic image in JPEG format, this is store in binary format.
Organization O Name of the organization.
Organization Unit Name Ou Name of the unit within an organization.
Owner Owner Distinguish name of the person who owns the user entry.
Sur name Sn Last name of the person.
Telephone Number Telephone Number Telephone Number of user.

Attribute Syntax: Attribute syntax is the format of the data that can be loaded into each attribute.
Example: Telephone Number attribute syntax contain string of numbers containing spaces and hyphens.
Object Classes of directory server: An object class is a group of attributes that defines the structure of an user entry. When we define the structure of an user entry. When we define user entry in directory we assign one or more object classes to it.
Example: Organizational Person object class includes mandatory attributes common name and sur name and optional attributes – Telephone Number Address.
Sub Class: It is an object class derived from another object class.
Super Class: The object class from which a sub class is derived is called super class.
Example: organizational person-superclass.
Inherit: Subclasses inherit all of the attributes belonging to their super classes.
Different types of OCS in LDAP
There are three types of object classes:
Structural, Auxiliary and Abstract.
Structural Object Class: It describes the basic aspects of an object. The most of the object classes that we use are structural object classes and every user entry belongs to at least once structural object class.
Example: These object classes model real world entities and their physical or logical attributes. Examples include people, printers and database connections.
Auxiliary Object Class: An abstract object classes are grouping of optional attributes that expand the exact  list of attributes in an user entry.
Abstract Object Class: An abstract object class is a virtual object class, it is used only for convenience when specifying the highest levels of the object class hierarchy.
Object class “TOP” is an abstract object class it is required as a super class for all the structural object class, but it can’t be used alone.
Explain different types of LDAP servers in market?
Microsoft – Active Directory (AD).
Oracle – Oracle Internet Directory (OID).
Oracle Virtual Directory (OVD).
Oracle Unified Directory (OUD).
Oracle Directory Server Enterprise Edition (ODSEE).
Oracle Directory Service Manager (ODSM).
Novel – Novel E Directory.
1.OID (Oracle Internet Directory):
OID has user entries.
OID is a special kind of database repository, OID uses database to store user information physically.
OID written in java and c language.
The default ports for OID –
10g – 389(non SSL), 636(SSL).
11g – 3060(non SSL), 3131(SSL).
The default user name of OID – “orcladmin”.
How to start OID: OID process is controlled by OPMN (Oracle Process Monitor and Notify server).
To start OID by using OPMN ctl command.
To start OID -> opmnctl startproc ios: component=oid.
To stop OID - > opmnctl stopproc ios: component=oid.
2. ODSEE (Oracle Directory Server Enterprise Edition):
It has user entries.
ODSEE is got its own embedded database to store the LDAP information.
It has a directory server and a replication server associated with ODSEE, so we can replicate data from one ODSEE directory to another ODSEE directory as well.
3. OVD (Oracle Virtual Directory):
It has no user entries.
OVD does not have any available storage media.
OVD server is a java server process that runs outside of web logic domain.
OVD is a basical virtual representation of directory (LDAP), We can have AD, OID, OVD or ODSEE are database using adaptors in OVD, we can decide what to connect.
4. OUD (Oracle Unified Directory):
It has user entries.
OUD is purely based on java, a pure java solution simplifies multiplatform support, deployment and ongoing maintenance.
OUD has embedded database associated with it.
It is a small and lightweight directory server, but still it is very fact and robust database to physically hold the LDAP information.
OUD can also act as replication server (or) proxy server. Proxy server can either be used for load balancing or data distribution.
5. ODSM (Oracle Directory Service Manager):
It has no user entries.
It is a java application to manager OID and OVD.
ODSM is java application which runs on web logic server.
ODSM uses JNDI (java Naming Directory Interface) to connect OID and OVD.
Install and configure ODSM with OID and OVD during installation.
ODSM port number 7005 (non SSL), 7006 (SSL).
ODSM URL: \\host: portnumber/ODSM [user-id-orcladmin].
6. Active Directory:
It has user entries.
AD is a special purpose database.
The directory is designed to handle large number of read and search operations and significantly smaller number of changes and updates.
AD user data is hierarchical, replicated and extentionable.
AD – LDAP port numbers – 389, 636 (SSL).
LDAP Synchronization
OIM LDAP synchronization is process to integrate OIM with LDAP servers (OID, AD, ODSEE, OVD, OUD), so that users/groups/roles created In OIM are synchronized automatically with LDAP server.
LDAP synchronization can be configured during OIM configuration phase.
OVD is mandatory to integrate with OIM LDAP synchronization with version number and above versions OVD is optional.
LDAP synchronization is enabled in OIM, four default jobs are enabled.
LDAP synchronization post enable provision user to LDAP.
LDAP synchronization post enable provision roles to LDAP.
LDAP synchronization post enable provision role membership to LDAP.
LDAP synchronization post enable provision role hierarchy to LDAP.
OIM LDAP synchronization creates OIM users in LDAP server under default user container configured during LDAP configuration.
Example: Users with attribute value C=US, should go to container – C=US, CN=user, DC= Domain.
User with attribute value country=UK should go to container –C=UK, CN=user, DC=Domain.
User creation in LDAP Directory:
./ldapmodify – v –a –h (hostname) –p (portnumber) –D cn=DirectoryManager –W (Working Directory Password) =oracle123.
User Record Representation in LDAP:
Dn: Uid=PSMITH, ou=People, dc=Example, dc=com
Object Class Person
Object Class Organizational Person
Object Class Inetorg person
Object Class Top
Given Name Peter
Cn Peter Smith
Sn Smith
User Password Oracle123

Search the User:
./ldapsearch  -v –h local host –p 2389 –D ‘cn=DirectoryManager’ –W oracle123 –b “dc=example, dc=ccm” “(uid=PSMITH)”.
DIP Sync
It is a Java application deployed on web logic server and used for user/group synchronization between OID and LDAP servers, provisioning between OID and applications. (Portals, Collaboration Suit).
DIP provides two types of services:
1. Synchronization.
2. Provisioning.
Synchronization: Keeps third party directory server (MS-AD, MS-ADAM/MS-LDS,IPLANET, TODTS) consistent with OOID synchronization service uses synchronization profiles to synch directories and profile is managed by “Manage sync profiles” or FMW control.
Provisioning: Users and groups information is updated from OID to LDAP enabled applications (Portal, EBS and OCS). Provisioning service uses provisioning profile to synchronize data between OID and LDAP enabled applications and profile is managed by “OID protocol”.
Integrate OD and AD (User/group sync via DIP using GUI):
1. Login into EM console.
2. From left panel, expand FARM domain.
3. Identity and Access -> DIP.
4. From DIP server drop down menu - > Administration. - > Synchronization profile.
5. Click on create button and enter following details:
a. Profile Name.
b. Direction of the synchronization.
c. Type.
d. Host Name.
e. Port Number.
f. User Name.
g. Password.
6. Click on test connection to check if DIP can connect to active directory server - > Once test successful, click on OK to save synchronous profile.
7. Click on Mappings - > If you wish to configure mapping rules or Exclusion list yet domain level or attribute level.
Filtering: If you wish to filter synchronization based on rules at source or target LDAP server.
Advanced: Change the frequency of schedule or log level.
8. Click on enable profile to enable this profile.

9.UI Customization
The identity self-service user interface (UI) in OIM is based on application development framework which ensures consistent customization.
ADF allows UI customization that is safe from patches and upgrades.
ADF supports in built customization and MDS customization.
Types of Customization:
User Customization: Allows an end user to change the content of the application at runtime to suit individual preferences and have those changes retain the next time the user opens the application. It is nothing but personalization.
Example: Re arranging sections in homepage, add, delete them.
Saved Searches.
Personalized view of search result table.
Runtime Customization: Done on browser itself activating without server restarting.
Example: Change logo and banner.
Change x*X dimensions for anything.
Change font colour, background colour for anything.
Add/Remove fields/buttons/links/table columns/menu items.
Seeded Customization: Adding task flows, changing skin, deployed and restart, exist as part of the deployed application.
Example: Using ADF data validations.
Building a custom ADF task flow.
Adding one or more custom region to the home page.
Creating external link.
Sand Box: Sand Box is an area where meta-data objects can be modified without effecting their main line usage page.
In simple words, Sandbox is a temporary storage area to save a group of page customizations before they are either saved and published to other users or discarded.
Sandbox is a logical start and logical end.
Customizing the UI by using web browser, (runtime customization) the sandbox activation is mandatory.
Before doing any UI customization of below activities it’s always require the sandbox activation.
Create/Modify forms.
Custom attributes adding to user form.
Creating application instances.
Adding role/attributes to request catalog.
We can have multiple sandboxes in OIM but only one sand box can be active at any given time.
We can export and import the sandboxes to move the changes from test environment to production environment.
Operations can be performed on the sandbox are:
De Active.
Before publishing the sandbox to close all open tabs.
Before publishing the sandbox to export the sandbox.
sand box back up of MDS
Login into SOA admin console (em console) as administrator.
On landing page, click on oracle, iam, console, identity, self-service, ear version 2.0
From the application deployment menu at the top select ‘MDS configuration’.
Under “export select the meta data documents to an archive on the machine where is this web browser running” option and then click export. All the metadata exported in zip file.
Explain about the Expression Language?
Using EL to write the expression to assign the roles in end-user self-service console.
Out of the box expression language available in
User Context:
1. #{oimcontext.connectuser.adminroles[‘orclOIMsystemAdminsitrator]!=NULL}
2. #{oimcontext.currentuser[‘ATTRIBUTE_NAME’]}
Request Form Context:
1. #{pageflowscope.requestformcontext.requestentrytype==’APP_INSTANCE’}
2. #{pageflowscope.requestformcontext.beneficiarylds}
Application Instance:
Application Instance is a combination of resource object plus IT resource.
Application Instance is a new entity introduce in OIM 11g R2.
Application Instance is the entity that can be provisioning to users.
Application Instance are published to catalog and users can access application instance via catalog.
In OIM 11g R2 resource and entitlements bundled in application instance which user can select via catalog.
We can create application instance without connector installation for disconnected application instance.
Example: UNIX, Linux and Windows can create application instance with connector installation for connected application instance.
Example: Flat File, Seibel, Salesforce etc.
Application instance are created when a sandbox is active.
Application instance are published to organizations in OIM these application instance requested can be via catalog by user belonging to organization to which the application instances are published.
Application instance can be associated with multiple organizations.
Application instance can have entitlements associated with the (Role, Group, and Responsibility).
Two application instance does not have same IT resource.
Two application instance does not have same IT resource and resource object.
Application instance can have parent application instance and in such case child application instance inherts the properties of parent application instance.
When you delete application instance it does a soft delete. For hard delete run schedule job “Application instance post delete processing job”. (With mode delete).
All the application instances will be published to catalog by running a schedule job “Catalog Synchronization Job”.
Predefined Roles of Application Instance:
Application instance viewer, application instance administrator, Application instance authorizer.
Connected Application Instance
1. Install Connector.
1. Tag properties. IT resource = true, Account Name = true, Tag Entitlement = true in child process form.
2. Create Sand box.
3. Create Application Instance.
4. Create form and associate to application instance.
5. On board entitlements.
6. Run lookup recon schedule job.
7. Run entitlement synch scheduled job/Run catalog synchronization job (Automatic).
8. Publish application instance (and its entitlements) to organization.
Disconnected Application Instance
1. Create Sandbox.
2. Create Application Instance (Check Disconnected).
3. Create form/child forms and associate to application instance.
4. OIM artifacts created behind the scene.
5. Publish application instance to organization.
6. Use entitlement loader schedule task in flat file connector to load lookups/entitlements.
7. Run catalog synchronization job.
8. Customize request form for more UI cosmetic changes or add new attributes.
9. Enrich the catalog entry for disconnected application instance or entitlements to assign fulfilment responsibility.
10. Enhance the fulfilment composite.
11. To model task assignment rules based on application metadata and compliance objective.
12. To connect to third party ticket management systems (BMC Remedy TM, CA service center etc.
Entitlement are used to grant the permissions to user required access:
Entitlements consists of:
a. Groups.
b. Roles.
c. Responsibilities.
Publish the all entitlements to organizations.
Difference between Connected and Disconnected Entitlements?
Connected Entitlements:
1. Import Connector.
2. Tag Entitlement=true in child process form.
3. Run lookup reconciliation job.
4. Run Entitlement list job.
5. Run catalog synchronization job.
Disconnected Entitlements:
1. Create child form using UI.
2. Add field of type lookup.
3. Populate lookup manually.
4. Run entitlement list job.
5. Run catalog synchronization job.

Request Catalog: This is web based interface that allows business users to request roles, application instances and entitlements. (With in application).
Catalog Items: Roles application instances and entitlements can be requested via catalog are called catalog items.
Category: Each catalog item is associated with one and only one category catalog administrator can provide a value for catalog items.
Tags: Very important for searching catalog when the users search the access request the catalog the search is performed against tags. These tags are 3 types.
1. Auto Generated Tags: The catalog synchronization process auto tags the catalog item using the item type, item name and item display name.
2. User defined tags: are additional keywords entered by the catalog administrator.
3. Arbitrary tags: While defining a meta data if the user has mark that meta data as a searchable then that will also mark as tags.
4. Catalog Administrator: is a global role that grants privileges to load and manage the catalog.
Note: User with system administrative privileges like ‘xelsysadm can also load and manage the catalog’.
Catalog Synchronization Job: It is a schedule job that loads roles, application instances and entitlements in catalog. Run the catalog synchronization job to populate the all the items to catalog.
10.Policies in OIM
What is Access Policy?
Access policies are list of user groups and resources with which users in the group are to be provisioned or di-provisioned.
Access policies are created using access policy menu item in OIM administrator and user console.
List the features of access policy
Provisioning Options:
While defining the policies, you can specify whether you want to resources particular policy to be provisioned with or without approval.
Without Approval: Resources are provisioned directly to the user without any request being generated.
With Approval: If the access policies specified that resources be provisioned with approval then the OIM generates a request this request must be approve before the user gets the resource.
Revoking the Policy: OIM access policies are not applied to the sub groups, policies are only applied to direct membership in the groups that are defined on the access policies.
You can specify if a resource in policy must be revoked when the policy no longer applies. If you do so, then these resources are automatically revoked from the users by OIM when the policy no longer applies to the users.
Denying Resource: While creating access policy you can select the resources to be denied along with the resources to be provisioned for groups.
Evaluating Policies:
In OIM, access policies can be evaluated in the following scenarios:
When a user is made a part of a group or removed from a group. The policy of the user is evaluated as part of the add or remove operation.
If the retrofit flag is set for the policy. These evaluates does not happen immediately after the action, instead they happen during next run of the “Set user provisioned” date scheduled task”. The evaluation can happen following scenarios:
Policy definition is updated so that the retrofit flag is set to on. Policies are evaluated for all applicable users.
A group is added or removed from the policy definition policies are evaluated only for users of the group that is added or removed.
A resource is added, removed or “the revoke if no longer applies” flag value is changed for the resource. Policies are evaluated for all applicable users.
When policy data is updated or deleted. This includes both parent and child form data. Policies are evaluated for all applicable users.
Note: If you select retrofit flag in access policies the resources are provisioned to groups and sub groups also.
Access Policy Priority:
Policy priority is a numeric number that is unique for each access policy you create.
1 is the highest priority, higher number 1 is the lowest priority.
Access Policy Data:
There are multiple ways in which process form data is supplied for resources during provisioning.
The following is the order of preference built into OIM:
Default value from the form definition.
Organization defaults.
Values obtained through data flow from object form to process form.
Prepopulation adaptors.
Access policy data if resource is provisioned because of a policy.
Data updated by process task or entity adaptors.
Password Policies:
Organization administrators can associate a password policy to an organization.
All password policies are created by system administrators only.
A password policy set for an organization is applicable for that organization and its sub organizations.
Password policy priority determines which password policy is applicable for a user, if the user is number of multiple organization, if the organizations are in the hierarchy, then the password policy of the organization, that is close to the user is applicable.
Process of reviewing user entitlements and access privileges with in an enterprise to ensure that user not acquired entitlements that they are not authorized to have.
Certifications are 4 types in OIM:
1. User Certification.
2. Role Certification.
3. Application Instance Certification.
4. Entitlement Certification.
Certifications can be scheduled, monitored, delicated and audited.
Supports both online and offline certification.
Multi-face review can be enabled.
Generate user certifications or application certifications base on event.
Generate certificate reports using vi publisher at run time.
User Certification:
Allows manager to certify employee access to roles, accounts and entitlements.
Role Certification:
Allows role owners to certify role content and/or role numbers.
Application Instance Certification:
Allows the person who is responsible for a particular system or application to review the set of users who have accounts on that system or application.
Entitlement Certification:
Allows entitlement owners to certify user accounts that have a particular privilege.
Type of Certification Paradigm Actor Line Items Details
User Certification User Centric Line of Business Manager. Users Role assignments, accounts and entitlement_assignments for each user.
Role Certification Privilege Centric Role Owner Roles Two type of details:
a. Assignments of each role to users.
b. Access policies associated with each role.
App_Instance certification Privilege_Centric Application Owner Application Instances Accounts
Entitlement Certification Privilege Centric Entitlement Owner Entitlement definitions Assignments of each entitlement.

Certification Concepts:
Line Item: Line item collects are groups together according to the type of certification the set of privilege assignments related to a particular identity or privilege.
Line of Business:  A category of industry or business function.
Certification Task: A line item specific SOA task which consists of a set of work to be done with in a certification process.
Certification Object: A generated certification that is assigned to particular certifier or primary reviewer consists of certificate id and set of line items.
Certification Definition: It contains set of parameters (Certificate type) selection criteria, restrictions etc. that is used as input to a certification job to generate certification objects.
Certification Jobs: Used to create certifications as requested or as requested or as scheduled.
Event Listener: A service that responds to changes in users supported for user and application instance certifications.
Certification Security: OIM admin roles administrate the certification feature and monitor the progress of certification instances.
a. Certificate Administrator: Grants the assignee super user privileges for the certification feature. Grant access to the certification configuration, scheduler and full access to certification where you can view or take action on any certifications.
b. Certification Viewer: A read only role, allowing a compliance administrator to view new in progress and completed certifications.
Both are global admin roles can be spoked only to top organization.
Mapped with corresponding OES application roles to be used in OES authorization policies.
Certification Process Overview:
1. Preparing Environment.
2. Configure the risk.
3. Global Configuration.
4. Define Certification Campaign.
5. Launch and sign of certificate campaign.
6. Audit and reporting.

1. Preparing Environment:
Attribute tagging: IT Resource and accounts in design console.
Turn certification on/off.
System configuration. Display certification: Attestation//Certification.

2. Configure the Risk: Define the default risk values assign to new catalog entries during imports.
Configure the default risk values each provisioning scenario, recon, direct provisioning, request based provisioning, access policy based provisioning, a harvesting, role based rule.
Define risk for the last action performed against a certification entry.
3. Global Configuration:
Interaction Behaviour: Password sign off – Required password sign off.
Turn on/Turn off comments.
Employee Access – Access to page one or directly to page2.
Filtering: Self certification – prevent reviewer self-certification.
Users and accounts to consider - > Active users and accounts.
4. Define certification Campaign:
Define the certification type:
Define the certification pages.
Define reviewers for each page of certification.
Define the scope.
Attach the composite.
Define the event listener.
Generate and schedule the certification jobs.
5. Launch and signoff the certificate campaign:
Business user/organization admin/manager/certify for each user.
IT admin/entity owner certify for each entity for each user.
Final review.
Offline certification.
End user challenge.
Close loop remediation.

6. Audit and Reporting:
Audit certification events.
Generate Reports.

Certification prerequisites for to develop the certifications:
Mark a catalog item as certifiable.
Set the certifier in the request catalog.
Set user manager and organization certifier.
Set risk level for individual entities.
Tagging attribute.
Configuring the availability of identity certification.
Configuring reminder, notifications, escalations and expiry for certifications.

Scheduler Task: In OIM metadata is predefined for default schedule task.
New task can be added by the user with new metadata or the existing task can be updated to add or update the parameter or configuration details.
Schedule task can contain the meta data information.
a. Name of the schedule task.
b. Description.
c. Name of the java class that runs the schedule task.
d. Retry.
e. Parameter. (Optional).
1. Name
2. Data type
3. Required/Optional
4. Help text.
5. Encryption.
Schedule tasks are mainly 3 types:
1. Predefined Scheduler Task:
These schedule task are present in the OIM by default.
Example: 1 - Password expiration task. (By default is enabled).
Example: 2 - Disable/delete user after end date.
Example: 3– Enable user after start date.
Example: 4 – Run future dated reconciliation dated reconciliation event.
2. LDAP Schedule Task: The scheduler triggers the directory server data synchronization using LDAP scheduler task.
Example: LDAP user create/update/delete reconciliation.
3. Custom Scheduler: These scheduler jobs are created by using java.

Steps for creating custom scheduler:
Custom scheduler means java code is required.
We are implemented the custom scheduler means to extend the scheduler task classes.
Below classes are extended for the custom scheduler.
a. Oracle.IAM.scheduler.VO.shcedulertasksupport
b. Oracle.IAM.scheduler.tasks.schedulerbaseclass
We are used below methods for java code.
a. INIT() – To initialize thee parameter.
b. EXECUTE() – To execute the methods.
c. GET STATUS () – To verify the status of schedule job.
d. GET HISTORY JOB () – To verify the history of the job details.
Different types of situation for using Custom Scheduler?
1. Reminder Notification (Manager, Role owner and Application Owner).
2. De-provisioning of the user (User Related).
3. Escalation Notification (Higher Management).
4. Disable user notification (User).
a. Create Java code and package it in a Jar file.
b. Create lib folder in directory and copy the Jar file.
c. Create the plugin.xml file.
d. Create the schedule task.xml file.
e. Zip the Jar file plugin.xml file and scheduler.xml file.
f. Register the zip file using ANT script.
g. Verify the registration in OIM database using below query.
Select * from plugins.
h. Copy the scheduler task.xml file into MDS.
i. After copy and to run the scheduler.
Structure of the Plugin.xml file:
<? xml version=”1.0” encoding=”UTF-8”?>
<oim plugins>
<plugins pluginpoint=”oracle.iam.scheduler.VO.tasksupport”>
<plugin plugin class=”oracle.iam.samples.schtasks.Lookuprecon scheduled task “version=”1.01” name=”Lookupreconscheduledtasksample plugin”>
Structure of the Schedule task.xml file?
<Name>sample scheduler</name>
<Description>List user logins</description>
</scheduled tasks>
Structure of the file? - > Lib - > Jar File - > Plugin.xml file - > Schedulertask.xml file [Meta data].

13.Event Handler
In OIM or any identity system, any action performed by a user or system is called an operation.
Example of the operation:
1) Creating Users.
2) Modifying Roles.
3) Password Policies.
Note: In OIM 11g entity adaptor can’t be attached to the process form so instead of you will have to re implement the entity adaptors as event handlers.
Orchestration: The process of any OIM operation that goes through predefined set of stages and execute business logic in each stage is called as orchestration.
The stages of orchestration:
Validation: To perform the validation on attestation.
Pre-process: To perform orchestration parameter manipulations or get approvals.
Action: In which the action takes place.
Audit: In which the auditing of operation is performed.
Post Process: In which consequent operations related to the current operation takes place.
Finalization: The process to perform any clean up.

Types of Event Handlers:
Pre-process Event Handlers: The pre-process event handlers are evaluated before            creating user data into OIM database. (Trigger before the actual transaction is executed).
Example 1: User login creation using first name and last name (fn and ln).
Example 2: Display name generation.
Example 3: When user is created the user account status is to be set based on some rules.
Pre-process event handlers extended the below class.
Pre-process event handler supports both synchronous and asynchronous.
If the event handlers executed in synchronous mode it returns the event result.
If it is executed in asynchronous mode it must return the NULL values.
If the event handlers in other combination we move the process to fail state.
Post-Process Event Handler:
The post process event handlers evaluated after user record created into OIM database.
(Trigger after the transaction is executed but within the transaction).
Example 1: Password generation using custom policies.
Example 2: Random password generation and send to the email notifications to the user.
For post process event handlers to extended the below class.
Post process event handlers are synchronous to the main transaction, In otherwords, they don’t impact the main transaction performance.
Validate Event Handler: Trigger before the actual transaction starts and can prevent the transaction from happening if the validation failed.
Validate event handler extend the below class:
Oracle.IAM.Platform.kernel.SPI.ValidateEvent Handler
Custom Event Handler: Event handlers are tied to specific entities in OIM like users and groups. There also tied to specific transactions like create, delete and modify.
In OIM 11g event handlers are implemented through the plugin framework.
1. Write the steps for Custom Event Handler Scheduler?
Create Java code and package into a Jar file.
Create the zip folder in directory and copy the Jar file.
Create the plugin.xml file.
Create the eventhandler.xml file.
Zip the Jar file plugin.xml and event handler.xml file.
Register the zip file using ANT script.
Verify the registration in OIM database using below query.
      Select * from plugins
Copy the eventhandler.xml file into MDS.
After copy use the event handler.
2. Write the structure of the plugin.xml file?
<? Xml version=”0.1” encoding=”UTF-8”?>
<oim plugins xmlns.xsi=>
<plugins pluginpoint=”oracle.iam.platform.kernel.SPI.EventHandler”>
<plugin pluginclass=” User event management” version=”1.0” name=”Role User event management”/>
3. Write the structure of the Event handler.xml file?
<? Xml version=’1.0’ encoding=’utf-8’?>
<event handlers>
<! - - Custom pre-process event handlers - - >
<action handler class=”oracle.oim.extensions.preprocessor.samplepreprocess extension” entity-type=”User” operation=”CREATE” name=”Sample Pre-process extension” stage=”Pre-process extension” stage=”pre-process” order=”1000” sync=”True”/>
</event handlers>
4. Explain Event Handlers.xml file?
Class Name Class Name of the Event handler
Entity Type User or Organization or Group
Operation Create, Modify and Delete
Stage Pre-process or Post process or Validation
Name Name of the Event Handler
Order Execution order of the event handler, Identifies the order.
Sync TRUE. The sync attributes indicate whether the event handler is synchronous or asynchronous. Supported values are true or false.

Event Result: Any user can created from GUI it will trigger the event result for the single user.
Bulk Event Result: Users are created from target system in the event handlers the bulk event result is executed.
Difference between scheduler and event handler?
Scheduler Event Handler
It will trigger the process for reconciliation or notifications. Event handlers are performed based on action rules. It is used for user creation and password generation.
In scheduler, the plugin point is oracle.iam.scheduler.view.tasksupport. In the event handler plugin point is oracle.iam.platform.kernel.SPI.Eventhandler.
In scheduler.xml file it mention only retry count. Event handler.xml file will mention entity type, stages, order of the event handler execution.

Difference between Event handler and Entity Adapters?
Event Handler Entity Adapter
Need to extend the TC base event class. No need to extend any class.
Can’t take any parameter from process form. Can take any field from process form as parameter.
Can’t return any value on the process form. Can return any values to any process form field depending upon the process form.

A list of recommendations should be consider in event handler implementations?
Use OIM 11 APIs whenever possible: avoid using thor.api tc user operation Intf for searching users. Make use of the new API’s like:
‘Oracle.iam.identity,usermgmt.usermanager’ and
‘Oracle.iam.identity.usermgmt.VO.user API’s like.
Use of the class ‘Oracle.iam.platform.platform’ to get instances of the API’s. When this class is used, there is no need for API authentication. The instances returned run under ‘internal’ user in OIM, therefore the update operations can be done without authenticating: Platform.getservice (usermanager.class).
Avoid long running operations in event handlers. Even if the code can be executed as post process asynchronous operation, think about moving any long running operation to scheduled tasks and/or other OIM features.
Use ‘Oracle.iam.platform.entitymgr.entitymanager’ for updating user attributes. This will present OIM from triggering the event handlers once again.
Avoid things like accessing external database, reading files and other ‘external to OIM’ operations. They will slow down the event handler’s execution.
Do not forget that OIM invokes the event handlers into two different ways. Bulk and non-bulk. Make sure that your event handler’s code is smart enough to handle both situations.
OIM instantiates one instance of each event handler during application server start up and keeps invoking it. Take this into consideration when designing and implementing your event handlers.

14.custom connector implementation
1) In OIM 11g custom connectors are implemented by using adapter factory and ICF. (Integrated Connector Framework).
2) In my project we are implemented custom connectors by using ICF.
ICF: Integrated Connector framework based on API and SPI providers.
API: It provides the consistent view of the connectors.
SPI: SPI consists of different interfaces which can be implemented when you build a ICF API’s.

Implementation Steps:
1. Implement the configuration class for connector to extending the below class.
2. To implement the implementation class for connector to extend the below class.
Note: This class implements the create, update and delete operation, interfaces and support all the operations.
3. Implement the filters.
Note: Connector supports only the all value filter operations.
4. Upload connector bundle to OIM database.
5. Prepare the Meta data for connector.
6. Prepare the data for provisioning and reconciliation process.
7. Resource object, Process form and Process Definition, IT Resource Type, IT Resource and Scheduler.

ICF SPI – Required Interfaces:
Implementing the INIT method:
Stores the configuration information of the target system. This can be used later while performing an operation.
Initialize all supporting classes it uses while performing any provisioning reconciliation operation.
Implementing the dispose method:
Disposes of any resources held by this connector instance.
Once the method is called, the connector instance is discarded and cannot be used.
Implementing the get Configuration method:
Returns the configuration instance passed to the connector when the INIT method was used.
Validate() method:
Check the values of all required properties are set.
Validate that all values of the configuration properties are valid.
Set Connector Message() method:
Used for message localization.
Get Connector Message() method:
Used for message localization.
Connector Bundle:
The connector bundle is a Jar file containing the ICF SPI implementation.
Connector bundle can contain one or more connectors.
Mapping of ICF API – ICF SPI:
Org.Identityconnectors.framework.API.configuration properties. Org.Identityconnectors.framework.SPI.Configuration.
Org.Identityconnectors.framework.API.connectorfacade. Org.Identityconnectors.framework.SPI.connector.

15.OIM bulk load Utility
Using OIM bulk load utility tool is a great way to load large number of user records into OIM in an efficient and performance way. The tool uses the SQL loader functionality of the underlying oracle database to “PUMP” records into OIM database table rather than working through the Java API layer.

16.OIM List of tables and description
User Record Stores the all user related data into below tables
Table Name Description
USR Contains the USR table users and also user define fields.
User Role Membership
RUL Stores the role definitions.
UGP Defines groups and roles in the system.
USG Defines which users are in which groups and list of priorities for the users in the specific group.
User Policy Profile
UPD Stores user policy profile data.
UPP Stores user policy profile related details.
User Resource Profile
OBI Stores the resource object instance information.
OBJ Represents the resource object data.
OIU User information to the resource object instance.
Provisioning Process
MIL Defines process task definitions.
ORC Stores the process instance information when provisioning takes place.
PKG Defines provisioning process or work flows in OIM.
OSI Stores information about task created for process instance.
SEH Stores specific information related to running of a specific task instance.
TOS Stores atomic process information
Process Form Tables
UD The information stored in the UD parent.
UD_* Stores the information to the child table.
AUD Stores detail information about the all of the auditions.
AUD_JMS Staging table that stores information about changes made as a part of any business transaction.
UPA Main auditing table for storing all snapshots and changes made to the user profiles.
UPA_FIELDS Stores user profile audit history changes in de normalized mode.
UPA_GRP_MEMBERSHIP Stores group membership history in de normalized mode.
UPA_RESOURCE Stores user profile resource history in de normalized mode.
UPA_UD_FORMS Information about changes to the user account profile.
UPA_UD_FORMFIELDS Stores the name of the account or entitlement profile fields that are modified.

OIM 11g provide the notification framework, based on events, notification template and template resolver. They are depend as follows:
1. Events are defined in XML file and must be loaded into MDS database in order to be available for use.
2. Notification templates are defined to the OIM admin console. The template contains text and the substitution variable that will be substituted by the data provided by the template resolver. Template supports HTML and text based emails and multiple languages.
3. Template resolver is a java class that is responsible for providing the data to be used to pass the template. It must be deployed as an OIM plugin. The data provided by the resolver class will be used by OIM in the template substitution variables.
The main steps for defining custom notifications in OIM are:
a. Define events and meta data.
b. Create template with notification contents to be sent to recipients.
c. Create custom notification resolver class.
d. Trigger the event.

Structure of the NotificationEvents.XSD:
<? Xml version=”1.0” encoding=”UTF-8”?>
<Eventsxmlns:xsi=”” xsi:nonamespaceschemalocation=”../../../metadata/NotificationEvent.xsd”>
<Event type name=”Demo Notification Event”>
<Attribute Data type=”X2-Entity” Entityname=”User” Name=”User Login”/>
</Static Data>
<Resolver Class=””>
<param data type=”X2-Entity” EntityName=”User” Name=”usr_login”/>
Line # Description
1 XML file notification tag.
2 Events is root tag.
3 Event type tag is to declare a unique event name which will be available for template designing and this is used in the OIM advanced administration UI.
4 The static data element lists a set of parameters which allow user to add parameters that are not data dependent. In other words, this element defines the static data to be displayed when notification is to configured. An example of static data is the user entity, which is not dependent on any other data and has the same set of attribute for all event instances and notification templates. Available attributes are used to be defined as substitution tokens in the template.
5 Attribute tag is child tag for static data to declare the entity and its data type with unique reference name. User entity is most commonly used entity as static data.
6 Static data closing tag.
7 Resolver class must be defined for each notification. It defines what parameters are available in the notification creation screen and how those parameters are replaced when the notification is to be sent. Resolver class resolves the data dynamically at run time and displays the attribute in the UI.
8 The param data type element lists or set of parameters which allow user to add parameters that are data dependent. An example of the data dependent or a dynamic entity is a resource object which user can select at run time. A notification templates is to be configures for the resource object corresponding to the resource object field, a lookup is displayed on the UI when a user selects the events the call goes to the resolver class provided to fetch the fields that are displayed in the available data list, from which user can select the attribute to be used on the template. Param tag is child tag to declare the entity and its data type with unique reference name.
9 Resolver closing tag.
10 Event type closing tag.
11 Events closing tag.

Note: Data type needs to be declared as “X2-Entity” for user entity and “91-Entity” for resource or organization entities. The dynamic entities supported for lookup are user, resource and organization.
5. How to find user and manager details in USR table?
SELECT USR_FIRST_NAME||’|’||USR_LAST_NAME||’|’||USR_LOGIN||’|’||(select  u2,  USR_LOGIN from USR R2 WHERE u2.USR_KEY=u1.usr_MANAGER_KEY and rownum<2) as  MANAGER_NAME from  USR u1;

18.Active Directory Connectors
Active Directory Connectors are two types:
1. Active Directory User Management Connector.
2. Active Directory Password Management (Sync) Connector.
Connector Architecture:
1. Active Directory User Management Connector:
A trusted source reconciliation from AD:
The user management connector propagates user data changes from the active directory to the corresponding to the OIM user.
Target source reconciliation from AD:
User data from active directory is matched with active directory resource assign to OIM users.
OIM User Password Change:
If only user management connector installed and configured for the target resource mode.
Depending upon the allow password IT resource parameter, the user management connector propagates to the active directory and allocated to the OIM, password changes made to OIM users.
The user management connector can be configured to run either trusted source or target source reconciliation.
2. Active Directory Password Management Connector:
Password changes on active directory or propagated to OIM.
Password Synchronization Process Work:

The following is the sequence of events that takes place in the during password sync.
A user changes the user password on Microsoft active directory the user can change the password in the following ways:
a. Using Microsoft Management Console.
b. Pressing CTRL+ALT+DEL and then using the change password option on one of the client computers for the Microsoft Active Directory Server.
c. Using a third party application or custom utility for changing password’s on Microsoft Active Directory.
The password change is successful on Microsoft Active Directory only when the password clears all the password checks on Microsoft Active Directory.
The local security authority (LSA) component of Microsoft Windows intercepts the password change on Microsoft Active Directory and passes the password (In plain text format) and required user information to the password filter (oimadpwdsync10.dll file). The oimadpwdsync10.dll file is one of the files copied to the target system when you install the password synchronization connector.
The password filter encrypts the password and user information in a password change record and stores this record in the password change record queue.
The password update thread is created when the password filter is initialized. This thread performs the following tasks:
a. Picks up a password change record from the in memory queue or persistent queue.
b. Decrypts the password change record.
c. Creates and sends an SPML request to oracle identity manager in the form of a SOAP packet. This SPML request contains the SAM Account name of the target system user whose password must be updated on oracle identity manager. On oracle identity manager, the SAM account name value is compared with the OIM user attribute that you specify while installing the connector.

Different types of Accounts in OIM
In OIM it presents 3 types of accounts.
1. Orphan Account: It is an operational account without a valid owner.
2. Rogue Account: Rogue account is account created “out of process or behind the control of the provisioning system”. Orphan and Rogue accounts represented in a serious security risks.
3. Service Account: Service account is like a admin account which has life cycle and privileges.

 How to find the Orphan account in Target System
In support projects to generate the reports for orphan accounts.
The orphan accounts found in target system using below database query.

SELECT recon_events.re_keyfield, obj.obj_name from recon_events, Obj WHERE re_status=’No user match field’ AND obj.obj_key=recon_events.obj_key;

 How to find the Ghost account in Target System
The ghost account in the target system using below query.
SELECT recon_events.re_keyfield, obj,obj_name from recon_events, obj WHERE re_status=’One entity match found’ AND obj.obj_key=recon_events.obj_key;

Propagate the user profile changes in target system
We need to propagate user profile information changes to target system like change of corporate phone number (save as UDF) into LDAP directory or we want to update email id in some target system as soon as email is updated.
Changes to user profile trigger actions as defined by a lookup called
LOOKUP.Users.Process – Triggers
This lookup contains value of the column in USR table as code key and name of the process task to trigger as decode key.
Example: For code key USR_EMAIL decode key is change email.
For all resource object provisioned to users whose provisioning process has got “Change email” task will trigger as soon as there is a change in email of the user.
This change email task has the responsibility of propagating change in email to the target system.


  1. Excellent article to understand the OIM basic

  2. Nice write-up. Really helpful for interview preparations !!! Thanks Bro!!!