Index of Platform Security articles

Index of IDM Governance articles

Index of IDM Directory Services articles

Index of Access Management articles

OAM and OIM Config changes for Split Profile ( Split Profile Configuration -Part 2)

In my previous post i have discussed split profile set up scenario with AD and OID in Fusion Applications IDM Environment and how to create Adapters in OVD  for consolidating the two directory servers AD and OID.Adapters configuration alone is not…

Identity Management

As members of the IDM and Security A-Team, we get exposed to a wide range of challenging technical issues around security and Oracle Fusion Middleware. We’re using this site to answer common questions and provide interesting solutions to the real-world scenarios that our customers encounter every day. Products and Technologies Access Management > Discussions on […]

Split profiles with AD and OID for Fusion Apps IDM

In this post I will walk you through on How to set up split profiles with AD and OID as backend directory server while Oracle Virtual Directory links them together to present a single consolidated view.
This is a very generic implementation scenario but is very important when setting up IDM for Fusion Applications, where clients would like to use their existing Enterprise Repository for the user base. Very common example is to provision users out of existing AD without replicating the user base to some other repository, that’s when split profile AD and OID comes into place, while OVD becomes the presenter of consolidated view.
Here are some of the FAQs:
  1. Why do we need OID  for Fusion Applications when existing Enterprise Repository can be used ?
    a.       All the Fusion Applications specific and Oracle specific attributes are created in OID
  2.  Can multiple directories still be used as Identity stores?
    a.       Yes. Multiple directories can still be used as Identity stores with oracle specific attributes present in OID and enterprise specific attributes and Fusion Application specific attributes present in say AD.I will discuss this scenario in upcoming blogs
  3. Are User Login Ids unique across directories?
    a.       Yes , this a pre requisite and other pre requisites and limitations are very well discussed in IDM Enterprise Deployment Guide for Fusion Applications for configuration of directories other than OID
  4. When is the good time to configure split directory mode, before or after FA provisioning?
    a.       I will stress this  and recommend to go with this configuration after FA provisioning is completed 
    b.      Since this can also be done prior to FA provisioning  , in that case the recommendation is to complete the IDM Environment with OVD and OID (ID Store,Policy Store) >>Validate IDM Environment >> Then proceed with split AD Configuration
    c.       Configuring AD and OID before IDM validation is prone to good number of user errors.


    For easy understanding and simple configuration I will stick to the scenario of split profile configuration where existing Enterprise Repository is not extended.In this scenario this is how the view is from OVD level (adapter plug-in view/ unified view).

    As you see in the image above even though the actual base of both OID and AD repositories are same ‘dc=us,dc=oracle,dc-com’ , OVD Adapters are configured to map uniquely and to consolidate to a unified view  of ‘dc=adidm,dc=oididm,dc=com’

    Now let’s get in to action on how to create above configuration. On a high level this can be split in to 5 tasks

    1. Setting up Shadow directory  in OID
    2. Create a shadow joiner
    3. Create user Adapters for AD and OID
    4. Create Changelog Adapters for AD and OID
    5. Create Join View Adapter and Global Change Log Plug-In

    1.Set up OID as shadow directory

    Since AD is not being extended, OID will be used as a shadow directory and use Oracle Virtual Directory to merge the entities from the directories and for this purpose we need to create a container in OID to store Fusion Apps specific attributes
    a. Create ‘shadowentries’ container in oid ( below is sample ShadowADContainer.ldif)

    dn: cn=shadowentries
    cn: shadowAD1
    objectclass: top
    objectclass: orclContainer

b. Load the group with following command
$ORACLE_HOME/bin/ldapadd -h <oid-host> -p <oid-port> -D cn=orcladmin -w <password> -c -v -f

c. Create acis on the newly created group/container  to grant access to RealmAdministrators and OIMAdministrators(This is the group that does all ID Administration in OIM)

