Вы находитесь на странице: 1из 56

Technical Skills

Skills: IDM and ODI


Friday, April 15, 2016
OIM 11GPS2 Basic
1.Introduction

Identity
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 companys 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]
Users login by using OIM client, the OIM client interacts with OIM manager
server providing it with the users 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 EJBs.
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.
DBAs 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 users first name, middle name, last name, the users 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.
User:

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 administrators, 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.
2.Organizations
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.
3.Roles
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 APIs Support old and new APIs

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.

4.Connector
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.
Adapters
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.

5.Adapter
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.

6.Provisioning
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:
Rules
Groups
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

7.Reconciliation
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.
8.LDAP
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.
Person-subclass.
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 cant 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 11.1.1.3 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:
Cd LDAP BIN PATH
./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
Uid PSMITH
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/MSLDS,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 its 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:
Active.
Publish.
De Active.
Import/Export.
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
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.

Catalog:
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.
.
11.Certification
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.

12.Scheduler
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).
Steps:
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>
</plugin></plugins>
</oimplugins>
Structure of the Schedule task.xml file?
<scheduletasksxmlns=http://xmlns.oracle.com/oim/scheduler>
<task>
<Name>sample scheduler</name>
<class>com.oim.samplescheduler</class>
<Description>List user logins</description>
<Retry>5</retry>
</task>
</scheduled tasks>
Structure of the Scheduler.zip file?
Scheduler.zip - > 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 cant 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.
Oracle.IAM.Platform.kernel.SPI.PreprocessEventHandler
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.
Oracle.IAM.Platform.kernel.SPI.postprocesseventhandler
Post process event handlers are synchronous to the main transaction, In
otherwords, they dont 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=http://www.w3.org/2001/xmlschema-instance>
<plugins pluginpoint=oracle.iam.platform.kernel.SPI.EventHandler>
<plugin pluginclass=com.mypackage.oim.plugins.events.Role User event
management version=1.0 name=Role User event management/>
</plugins>
</oimplugins>
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.
Cant take any parameter from process form. Can take any field from process
form as parameter.
Cant 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 APIs like:
Oracle.iam.identity,usermgmt.usermanager and

Oracle.iam.identity.usermgmt.VO.user APIs like.


Use of the class Oracle.iam.platform.platform to get instances of the APIs.
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 handlers
execution.
Do not forget that OIM invokes the event handlers into two different ways.
Bulk and non-bulk. Make sure that your event handlers 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 APIs.

Implementation Steps:
1. Implement the configuration class for connector to extending the below
class.

Org.Identityconnector.Framework.AbstractConfiguration
2. To implement the implementation class for connector to extend the below
class.
Org.Identityconnector.Framework.SPI.connectorinterface
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:
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.
Auditing
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.

17.Notifications:
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=http://www.w3.org/200/xmlschema-instance
xsi:nonamespaceschemalocation=../../../metadata/NotificationEvent.xsd>
<Event type name=Demo Notification Event>

<StaticData>
<Attribute Data type=X2-Entity Entityname=User Name=User Login/>
</Static Data>
<Resolver
Class=com.oracle.demo.oim.notification.demonotificationeventresolver>
<param data type=X2-Entity EntityName=User Name=usr_login/>
</Resolver>
</Eventtype>
</Events>
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 91Entity 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 passwords 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.
SOME Important PIONTS IN OIM

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.

Posted by CH V Madhusudhan Rao at 5:03 PM Email This BlogThis! Share to


Twitter Share to Facebook Share to Pinterest
No comments :

Post a Comment

Newer Post Older Post Home


Subscribe to: Post Comments ( Atom )
About Me
My Photo

CH V Madhusudhan Rao

View my complete profile

TUTORIAL

2016 ( 6 )
May ( 1 )
April ( 5 )
OIM 11GPS2 Basic
Oracle Data Integrator (ODI) - Frequently Asked Qu...
Oracle Data Integrator (ODI) - Frequently Asked Qu...
Oracle Data Integrator (ODI) - Frequently Asked Qu...
Oracle Data Integrator (ODI) - Frequently Asked Qu...

2014 ( 18 )

Template images by molotovcoketail. Powered by Blogger.

Вам также может понравиться