Authenticating OIM APIs without end user’s password

A common requirement in an OIM implementation is to not expose OIM user interface to all types of end users. To address this requirement, usually a custom application using OIM APIs is developed and deployed. Such application will expose specific OIM f…

OIM 11g R2 & X.509 authentication

OIM 11g R2 is out! This release brings a lot of new features and also improvements to existing features.OIM authentication providers are among the ones that were improved. The improvements make easier to integrate OIM with SSO solutions (for both SSO p…

Custom transformation provider for OIM GTC connector

GTC based connector is one of the most used approaches for reconciling data into OIM, specially through the use of flat files. A common issue is that some customers do not allow direct communication between OIM and the HR system (for different reasons …

OIM 11g & LDAP Synchronization

Since the first OIM 11g release, one of the frequently asked questions about OIM 11g is:

  • Should I configure OIM with LDAP synchronization or should I deploy a LDAP connector?

Since earlier versions, OIM provides connectors for the most popular LDAP systems: Oracle Internet Directory (OID), Oracle Directory Server EE (formerly Sun Java Directory/iPlanet), Novell eDirectory and Microsoft Active Directory (AD).

With OIM 11g, a new feature called LDAP synchronization was introduced. OIM uses this feature to synchronize its users and roles base to a LDAP system. This synchronization is bidirectional and it uses scheduled jobs/reconciliation engine to pull changes from LDAP and event handlers to push data to LDAP.
But if OIM already provides a connector for most of the industry LDAP servers, why provide a feature like LDAP Synch? Different customer’s business requirements, customer feedbacks and also some technical reasons led Oracle to develop this feature and make it available out-of-the-box in the product.

Going back to the fundamental question of this post: which one should I use? And the answer is, as usual, IT DEPENDS. It really depends upon the project requirements and their alignment with the different approaches functionalities and technical details.

But before you start saying “I do have my requirements, but I still don’t know which one to use”, let’s review the main differences between these two implementation approaches. With some knowledge about the main differences and the project requirements in hands, certainly it will be easier to make a decision.

  • LDAP Synchronization is a mandatory piece for the OIM-OAM integration (in the current 11.1.1.x releases). So if you are planning to integrate these products and make full use of the password lifecycle management features provided by the integration, LDAP Synch is a MUST. 
  • LDAP Synchronization is data oriented approach. Although it is possible to configure attribute mapping, basic synchronization rules and some other minor things, in the end, it is all about data: users and roles being synched behind the scenes from/to the LDAP server. The synchronized LDAP account is NOT in the users’ accounts list in OIM.
  • Connector is a process oriented approach. In this approach, one can make full use of OIM features like request/approvals based provisioning, access policy based provisioning, modification requests. A user will see, among his/her accounts, the LDAP account and he/she can take actions from there.
  • Reporting and auditing will contain information about the LDAP account only if a LDAP connector is implemented.

There are other technical details and functionalities that may be considered, but the topics above are the basics and first ones that you can use to help on the decision.

OIM 11g OID (LDAP) Groups Request-Based Provisioning with custom approval – Part II

Introduction This is Part Two of the article describing a potential implementation of Request Based LDAP Group Membership provisioning. Part One can be accessed here. Continuing with the implementation after disabling the default approval policies at the Request and Operation Levels, the next step is to configure OIM to enable the modification of a provisioned […]

OIM 11g Event Handler example

This post shows an example of a post process event handler in OIM. The example is simple and it shows how the user profile can be updated from the event handler based on the information that is provided by OIM to the event handler. Use case description…

Oracle Identity Manager Academy

Index to the Oracle Identity Manager Series from the Fusion Security Blog TeamOIM 11g is the current release of the Oracle provisioning tool, this post is to be used as basis for all the other OIM related posts in this blog. Through the posts we try to…

OIM 11g Event Handlers

Event Handlers are among the most common customizations in OIM 11g implementations. They have been available in OIM for a long time, but with 11g and its new frameworks, they certainly are becoming even more popular.

The most common use of event handlers is for extending the user management operations. Although a variety of business requirements can be achieved through custom event handlers, they must be used with care and with focus on the performance impact they may bring to OIM transactions.

The main types of Event Handlers are:

  • Pre-Process: triggered BEFORE the actual transaction is executed
  • Post-Process: triggered AFTER the actual transaction is executed, but within the transaction
  • Validation: triggered BEFORE the actual transaction starts and can prevent the transaction from happening if the validation fails
Because they are executed after the actual transaction happens, the post-process event handlers are asynchronous to the main transaction. In other words, they do not impact the main transaction performance.
But keep in mind that they can and will affect OIM overall performance, they are just another code to be executed by the application server.
Event Handlers are tied to specific entities in OIM like ‘Users’ and ‘Groups’. They are also tied to specific transactions, like ‘CREATE’, ‘MODIFY’ or ‘DELETE’, and they can also be tied to any transaction.
In OIM 11g, the Event Handlers are implemented through the plugin framework. An Event Handler comprises of:
  • The XML file that defines the event handler and specifies (among other things): Event Handler name, Java class with the implementation, entity type, the stage that the event handler will be executed (preprocess, postprocess) and other information depending on the type
  • The plugin that contains the code to be executed

Finally getting to the point: a list of recommendations that should be considered in Event Handlers implementation.

  •  Use OIM 11APIs whenever possible; avoid using ‘Thor.API.tcUserOperationsIntf for searching users. Make use of the new APIs like ‘oracle.iam.identity.usermgmt.api.UserManager’ and ‘oracle.iam.identity.usermgmt.vo.User’APIs like
  • Use 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 prevent OIM from triggering the event handlers once again
  • Avoid things like accessing external database (or other database schemas), reading files and other ‘external to OIM’ operations. They will slow down the event handler execution.
  • Do not forget that OIM invokes the event handlers in two different ways: bulk and non-bulk. Make sure that your Event Handler code is smart enough to handle both situations.
  • OIM instantiates one instance of each event handler during application server startup and keeps invoking it. Take this into consideration when designing and implementing your Event Handler.
The recommendations above may or may not apply to your business cases and implementation, but they are a good start point when designing Event Handler implementations.

Check the Oracle Identity Manager Academy for other OIM 11g related posts

Using OIM 11g APIs in Fusion Web Applications

IntroductionThe purpose of this article is to describe the setup needed to build ADF/Fusion Web Applications using JDeveloper that make use of OIM 11g new API’s and Services.OverviewI have encountered many users that are trying to develop applications …

Performance Tuning Tips for OIM

Introduction Escalations in OIM are typically related to performance issues; however, performance problems can be prevented by following some common recommended practices on how to configure OIM’s components and connectors. This article will discuss several kinds of issues/recommendations that can cause/avoid performance problems. These are grouped in the following categories: Memory Related Connector Related Customization […]

Developing Workflows to OIM 11g – the basics

OIM & BPEL Working together? 

OIM 11g release brought us the powerful world of Oracle BPEL based workflows: from this release on, Oracle BPEL is the workflow engine to be used by OIM in all sorts of requests and their related approval processes. While this integration makes OIM workflows way more powerful and flexible when compared to OIM 9.x, the development process is quite different. The idea for this article is to provide tips for making the development process more straightforward.

First let’s take a look in the main development steps for having a new workflow:
1. Generating basic workflow: OIM provides an utility that can be used to generate a JDeveloper project that contains a basic BPEL Workflow process:

‘ant -f new_project.xml -f new_project.xml’

The ‘new_project.xml’ is located at $OIM_HOME/server/workflows/new-workflow.

You have to provide the application name (which will become the JDeveloper Applciation Name), the project name (which will become the JDeveloper project in the application) and the process name (which needs to be unique across applications and will be the BPEL process name).

The command line will generate a JDeveloper application and you can copy it to wherever your JDeveloper is installed and start working on your customizations.

2. Customizing the workflow: using JDeveloper you can customize the workflow generated in the previous steps and code the logic to achieve your business requirements.

This is the step where you do all your customizations in the BPEL workflow. You can use OIM APIs to get information back from OIM, you can make external calls to legacy systems to verify data, you can easily integrate with existing WebServices, and you can pretty much do whatever is needed to achieve your business requirements.

3. Deploying the workflow: once the customization is done, it is time to deploy the workflow to Oracle BPEL engine. You can do this in two different ways:

  • Directly from JDeveloper: you have to create a WebLogic connection in JDeveloper.
  • Using a command line:

‘ant -f ant-sca-deploy.xml’

This script is located at $SOA_HOME/bin.

You will have to provide SOA Server connectivity information (username, password and URL) and also the path to the ‘.sar’ file. The ‘.sar’ file is generated by JDelevoper when you deploy the workflow to a file.

4. Registering the workflow: after the deployment to the SOA Server, the BPEL process must be registered in OIM. There is another script to accomplish this task:

‘ant -f registerworkflows-mp.xml’

This script is located at $OIM_HOME/server/workflows/registration

You will have to provide OIM connectivity information (URL, administrator username and password),  and also a path to a properties files you must create. The properties file must contain the BPEL workflow process information like category, domain, version and others.

What now? Are you done with the development cycle? 

Probably not, in most cases, it is necessary to make changes to the BPEL workflow to either fix bugs or make corrections. And there is a sequence of steps for that:

  1. Make the changes in JDeveloper
  2. Disable the workflow process in OIM
  3. Re-deploy the workflow to SOA Server
  4. Enable the workflow in OIM

To accomplish these steps, you have to use the same scripts you used in steps 3 and 4 from when you first deployed your workflow.

Ok, now finally to the point!

You probably noticed the number of scripts and the number of times you will have to run them when developing BPEL workflows to OIM. So to make the development process easier, I created some scripts to run OIM scripts. Scripting scripts is a good approach to lower the number of parameters you have to provide:  instead of typing the same parameters every time you run the script, you just provide the ones that make the difference. The scripts below are for Linux platforms, but they can be easily translated to other Unix-like platforms and also to Windows.

First we need to set all the environment variables we need in one script (substitute the values between ‘<>’ by the values from your environment):

middleware.env – this script will be sourced in the other ones

export MIDDLEWARE_HOME=<middleware_home>
export ANT_HOME=$MIDDLEWARE_HOME/modules/org.apache.ant_1.7.1
export PATH=$ANT_HOME/bin:$PATH
export SOA_HOME=$MIDDLEWARE_HOME/<soa_folder>
export OIM_HOME=$MIDDLEWARE_HOME/<iam_home>
export WL_USER=<weblogic>
export OIM_USER=<xelsysadm>
export OIM_URL=t3://<hostname>:<port>
export SOA_URL=http://<hostname>:<port>

Then we can use it in the ones that will actually do the work: – deploys the workflow process to the BPEL server. To run this one all you have to provide is the WebLogic admin password and full path to the ‘.sar’ file.


. ./middleware.env

cd $SOA_HOME/bin

ant -f ant-sca-deploy.xml -DserverURL=$SOA_URL -Duser=$WL_USER -Dpassword=$1 -Doverwrite=true -DsarLocation=$2 – disables the workflow in OIM. You have to provide the OIM administrator password and the workflow process name.


. ./middleware.env

cd $OIM_HOME/server/workflows/registration

ant -f registerworkflows-mp.xml -DserverURL=$OIM_URL -Dusername=$OIM_USER -Dpassword=$1 -Dname=$2 -Ddomain=default -Dversion=1.0 disable – enables the workflow in OIM. You have to provide the OIM administrator password and the workflow process name.


. ./middleware.env

cd $OIM_HOME/server/workflows/registration

ant -f registerworkflows-mp.xml -DserverURL=$OIM_URL -Dusername=$OIM_USER -Dpassword=$1 -Dname=$2 -Ddomain=default -Dversion=1.0 enable

Collateral Information

Product documentation will always be the primary source of information. You can find more information about how to work with OIM and BPEL at:

Oracle Fusion Middleware Developer’s Guide for Oracle Identity Manager

Oracle Fusion Middleware Developer’s Guide for Oracle SOA Suite