dn: cn=shadowentries
changetype: modify
add: orclaci
orclaci: access to entry by group=”cn=RealmAdministrators,cn=groups,cn=OracleContext,dc=us,dc=oracle,dc=com” (browse,add,delete)
orclaci: access to attr=(*) by group=”cn=RealmAdministrators,cn=groups,cn=OracleContext,dc=us,dc=oracle,dc=com” (read,write,search,compare)
orclaci: access to entry by group=”cn=OIMAdministrators,cn=groups,dc=us,dc=oracle,dc=com” (browse,add,delete)
orclaci: access to attr=(*) by group=”cn=OIMAdministrators,cn=groups,dc=us,dc=oracle,dc=com” (search,read,compare,write)

changetype: modify
add: orclentrylevelaci
orclentrylevelaci: access to entry by * (browse,noadd,nodelete)
orclentrylevelaci: access to attr=(*) by * (read,search,nowrite,nocompare)

d. An image of how the shadow container looks after creation.

 Note: All the steps here after are to be performed by connecting to OVD via ODSM.You can use the screen shots as pointers for configuration.



2.Create Shadow Joiner Adapter

Shadow Joiner User Adapter settings 

3.Create User Adapters for AD and OID

you would need to create a User Adapter for AD and OID.Use these screen-shots as pointers
3.1 User Adapter for AD
          AD User Adapter Parameters
3.2   User Adapter for OID
      OID User Adapter Parameters

4.Create Change Log Adapters for AD and OID


  4.1 Change Log Adapter for AD

4.2 Change Log Adapter for OID

5.Create a Join View Adapter and Global Change Log Plug-in

5.1 Join View Adapter Settings
 5.2 Global Change Log Plug-in
Finally this is how the summary of all the OVD Adapters is shown in HOME tab for OVD in ODSM
Next Steps ? 
Now that split profile is configured, what are the settings that need to change in OAM and OIM , I will discuss that in next blog.

Patch Management of an Oracle Identity Management Deployment

Today I’d like to discuss a very important topic which is patch management in an Oracle IDM/IAM deployment.  Patching seems like a pretty basic topic.  It is often taken for granted.  However, experience has shown me that patching is a frequent source of confusion for many enterprise software customers including those deploying the Oracle Identity Management  stack.

So, I thought I’d address some common questions / topics related to patching so that people have a better understanding of what patches to apply to their environments and when to apply them. 

This post is a part of both the OAM 11g academy and OIM 11g academy series.

Patches, Bundle Patches, Patch Sets and New Releases

The first thing I’d like to do is clear up some terminology that is frequently a source of confusion for Oracle Middleware customers.  There are four delivery mechanisms for updating Oracle Fusion Middleware software.

New Releases: New releases are major updates to software.  New releases always include major feature enhancements and can often include new ways of doing existing functionality and even complete new code basis.  Moving to a new release can sometimes be characterized as an upgrade but other times should be considered a migration where the old and new versions of software coexist side-by-side and certain applications, users, or functionality move from the old version of the software to the new release over time.

Patch Sets: The topic of what exactly a patch set constitutes in Fusion Middleware land is somewhat controversial but I’d like to throw out some practical guidelines based on my experience.

For starters, patch sets are applied at the package level.  To review, there are two major packages in the IDM stack today: 1) the IDM package containing OVD, OID, and OIF and 2) the IAM package containing OAM, OIM, and OAAM. 

Patch sets can be packaged as full installs, upgrades using the Oracle installer, or both.
To me, patch sets constitute minor new releases.  They may contain new functionality and may require some “post application” steps to complete the upgrade. 

Patch sets should be fully tested in the context of a customer specific deployment before being moved into production.

Bundle Patches: Bundle patches are sets of patches that fix multiple issues that are applied primarily through the OPatch utility.  Bundle patches usually do not contain new features and require few if any manual post application steps.

Bundle patches should also be tested in the context of a customer specific deployment before being applied to production systems but should be considered lower risk than patch sets.

