Identity And Access Management - Rajiv Dewan

Oracle Identity Manager: Security Issue

Today I found another issue with Identity Status (User Status) in Oracle Identity Manager, here are the sequence of activities which I performed:

  1. "User A" is logged in into OIM and doing some operations from his/her laptop. 
  2. At the same time, System Administrator logged in into OIM and disable the user or user gets disabled as part of Trusted User Reconciliation.
  3. Identity Status changed to Disabled on UI as well in User Repository(Database) successfully.
  4. Still user was able to perform various operations in OIM like request submission for self, others etc. If that user has administrative privileges then he/she can do anything.
In short, if someone has active session of OIM, he/she can do anything until that session terminates. 

OIM doesn't allow to create new session if Identity Status is Disabled but it must terminate the existing active sessions as well.

OIM - Provision Entitlement Programmatically - Error

For a PoC, I was trying to do provisioning of entitlement through APIs. While making the api call, I was getting error "Entitlement attribute not marked as key in reconciliation field mapping for ...".

I checked all the configurations, checkbox for Key was already selected. Tried with creating reconciliation profiles and restarting servers multiple times but didn't help.

I found the reference of the same issue in the following Oracle document under General Issues and Workaround section


Document was also saying the same thing that set the Key property for entitlement field. 

Finally I had to do reverse engineering on the API and found that it was an issue with Entitlement object which I was passing. It wasn't mentioned anywhere in the document that it is required to set few of the mandatory properties of Entitlement object and even the error message was misleading.

It took 2-3 hours to find the actual root cause but anyways I'm glad that it's working now, no need to open any new SR for this.

OIM - Task Auto Retry Time Limitation

I came across a requirement where there was a need to "Auto Retry" few tasks in every 2 hours (or more than 2 hours) in failure scenarios. 

OIM allows me to set below "Auto Retry" configuration for any failure task:

No of Retry Count
Retry Period

I can provide 59 minutes as the max time for the Retry Period but in our case we don't want to retry in every hour or in every 59 minutes. We know the reason of failure of such tasks that's why we want to retry in every 5 hours (or n hours) to avoid unnecessary retries.

One solution was to write a schedule job and retry such rejected tasks.

Another solution, which I tried: 
I changed the Retry Period in the database (MIL table). Design Console allows me to enter 59 minutes as the max value but database column doesn't have such limitation. I tried with giving the value as 120 minutes and it worked fine. First retry happened after 120 minutes only. 

Only challenge with this approach, Design Console doesn't show this Retry Period while opening the task. I can see the Retry Period from the Process Definition form (where it lists all the tasks) but not on that particular task while opening the task detail.

So in case you want to make any changes in the task (rare case in Prod) then it will ask you to provide value for Retry Period while saving the task so you will have to change the value in database again.

Disconnected Application Duplicate Task Getting Assigned

Few months back, I was working with Disconnected Applications and came across another issue where same task is getting assigned multiple times to Help Desk team for manual action.
In case of RBAC, if last role is removed then Access Policy disable or revoke the application so in my case it was configured to Disable the application.

If user request for any role again for the same application then Access Policy creates two tasks for Help Desk Team "Enable Application" and "Grant Entitlement". If Help Desk team, doesn't take any action on these two tasks for 4-5 days and during this time end user requests for another role for the same application then OIM Access Policy creates another "Enable Application" task for the same application.

I have seen this Duplicate Tasks issue for many scenarios.

Multiple Design Console Installations

It is obvious to have multiple OIM environments for any client like Dev, QA, Pre Prod & Production and we need Design Consoles for all these environments. Generally what we do, we install one Design Console and make changes to xlconfig.xml under Config folder to connect to different environments OR we make copy of Design Console folders.

I thought to use the same client for multiple environment by creating multiple xlconfig.xml i.e. one for each environment but I found that file name is hard coded in the jar files. Design Console supported jar files always look for xlconfig.xml so what I did:
  • Created different directories for each environment under the same Design Console installation
  • Copied the config folder inside each directory
  • Created multiple xlclient.cmd and pointed to corresponding environment directory

