HAPPY NEW YEAR 2017

Identity And Access Management - Rajiv Dewan

OIM 11g Download Link

OIM 11g : http://www.oracle.com/technetwork/middleware/downloads/oid-11g-161194.html

OIM 11g Connectors: http://www.oracle.com/technetwork/middleware/id-mgmt/downloads/connectors-101674.html

OIM 11g Certification: http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

Make User ID as Non Mandatory Field in OIM

Make User ID as Non Mandatory Field on Create User Form

In most of the business requirements, we generate user id at the time of user creation. So in that case if we don’t fill User ID field then it throws error to us.

To avoid this,

1. Go to OIM_HOME/xellerate/config

2. Take backup of FormMetadata.xml

3. Open FormMetaData.xml in edit mode

4. Search for Form name="3" and search following line

AttributeReference editable="true" optional="false">-16 /AttributeReference

5. Make changes in following line fro optional attribute

AttributeReference editable="true" optional="true">-16 /AttributeReference

6. Save FormMetaData.xml and Restart the Application Server.

System Validation with PENDING Status

System validation Pending

I have seen this problem on forum so many times. Whenever we request for a resource then it stuck in “System Validation” Task.

Solution > Go to Design Console > Process Definition > Search for Process Definition of your object > CheckAuto Savethere.

Concurrent Approval in OIM

Concurrent Approval (2 level Approval)

It is the basic requirement of any client that request should be approved by one user/group then it should be approved by second user/group also. Request will be considered Approved only after both the APPROVALs.


Solution > I am taking example of TWO concurrent Approval. You can extend the same as per your requirement.

1. Go to Design Console > Process Definition

2. Give name of Process Definition say Resource Approval, select your object name from the list and type should be ‘Approval’ and Save

3. Add one task say “First Level Approval”. It should be Non Conditional and required for completion.

4. You’ll be able to see two responses ‘Approve’ and ‘Reject’ under Responses tab. You can ignore UNKNOWN

5. Go to Assignment tab and select user in the User tab. If you want to assign to group then Select Group Name but if you select Group name then Type should be Group there. By Default it is user and user is XELSYSADM. Save it

6. Add one more task “Second Level Approval”. It should be Non Conditional and required for Completion. Now follow step 4 and 5 for this task.

7. Save and Close

8. You are done.

Multilevel Approval Workflow in Oracle Identity Manager

It is the basic requirement of any client that request should be approved by one user/group then it should be approved by second user/group (only after first approval).

Solution > I am taking example of TWO Level Approval. You can extend the same as per your requirement.

1. Go to Design Console > Process Definition

2. Give name of Process Definition say Resource Approval, select your object name from the list and type should be ‘Approval’ and Save

3. Add one task say “First Level Approval”. It should be Non Conditional and required for completion.

4. You’ll be able to see two responses ‘Approve’ and ‘Reject’ under Responses tab. You can ignore UNKNOWN

5. Go to Assignment tab and select user in the User tab. If you want to assign to group then Select Group Name but if you select Group name then Type should be Group there. By Default it is user and user is XELSYSADM. Save it

6. Add one more task “Second Level Approval”. It should be Conditional and required for Completion. Now follow step 4 and 5 for this task.

7. Go to First Level Approval task and Go to ‘Responses’ tab and select Response ‘Approve’ and at the bottom in Task to Generate click Assign and select ‘Second Level Approval’ there. Now if you select Response ‘Approve’ then you can see ‘Second Level Approval’ at the bottom. Save it and Close.

8. You are done.

Oracle Identity Manager Terminologies

IT Resource:

IT Resource stores the configuration data of Actual Target Resource

Example: Above we have created Resource Object which is virtual representation of target Resource. But we have to create user into Active Directory so we should store configuration data related to actual Active Directory somewhere in OIM like FQDN of Administrator of AD, password of AD Admin, Root DN of AD, IP Address, SSL or not etc for setting up connection with Active Directory. We store this information in IT Resource and use this information while creating user into Active Directory.

Forms in OIM: There are two types of forms in OIM which are used for showing and storing user data for provisioning. Forms are:

1. Object Form
2. Process Form

Object Form: Object form is associated with Resource Object. It is visible at the time of provisioning. It is used for getting some input from the user while provisioning.

Example: user is raising request for some resource say “Resource A”. Client wants to store the Previous Company Name in the target resource and he doesn’t want to store this attribute in user Profile of that user. So we create one object form with one field say “Last Company Name”. While raising request for “Resource A”, user would be able to see this form and he has to fill his last company name.