One-Off Patches: One-off patches are patches for individual issues or very small sets of issues.  They are often issued to individual customers only.

What patches should I apply?

Now that we’ve cleared up terminology I’ll give some guidance on what patches one should be looking to apply.

In terms of patch sets.  I recommend that you apply the latest patch set for the release you are installing when doing a new deployment with the caveat that all the software being installed into one Fusion Middleware Home (or WebLogic domain) must be running compatible versions.  I discuss the issue of compatible versions extensively in my articles on domain architecture.

Beyond that, I strongly recommend that customers apply the latest bundle patches for every Oracle Identity Management product they are installing unless they have an explicit reason not to.

OAM, OIM, OIA, OAAM, and OES, have official bundle patches.  There are good support articles detailing the bundle patch histories of each product with links to the bundle patches available.  I wrote about these support articles here.  The link given to the OAM article is still valid.  The link given to the OIM article is for only.  There is a separate article (1360009.1) for OIM

The situation is a little trickier for OID, OVD, and their management application ODSM.  Traditionally these components have only been patches through one-off patches.  However, recently (what I like to call) pseudo bundle patches for these components have emerged for Fusion Apps build outs.

Even though these pseudo bundle patches are listed as Fusion Apps only, the earliest version of these patches was also recommended for non-FA deployments in the IDM Enterprise Deployment Guide.  Based on this fact and the content of the patches, I recommend that customers seriously consider applying the latest OID, OVD, and ODSM pseudo bundle patch.

You can find the specific IDs for these patches in the Fusion Application release notes (1355561.1).  Early versions of these patches were also mentioned in the IDM EDG

At the time of this article, the current versions of these patches seem to be:

12937765 for OID   This is the same patch recommended in the EDG.

13031079 for ODSM  This is a more updated version of the ODSM patch recommended in the EDG.

13031196 for OVD  This is a more updated version of the OVD patch recommended in the EDG. 

If you are doing an FA install or EDG style build out with OAM/OIM integration.  It is also important that you apply the IDM Tools patch for the ‘IDM Config Tool’.  The idmConfigTool is a command line utility used to automate portions of an OAM/OIM deployment.  It is very important that you apply the recommended patch for this tool before trying to use it.

Unfortunately, the guidance on what patch ID to apply for the IDM Tools for non-FA installs is a little weak.  My current recommendation is to apply the most recent patch available for the version of OAM/OIM that you are installing ( or 11.1.2).  If you have trouble identifying the right patch then I encourage you to reach out to support.

When should I apply patches in a new deployment?

In general, you should apply patches in a new build out after you have installed the software components you are deploying but before you create, extend, and configure the WLS domains.  Likewise, you should apply patches before creating instances for OID, OVD, and OHS.  It should be noted that my recommendation is in line with the sequence of events documented in the IDM EDG and more updated IDM EDG for FA.

Now, I’m not saying that you have to re-install if you don’t follow this order.  However, installing the patches this early is a good idea for a few reasons:

1) There could be fixes to the configuration wizard or other configuration tools that are present in the patch.  Applying the patch up front lets you take advantage of these fixes.  Again, this is especially important with the ‘IDM Config Tool’ patch.

2) It’s easier to apply the patches up front as you don’t have any services running that require starting and stopping.

3) If you apply the patches up front then you don’t have to worry about never getting around to it.  Too often I have seen customers continue to delay applying patching during their build outs to the point they go into production without patches that are strongly recommended.

How often should I apply new patches?

The short but obvious answer is as often as possible.  I will say that all too often I see customers struggle with issues that have already been fixed in available bundle patches.  All software includes bugs and as good as Oracle Middleware software is, it is no exception.  Applying regular bundle patches should be considered part of the cost of doing business for your business and the apps that leverage the Oracle IDM stack.

I’d love to see customers apply every bundle patch but I know that many won’t be able to meet that goal.  So, for those that can’t or won’t apply every bundle patch I’d ask you to consider a policy of applying every other patch.  This should put you in the ball park of applying bundle patches every 6-9 months.  I think that is a reasonable thing to suggest.