So now I have only one Design Console installation for all the environments. If I have to upgrade my Design Console then I have to do it only once.

For people who don't know, you can pass the username & password from xlclient.cmd itself so no need to type username/password for login (Small thing but useful sometimes it is really necessary :) )

Edit your xlclient.cmd same as below:

com.thortech.xl.client.base.tcAppWindow -server server -user RAJIVDEWAN -password Welcome1

Access Policy Harvesting - Case Sensitive Issue

Access Policy Harvesting - Case Sensitive Issue

Here's another issue with Access Policy Harvesting. I reconciled entitlement (xyz) for a user but in Access Policy we gave entitlement name in different case (Xyz). When we ran the Evalaute User Policy job after role assignment, OIM initiated provisioning for entitlement "Xyz".
Ideally OIM should have done Access Policy Harvesting for that entitlement but it didn't.

So make sure you compare the Access Policy Child form data with reconciled data. You can do the same by comparing POC and Child Form tables. This may give you 100% results if at-least one user is having access to entitlements which are defined in Access Policies.

Access Policy Harvesting - Oracle Identity Manager

Access Policy Harvesting is very common but important feature of Oracle Identity Manager. It is very complicated feature too :) In the last deployment we faced some weird issue with Access Policy Harvesting. In earlier versions of OIM, we used to follow steps mentioned in my other blog post (Click Here)

Details & Workaround:
RBAC solution is implemented for an application. Few roles of that application were already integrated earlier and now application team added few new roles and assigned the membership from the backend.
Now when we reconciled newly added roles and ran Access Policy Harvesting job (Evaluate User Policy) after assignment of OIM Roles, OIM didn't do AP Harvesting for newly added entitlements ONLY for few users.

AP Harvesting worked for few users for same set of entitlement and role but it didn't happen for other users having same role and entitlement. We tried to evaluate the Access Policies multiple times but no luck. On debugging, I found that accounts for such users (for who AP Harvesting didn't happen) were created by OIM through Provisioning Mechanism and that's why OIM was skipping those accounts while evaluating access policies. 
I had to change the Provisioning Mechanism of such account to "AP Harvested" from the database and evaluate the access policies again AND everything worked like a charm. :)

OIM Connectors: Office 365, ServiceNow, RestAPI, SalesForce

Oracle has released few new connectors for Oracle Identity Manager:

  • Office 365
  •  ServiceNow
  •  Generic REST 
  • SalesForce 
  • BOX
  • Webex
  •  Generic SCIM
  • Fusion Apps
  • Concur
  • Generic Script
  • Identity Cloud

These connectors can be downloaded from below link:


Sample Code: OIM API Code for Provision Application Instance

Here is the sample OIM API code for submitting request for Provision Application Instance:

public void submitProvisionRequest(RequestService requestService) throws InvalidRequestException, InvalidRequestDataException, RequestServiceException, BulkBeneficiariesAddException, BulkEntitiesAddException{
        String beneficiaryKey = "141";
        String applicationInstanceName = "ActiveDirectory";
        String applicationInstanceKey = "14";
        RequestData requestData = new RequestData();
        Beneficiary beneficiary = new Beneficiary();

        RequestBeneficiaryEntity requestEntity = new RequestBeneficiaryEntity();

        List targetEntities = new ArrayList();


        List beneficiaries = new ArrayList();
        String requestID = requestService.submitRequest(requestData);
        System.out.println("Request ID :: " + requestID);

OIM - SOA : Value too large for column "WFMESSAGEATTRIBUTE"."STRINGVALUE"

Issue Description:

For every request in OIM, OIM User Interface allows justification of 4000 characters but if you provide justification of 4000 characters, you will see error in the SOA Logs:

ORA-12899: value too large for column "_SOAINFRA"."WFMESSAGEATTRIBUTE"."STRINGVALUE" (actual: 4000, maximum: 2000) 

which means SOA supports justification of maximum of 2000 characters.

Put a solution in OIM UI (can be done in many ways) to restrict users from entering justification of more than 2000 characters.