Limitation: Can’t populate Target User Data on Object Form.

Process Form: This form is associated with provisioning process of any target resource. During a provisioning process, data flows to the actual target resource from process form only.

Features:

• Can populate Target User Data on Process Form which can be used while provisioning
• Used for Best Practice

Need: Just consider a scenario. Manager A is raising request for his subordinate User JMD. We have to create account in actual target resource for JMD but from where we’ll get JMD’s data. If we get from user profile then we’ll get Manager’s data not JMD’s data. In this case we use process form. Om process form we’ll get JMD’s data.


Adapter: It is smallest component in IDM which is used to perform a particular function in IDM. It can be attached with a form, task. Depending on its type, it performs various operations in OIM. Adapters are reusable components which is the biggest advantage. Here are five types of Adapters in OIM:


1. Process Task Adapter
2. Task Assignment Adapter
3. Pre populate Adapter
4. Entity Adapter
5. Rule Generator Adapter


Process Task Adapter: As the name suggests, it can be attached only in task.

Example: Suppose in your provisioning workflow you have one task which is used for creating user then you can attach one Process task Adapter in this workflow which will create user.


Task Assignment Adapter: It is used for assigning the task to any particular user/group. Task assignment adapter is used when you want to perform some operation to find the user to whom you want to assign task.

Example: If you want to assign the request to some user based on target user’s attributes then we need task Assignment Adapter. In my OIM implementation user has an attribute Country. Client wants that if user is from INDIA the request should be approved by JMD01, if user is from USA then request should be approved by JMD02.. so .. on… In this case we’ll have to use Task Assignment Adapter.

Pre Populate Adapter: This adapter is used for populating any field on forms (Process/Object) with some data.

Example: I have a process form which has fields like First Name, Last Name, User ID. I want to fill these fields from User Data. Then we use Pre Populate Adapter which populates the value from user Profile to Process form Field. In general terms, it copies the User ID, First Name etc from user profile and paste it on the process form fields.

Entity Adapters: When you want to perform any operation on any Entity like user/group then we use Entity Adapters. It can be attached only with forms. These adapters can be used

1. Before inserting data into Database (Pre Insert)
2. After inserting data into Database (Post Insert)
3. Before updating data into database (Pre Update)
4. After updating data into database (Post Update)
5. Before deleting data into database (Pre Delete)
6. After deleting data into database (Post Delete)

Example: Client wants to generate default password say ‘Jmd123’ while creating user. You will create entity adapter which will return a string “Jmd123”. You’ll attach that adapter in Design Console > Data Object Manager > Users form on Pre Insert i.e. before inserting data into Database of OIM.

Event Handler: It is similar as Entity Adapter but can be attached only on Pre Insert or Pre Update.


Difference between Event Handler and Entity Adapter:


Event Handler Entity Adapter

Need to extend tcBaseEvent class No need to extend any class
Can’t take any parameter from form Can take any field from form as parameter
Can’t return any value on the form Can return any value to any form field depending upon
the form

Identity Manager Terminologies

Reconciliation:

It is the process of bringing identities and accounts into IDM from some resource is known as reconciliation.

There are two types of Reconciliation:

  1. Trusted Reconciliation (Authoritative)
  2. Target Reconciliation (Non Authoritative)
Trusted (Authoritative) Reconciliation >

Process of loading identities into IDM is known as Trusted or Authoritative Reconciliation. In the process we load user profiles into IDM. User gets created into IDM.


Example: User data is stored in Active Directory. If we run trusted reconciliation against Active Directory then user will get created into IDM. If user already exists in IDM with that user id then his profile will get updated with new values from Active Directory (If any).


Target (Non Authoritative) Reconciliation >

Process of loading account profile into IDM is known as Target or Non Authoritative Reconciliation. In this process we load user’s account profile i.e. user’s target account information. In this reconciliation only Resource profile of user is created not user profile.

Example: User data is stored in Active Directory. If we run target reconciliation against Active Directory then his Resource Profile will get created into OIM. Resource profile shows that User has account into Active Directory. For creation of resource profile, it is required that user must be present in IDM before.


Provisioning:

Process of creating account of user into target resource is known as Provisioning.


Example: User is created into OIM. When we create user in any target resources like AD, OID etc from OIM, is known as User provisioning.


Resource Object:

Virtual representation of a target resource is known as Resource Object in OIM.

Example: Client has Active Directory as target resource in which users have to be provisioned from OIM. But OIM doesn’t understand Active Directory. So we make a virtual identity of Active Directory in OIM which is understandable by OIM. It is known as Resource Object.