How to tell what patches have been applied to an environment?

The answer is run ‘opatch lsinventory -all’.  You can read my full blog post on this subject here.

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…

Tips and Tricks When Upgrading IDM for Fusion Applications – RUP1 through RUP3

In this article, I want to share some lessons learned from doing the IDM portion of the FA upgrade. Overall, the process of upgrading the security components is straightforward if you follow the instructions carefully, but there’s no denying that the IDM part of the upgrade is a little more hands-on and potentially confusing that the FA part.

A Note About Versions

When you start reading the documentation below, you may notice like I did that the naming convention for the upgrades is changing — up to now, the upgrades have been referred to RUP1, RUP2, etc., but the documentation no longer reflects that:
Version              Old Name                   New Name          FA 11gR1 RUP1         FA 11gR1 Update 1          FA 11gR1 RUP2         FA 11gR1 Update 2          FA 11gR1 RUP3         FA 11gR1 Update 3

You will see references to both naming conventions, so you should keep both in mind when searching in My Oracle Support or in your favorite search engine for information.
Important Note: These are incremental and not cumulative patches. You will need to apply RUP1 before you can apply RUP2, and the same goes for RUP3 (RUP1 and RUP2 need to be applied first).

The Documentation

Starting with RUP2/Update 2, the documentation you need to upgrade consists of three separate docs:

For RUP1/Update 1:
Release Notes: MOS Document 1382781.1
Patching Guide:

For RUP2/Update 2:
Release Notes: MOS Document 1439014.1
Patching Guide:
IDM Upgrade Procedure: MOS Document 1435333.1

For RUP3/Update 3:
Release Notes: MOS Document 1455116.1
Patching Guide:
IDM Upgrade Procedure: MOS Document 1441704.1

You should always start with the release notes before looking at the patching guide. The IDM upgrade procedure is a complement to the patching guide — while following the patching guide for the upgrade you’re performing, it will refer you to the IDM upgrade doc, which will then refer you back to the patching guide to continue.
Important Note: These docs have all been updated over time — make sure you check online before starting your upgrade to make sure that you have the most recent version!

Upgrading IDM from RUP1/Update 1 to RUP2/Update 2

Most of this consists of patching, but there are a couple of major changes on the IDM side, namely, the upgrade of the IDM Suite to from which in turn requires the upgrade of WLS in the IDM domain to 10.3.6.

Things You Should Do Before You Start the Upgrade

As of the time I’m publishing this, the RUP2 binaries on eDelivery come with the wrong copy of the IDM Suite installer (version instead of the required This means you will need to separately download the correct version from eDelivery. Once you have everything downloaded and ready to go, it’s worth going through the binaries to identify where the IDM-specific patches are so you don’t have to search for them later. In my case, everything was unpacked to “/u01/backup/rup2” on the machine where I first tried this:

Patch                Location
13797139        /u01/backup/rup2/installers/oracle_common/patch/13797139
13642895        /u01/backup/rup2/installers/oracle_common/patch/13642895
13686287        /u01/backup/rup2/installers/oracle_common/patch/13686287
13579026        /u01/backup/rup2/installers/oracle_common/patch/13579026
13782459        /u01/backup/rup2/installers/pltsec/patch/13782459
13620505        /u01/backup/rup2/installers/pltsec/patch/13620505
13399365        /u01/backup/rup2/installers/iam_patches/13399365
13115859        /u01/backup/rup2/installers/iam_patches/13115859
13684834        /u01/backup/rup2/installers/iam_patches/13684834
13477091        /u01/backup/rup2/installers/webgate/ext

Note that the last patch (13477091) is an OAM 10g patch for WebGate and is not applied with OPatch but run as a standalone executable.
In a similar vein, the doc references some common paths, and the example paths in the doc do not reflect the paths that are specified in the Enterprise Deployment Guide. I went through the paths on one of my lab servers which does follow the EDG:

IDM_ORACLE_HOME                             /u01/app/oracle/product/fmw/idm
OID_ORACLE_HOME                             /u01/app/oracle/product/fmw/idm
IDM_ORACLE_COMMON_HOME        /u01/app/oracle/product/fmw/oracle_common
IAM_ORACLE_HOME                            /u01/app/oracle/product/fmw/iam
OIM_ORACLE_HOME                            /u01/app/oracle/product/fmw/iam
IAM_ORACLE_COMMON_HOME       /u01/app/oracle/product/fmw/oracle_common
SOA_ORACLE_HOME                           /u01/app/oracle/product/fmw/soa
OHS_ORACLE_HOME                           /u01/app/oracle/product/fmw/web
WEB_ORACLE_HOME                          /u01/app/oracle/product/fmw/web
OHS_WEBGATE_ORACLE_HOME      /u01/app/oracle/product/fmw/oam/webgate
OHS_ORACLE_COMMON_HOME      /u01/app/oracle/product/fmw/oracle_common

Again, this is an exercise worth doing before you begin to make the upgrade steps go a little more quickly.

Following the Upgrade Doc

The upgrade doc divides the tasks into 13 steps, and I will highlight some specific comments below for the steps where I encountered an issue or where I felt that some clarification was warranted. For example, there are four patches (13797139, 13642895, 13686287 and 13579026) that you are instructed to apply in Step 6 and then again in Steps 7 and 8 and this made no sense at first. On a closer read, however, it became clear that the doc was covering a very generic deployment where the IDM Suite, the IAM Suite and the Web Tier were on separate WebLogic domains. And that’s not the case for FA installations that follow the EDG. So you really only need to apply the four patches in Step 7 because the WLS-based security components are all in one domain.

Step 4: Create Backups

Do not neglect this step! Upgrading FA is a large and complex effort.

Step 5: Download Required Patches

This step was a bit of a puzzle for me, because it belongs in the “Before Upgrading” section before Step 1. Besides, with the exception of the IDM Suite, everything else is included in the RUP2 binaries that you download from eDelivery.

Step 6: Upgrade the IDM Node

There should be no drama in this section, but remember from above that you can wait until Step 7 to apply those four patches. If you don’t, you will need to roll back and reapply those patches in the next step.

 Step 7: Upgrade the IAM Node

Remember that if you followed the EDG, the IDM and IAM nodes are one and the same and you have already upgraded WLS (and don’t need to do it again).

Apply Oracle Identity Manager patch 13399365

There are two things that happened to me when I tried this the first time. The first thing was an error from OPatch saying that this patch conflicts with patch 12961473. Turns out that this is a known issue and the fix is to simply roll back patch 13399365 and then reapply it. The second thing was deploying the new weblogic.profile file. There were some unfamiliar parameters that needed to be given values, and to save you some time, here is a copy of what it should look like for FA:

# For passwords if you dont want to put password </optional> in this file just comment it out from here, you will be promted for it in rumtime.
#Neccessary env variables [Mandatory]
#DB configuration variables [Mandatory]
# Database password is optional. if you want to  give it on terminal itself leave it commented. Otherwise uncomment it.
# If you have milty-tenancy enabled in your environment
mdsDB.user=<MDS DB Schema owner>
#Password is optional,  if you want to  give it on terminal itself leave it commented. Otherwise uncomment it.
#mdsDB.password=<MDS DB Schema password><MDS DB Host>
mdsDB.port=<MDS DB port>
mdsDB.serviceName=<MDS DB ServiceName>
#For domain level configurations [Mandatory]
# put here your admin server related credentials
#Password is optional,  if you want to  give it on terminal itself leave it commented. Otherwise uncomment it.
#oim specific domain level parameters [Mandatory]
#SOA specific details [Mandatory]
#put here the name of the targets of taskdetails. in non cluster it will be soa server name and in cluster it will be something like cluster_soa
#Following params is needed only if you have enabled OHS in your env
#If your env is FA, you can set this var false or ignore this if your env is non FA.

The script is in the same directory as weblogic.profile. You may see an error in the last step that it runs, and this seems to be due to the fact that the script tries to deploy SOA stuff before the server is fully up. This is another known bug, and the easiest fix is to check for undeployed apps in the WebLogic console and manually deploy them.

Upgrading IDM from RUP2/Update 2 to RUP3/Update 3

Most of this consists of patching, but there are a couple of changes on the IDM side, namely, the upgrade of the WebGates to 11g from 10g. The other thing (and it’s not quite spelled out in the doc) is that the FA database is upgraded to, and while this is mandatory for the FA DB it is optional for the IDM DB. For that reason alone, if you are going to upgrade the IDM DB as well, I recommend that you wait until the overall upgrade is complete and smoke tested before doing it.

Things You Should Do Before You Start the Upgrade

Once again, you should map the homes as above to have those paths handy, and locate the patches in the RUP3 binaries before rather than during the upgrade:

Patch 12575078, which contains Oracle Access Manager WebGates (
Patch 13453929 for Oracle Access Manager WebGates
Patch 13735036 for Oracle Identity Manager
Patch 13768278 for IDM Tools. Note: Be sure you download the version of this
patch, which is named
Patch 13787495 for Oracle Access Manager Config Tool
Patch 13879999 for Oracle Internet Directory
Patch 13893692 for Oracle SOA Manager
 /u01/rup3/installers/oracle_common/patch/13893692 < for ORACLE_COMMON_HOME
 /u01/rup3/installers/soa/patch/13893692 < for SOA_HOME
Patch 13901417 for Oracle Access Manager

Important Note: Patch 13893692 has two parts that are applied separately, and the two parts live in different directories.
Finally, when you install the 11g WebGate(s), you will need a couple of specific gcc libraries present, and for me, my server had the 32 bit versions but not the required 64 bit versions. You can build these from scratch by downloading the source from GNU, but if you’re like me and in a hurry sometimes, you can just get them via yum:

 yum update libgcc
 mkdir /u01/app/oracle/product/fmw/gcc_lib
 cd /u01/app/oracle/product/fmw/gcc_lib
 ln -s /lib64/ ./
 ln -s /usr/lib64/libstdc++.6.0.8 ./

You will need this in Step 9.

Following the Upgrade Doc

Same applies here as above — there are 14 steps in this doc with a special section that applies to Solaris.

Step 8: Upgrade the IAM Node

When you apply patch 13893692, you will get a message stating that it is already present. Just to be safe, I did a roll back and reapplication of it.

Step 9: Upgrade the OHS Node

This is where you need those gcc libraries — from the installer, specify the path that contains the symbolic links above (/u01/app/oracle/product/fmw/gcc_lib for me) for the location of the gcc libraries. The file names have to match those above.
In the new httpd.conf file, you may need to add the following lines to ensure that all logins work as they previously did:
You may need to add one line to httpd.conf to ensure that login works correctly:

 #*******Default Login page alias***
 Alias /oamsso “/u01/app/oracle/product/fmw/oam/webgate/access/oamsso”


So that’s it. If you’re careful and methodical, you shouldn’t encounter any issues for the IDM part of the upgrade. The two upgrade docs, while a bit confusing in some respects, are complete and should work for you. If anybody has their own experiences to share, please do.

Domain Architecture and Middleware Homes Revisited

Over a year ago I wrote a couple important posts about the domain architectures used in Oracle Identity Management deployments.  You can find these posts here and here.
These posts have been very popular.  I’ve received lots of positive feedback on them but also a fair number of questions.  So, I thought that it would be worth revisiting the topic now.

 Let’s Review My First Post

So, the central premise of my first post was that it is a good idea to install products from different distribution packages into different WebLogic domains.  Specifically, I am recommending that customers install the IAM package (OAM,OIM,OAAM) into a separate domain from the IDM package (OID,OVD,OIF).   Same thing goes with products from either package and WebCenter or SOA suite. 
The reason is that it introduces the risk that different components (libraries, jars, utilities), including custom plug-ins, from the different packages that you are installing in the domain might be incompatible and cause problems across your entire domain.
Beyond the risk of such an incompatibility, you also must consider how installing multiple packages into one domain reduces your flexibility to apply patches and upgrades.
The exception to this warning is SOA Suite for OIM. SOA Suite is a prerequisite for OIM and as part of the stack that supports OIM should be installed in the same domain as OIM. However, if you use SOA suite for other purposes, you should consider setting up a separate install for running your own services, composites, BPEL processes etc.
Let’s Review My Second Post
In my second post I discussed whether or not to split up products from the same package into multiple domains.  I argued that while the incompatibility issue isn’t such a big deal but that the additional flexibility of deploying in different domains could still be beneficial.  I did warn though that OIM/OAM/OAAM integration is only supported with all the software running in the same domain.
Advice Revisited
A year and a half later, I still strongly stand by the advice in my posts.  I’ll put it this way, I’ve worked with people who regret deploying multiple packages into one domain for all the reasons I mentioned but all the people I’ve worked with who have gone with a split domain model across packages have been happy and glad they’ve gone that route.
That being said, there are a few clarifications and updates to my advice that I’d like to now make.
It’s About Middleware Homes (Install Locations) Not Just Domains
One thing that I want to make clear is that my advice about separating the products from different packages extends beyond domains to Middleware Homes which are the root directories for the Middleware products that you are installing together.  To avoid the conflicts and restrictions that you can run into by installing multiple packages together you need to install them in separate Middleware Homes, just separate domains is not enough.  It is true that most people just create one domain per Middleware Home but I’ve seen some examples of multiple domains in a Middleware Home recently so I thought this was definitely worth mentioning.
Domain Architecture for OAM/OIM Integration
The limitation that you have to put OAM and OIM in the same domain if you want the integration to work has, shall we say softened.  I would still say putting them in the same domain is the easiest and most tried and true path (the yellow brick road if you will).  However, if you utilize a real OHS based OAM agent rather than the domain agent; you can make the integration work with OAM and OIM in separate domains.  In fact, the most recent IDM EDG for FA includes this option.
Fusion Applications
Speaking of Fusion Apps, I do want to discuss this advice in the context of Fusion Apps.  As I describe here, the IDM build out for Fusion Apps is prescribed very specific process with a specific architecture.  It is very likely you will run into issues deploying Fusion Apps on top of an IDM environment that deviates from this architecture as FA has made certain assumptions about how the IDM environment will be set up.
In the context of the domain discussion, the IDM EDG for FA does steer you down the path of creating one big IDM domain that contains OID, OVD, OAM, OIM, ODSM, and potentially OIF.  This is of course contrary to the advice I’ve been giving.  In the context of FA though I think this is OK.
When using the IDM products with FA you are restricted to very specific versions of the IDM products in the stack, so upgrade flexibility and incompatibility concerns isn’t really an issue.  Also, as I said, the FA provisioning process may be expecting the Oracle IDM/IAM products to be deployed in a single domain.  So, for FA I advice people to follow the EDG and stick with the single domain model or moving forward whatever models are documented in the IDM EDG for FA.

OIM 11g Localization Tips

As any other enterprise application, OIM 11g provides localization features: it detects user’s browser language configuration and presents the UI to the end user accordingly to the configured language.Customers can plug a lot of custom code and objects…

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

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

The Worlds Most Dangerous WebLogic Identity Asserter

…or how Josh stole my idea for a post in one paragraph.In a recent post Josh saidThere is another approach that, unfortunately, is rather common – use a Web Gate in front of WebLogic Server and use a very weak identity asserter or no SSPI connector a…