Identity and Cloud Security A-Team at Oracle Open World

I just wanted to let everyone know that Kiran and I will be presenting with our good friend John Griffith from Regions Bank at Oracle Open World next week. Our session is Oracle Identity Management Production Readiness: Handling the Last Mile in Your Deployment [CON6972] It will take place on Wednesday, Sep 21, 1:30 p.m. […]

Protecting Intranet and Extranet Applications with a Single OAM 11g Deployment

I frequently get asked how to setup a single OAM deployment to protect both intranet and extranet apps. Today I’d like to explore the issues and solutions around such a setup.

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

The Requirement

So the specific request is how to set up OAM so that it can protect intranet applications that can be accessed only from within the corporate network and extranet applications that can be accessed from the public internet.

The “Problem”

The issue (or apparent issue) that people see with creating such a solution is that OAM 11g is configured with a single “front end host” configured through a global setting that governs what protocol (HTTP/HTTPS), hostname, and port are used when users must be redirected to the OAM managed server.

If you go back and look at Chris’s post on the OAM 11g login flow and cookies then you’ll see that there are points in the flow where the user is redirected to the OAM managed server. This redirect can be to a load balancer or HTTP server fronting a managed server or cluster of OAM managed servers. So, OAM allows you through the “load balancer” settings to specify the interface that is fronting the OAM manage server(s).

The issue is that there is only a single global setting for defining the front end host for OAM. So people ask how can we protect intranet and extranet applications with one OAM deployment?

There are in fact two solutions to meeting this requirement.

An Extranet Front End Host for OAM

The first solution is to simply specify an extranet (externally accessible) host as the front end host for OAM. This way both intranet users accessing internal applications and extranet users accessing external applications from the internet can access the OAM server through the same front end host.

OAM Deployment with External Front End Host

This architecture is the recommended reference architecture for supporting this requirement. It is also the simplest solution to implement. The idea that you need to wrap your head around here is that even though your application may be accessible only from within the corporate network, that does not mean that your users cannot be sent at times (during login and initial SSO) to an externally accessible web server.

I do sometimes hear objections to this solution from customers who say that they want to keep their intranet users on the internal network. I have to admit that I don’t fully understand this objection. When I inquire as to what specifically they are concerned about I usually get a fairly vague response. In addition, it should be noted that on many if not most corporate networks, the user wouldn’t be sent all the way out to the internet to access the OAM front end host but rather just to the DMZ.

That being said, for customers that really want to keep intranet users on the internal network there is another solution.

Split DNS

I found a really good article by Thomas Schinder that explains split DNS. You can read it here.

The basic idea specific to an OAM deployment is that you setup your DNS so that your front end host for OAM as defined in the load balancer setting (say resolves to an externally accessible load balancer or web server when users query the host from the public internet but resolves to an internal load balancer or web server when users query the host from the internal network.

OAM Deployment with Split DNS

Split DNS works really well with OAM and is a completely viable option for enabling OAM to protect both extranet and intranet solutions simultaneously.

Identity Stores

There is a second unrelated issue that sometimes faces people wanting to do a single OAM deployment for external and internal applications and that is how their users are stored.

There are many variations on identity store requirements for hybrid internal/external deployments and I will save this discussion for another day but I wanted to mention it now as something to consider if you are planning such a deployment.

OAM and OIM 11g Academies

As many of you know, last year we created indexes of posts on OAM and OIM 11g R2 that we call OAM 11g Academy and OIM 11g Academy.

These indexes contain the articles we’ve written that we believe provide long lasting guidance on OAM and OIM.  Posts covered in these series include articles on key aspects of OAM and OIM 11g, best practice architectural guidance, integrations, and customizations.

It is our hope that these series will prove valuable to new and experience architects, implementers, and administrators of OAM and OIM.

Over the last few months, we haven’t been the best about updating these series to include new articles we’ve written.  That being said, we have gone back and brought the indexes up to date.  This is especially true on the OIM side where we have added many articles including some specifically on the new R2 release and have organized the index of articles into categories.

Going forward, it is our intent to continue to add to both the OAM and OIM series with lots of new content.

One thing to note, articles that apply specifically to R2 (and future releases) will explicitly say so in the index.  Likewise, any article that does not apply to the current release will be edited to note that.  Any other article in the indexes should be viewed as applying to all versions of 11g.
The links for the academy series are:

OAM 11g Academy

OIM 11g Academy

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.

Achieve Faster WebLogic Authentications with Faster Group Membership Lookups

In my last post  I wrote about the complicated and timely process of determining all of a user’s group memberships when an LDAP namespace includes nested and dynamic group memberships. I wrote about how you can simplify and speed up getting a user’s group memberships through the use of a dynamic “member of” attribute and specifically the orclMemberOf attribute in OID.

Today I’d like to extend this discussion to WebLogic server authentications.

A Review of LDAP Authenticators and Groups

As I’ve written about in the past, as part of the authentication process, LDAP authenticators do a search to determine what groups the user is a member of which in turn get used in determining the group memberships and roles for the JAAS subject and principals.

By default the WebLogic LDAP authenticators follow the long time consuming process I laid out in my last post for determining group memberships with nested groups. First, it searches all your groups to figure out which groups your user is directly a member of. Then for each of those groups, it searches all your groups again to see which of those groups your user is a member of.

It will continue to search your groups with the results of each subsequent search until you reach the configured maximum level of nested memberships that you want to pursue or all the searches come back empty.

Only it is actually quite a bit “worse” than that because for some reason when the authenticator finds a group within a group it doesn’t just use the DN of that group in the next search, it takes the name of that group based on the “group name attribute” setting in the authenticator and then does a search to find the group’s DN all over again. So, for every group found in a search of memberships for the user there will be 2 new LDAP searches performed. One to get the user’s DN again and one to get the groups that group is a member of.

In my post on tuning LDAP authenticators, I wrote about the importance of tuning the settings governing group membership searches in the authenticator and specifically about limiting the depth of the searches for nested group membership.

Speeding Things Up

Today, I’d like to cover how-to dramatically speed up this process by letting the directory do all the work for you. This is achieved by configuring the authenticator to take advantage of the dynamic ‘member of’ (orclMemberOf in the case of OID) attribute that I wrote about in my last post.

The setting that enables this behavior is in the Dynamic Groups section of the provider specific configuration for LDAP authenticators and is called User Dynamic Group DN Attribute. When configured the LDAP authenticator will skip all searches (for both direct and nested memberships) of dynamic groups. Instead it will add roles (group principals) to the user for every group returned by the LDAP directory (OID) in the value of the specified attribute.

Here is what you need to know about this setting:

1) When configured the authenticator will add roles (group principals) to the user for every group returned by the LDAP directory (OID) in the value of the specified attribute.
2) Despite the fact that the setting is part of the Dynamic Group section of the authenticator configuration, the authenticator will add roles for every group returned as part of the value of the attribute, regardless of whether that group is a static group or dynamic group.

3) That being said, the authenticator will still perform a search of memberships for all static groups even when the User Dynamic Group DN Attribute is defined. It will not however perform a membership search of dynamic groups; instead it assumes all dynamic group memberships are captured by the attribute value.

Note especially that the authenticator will still perform a full search of nested static groups even when User Dynamic Group DN Attribute is defined; even though the orclMemberOf attribute in OID includes static group memberships.
Putting It All Together
So, to dramatically improve your WebLogic authentication performance with nested groups I recommend that you configure your authenticators as follows:

1) Enter the appropriate LDAP attribute name for the value of User Dynamic Group DN Attribute based on the type of directory you are authenticating against.. Appropriate values include orclMemberOf for OID, memberof for DSEE, and ismemberof for AD.

2) Set the value of GroupMembershipSearching to limited. The default value is unlimited.

3) Set the value of Max Group Membership Search Level to 0. This will make the authenticator not perform searches for nested group memberships and limit it to performing a single search to find the users direct group memberships. Again, we will be relying on the value of the attribute specified in User Dynamic Group DN Attribute to give us the nested searches.

4) If you want to even eliminate the direct group membership search you can specify an empty Group Base DN. Note here that the Group Base DN must exist or you’ll get an error and a failed authentication. However, it can be empty. So, you can create cn=fakegroupbase as a sibling of cn=Groups,dc=example,dc=com.

5) If you recall in my previous post I mentioned that using the orclMemberOf attribute can result in duplicate listing when nested memberships are returned multiple times, once for each group that the user belongs to that is a member of another given group. Because of this, you’ll probably want to check the Ignore Duplicate Membership option in the authenticator.

Below is a screen shot of an OID authenticator configured with these options:

Fast Group Membership Lookups in OID with the orclMemberOf Attribute

If you utilize nested and dynamic groups (and especially nested dynamic groups), then it can take a lot of effort and time to calculate all of a user’s group memberships in an LDAP directory.

First you have to search for the user and find the user’s DN. Then you have to search all your groups to figure out which groups your user is directly a member of. Then for each of those groups you have to search all your groups again to see which of those groups your user is a member of.

You have continue to search your groups with the results of each subsequent search until you reach the maximum desired level of nested memberships that you want to pursue or all the searches come back empty. All the while you have to keep yourself out of infinite loops created by repeating memberships such as when two groups are members of each other.

Many LDAP directories simplify things through a virtual “member of” attribute which is a virtual multi valued attribute containing all of the groups a user is a member of through both direct and indirect means.

It may have escaped your notice, but OID joined the party fairly recently (in I believe) and now supports such an attribute. The attribute’s name is orclMemberOf. You can read all about the attribute here; but suffice it to say it is a dynamic multi valued attribute containing the groups to which a member belongs.

The membership includes both direct membership and indirect membership from nested groups. It also includes membership from dynamic groups and dynamic nested groups based on labeleduri.

The attribute value is computed during a search and is not stored. This means you will not see orclMemberOf populated in an LDAP data browser including ODSM. Further, the value is not returned by default in searches. You have to explicitly request it. Lastly, orclMemberOf cannot be used in a search filter.

One nice little additional feature thrown in is that the aliases of memberof and ismemberof are supported for compatibility with code written for compatibility with Active Directory and Oracle Directory Server Enterprise Edition (DSEE) / SunOne / IPlanet.

Below is a sample search with results for a specific user where I request and receive the value(s) of orclMemberOf.  You will also notice that nested memberships are returned multiple times, once for each group that the user belongs to that is a member of another given group.  So, watch out for that.

In a future post, I’ll discuss how you can use the orclMemberOf attribute to greatly speed up authentication into WebLogic and Fusion Middleware Products such as SOA Suite and WebCenter which utilize WebLogic’s security framework.

[oracle@oam1 bin]$ ./ldapsearch -h -p 3060 -D cn=orcladmin -w Oracle1_g -b “cn=Users,dc=example,dc=com” -L -s sub -v “uid=tim.doyle” memberOf

ldap_open(, 3060 )

filter pattern: uid=tim.doyle

returning: memberOf

filter is: (uid=tim.doyle)

dn: uid=tim.doyle,cn=users,dc=example,dc=com

memberof: cn=administrators,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=nyusers,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=nestgrp1,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=oaamcsrmanagergroup,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=oaamenvadmingroup,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=oaamruleadministratorgroup,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=product support group,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

1 matches

Sample External Login.jsp page for Oracle Access Manager 11g

One of the more popular posts on our blog was a post I made a while back about how to configure OAM 11g to use an externally hosted custom login page and how to write such a login page.

When I originally wrote that post I included only snippets from a JSP page that represents an external OAM login form.

I have updated that post with a full sample login.jsp that functions as an external login form for OAM 11g.  The code is also included below.

To review, to work as an external login form the login page code must do the following:

• You need to post back to the OAM server to the URI: “/oam/server/auth_cred_submit”. Note that in my sample, I’m posting to a load balancer VIP over SSL which will route the post to one of the OAM servers in my cluster.

• You need to post variables “username” and “password”

• You need code that will grab the request_id off of the query string and post it (as a hidden form variable) as well.

The Code

    <%@ page contentType="text/html; charset=iso-8859-1" language="java" %>
String error=request.getParameter("error");
if(error==null || error=="null"){
String paramName = "request_id";
String reqId = request.getParameter( paramName );

<title>User Login JSP</title>
function trim(s)
return s.replace( /^\s*/, "" ).replace( /\s*$/, "" );

function validate()
alert("Login empty");
return false;
else if(trim(document.frmLogin.sPwd.value)=="")
alert("password empty");
return false;

<p>Acme Clinical Applications Login Screen - OAM edition</p>
<form name="frmLogin" onSubmit="return validate();" action="" method="post">
User Name<input type="text" name="username"/><br/>Password &nbsp;<input type="password"
<input name="request_id" value="<%=reqId%>" type="hidden"> <br/>
<input type="submit" name="sSubmit" value="Submit"/>

Deploying OAM 11g Correctly Part 2 – Logins and SSL

This is another post in our OAM 11g Academy series. To view the first post in the series which will be updated throughout to contain links to the entire series, click here:

A couple months ago Chris wrote a good post about the best way to deploy OAM from a web server / network architecture point of view.

Today, I’d like to touch on a very important but overlooked aspect of OAM deployments which is whether or not to use SSL between the web server and OAM. The product documentation and broader OAM writings out there in the community do a good job of describing the webgate to OAM server communication (OAP) security modes of open vs. simple vs. cert mode. However, what is completely neglected is the discussion of whether or not to use SSL between the web server and OAM.

This discussion applies to architectures where the OAM server is being fronted by a web server (usually OHS). This includes Fusion Apps deployments, the integrated IDM deployment described in the IDM Enterprise Deployment Guide (EDG), and many other custom deployments.

OAM 10g vs. 11g

In OAM 10g, users login by submitting credentials to the webate which then passes them along over the OAP protocol to the access server (OAM server equivalent in 10g). So, in 10g it was extra important to use simple mode or cert mode for the webgate to OAM communication if you don’t want credentials going over the wire.

In OAM 11g, users login by submitting credentials directly to the OAM server (running in WLS) which can be exposed directly to the user or put behind a web server (usually OHS). This means 2 things:

1) Credentials are no longer going over the webgate to OAM (OAP) connection. This somewhat lessons the value of using simple or cert mode; although username and response information that potentially carries confidential data still goes over this connection.

2) In the case where OHS is fronting OAM, user credentials are going from OHS to OAM/WLS. This means that if you don’t want those credentials to travel over the wire in the clear, that you should configure this connection to be over SSL.


If your security requirements and network are such that you want to encrypt credentials and other potentially confidential information going between the web server (OHS) and OAM, then you should configure the webgate to OAM communication to be simple or cert mode and configure the OHS to OAM/WLS communication to be SSL (HTTPS).

If your security requirements and network are such that you don’t care about encrypting credentials that go over the wire between the web server (OHS) and OAM then use open mode for the webgate communication and normal HTTP for OHS to OAM/WLS.

The following diagram illustrates both of these options.

I would argue it doesn’t make sense to do what many people do which is to use simple mode for webgate communication but normal HTTP without SSL for web server (OHS) to OAM/WLS communication.

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.

Retrieving and Setting HTTP Headers in BPEL

The capability to retrieve and set HTTP headers in BPEL was recently added to Oracle SOA Suite 11g. Edwin Biemond has written an excellent blog post on how to use this capability.

From a security/IDM perspective, I think this feature opens up the ability to create some interesting solutions whereby identity information is added to HTTP headers by OAM (or other SSO products) in the web tier and consumed by services in the app tier. It also makes it possible to pass identity data between services in HTTP headers and thereby ignore having to modify web service requests themselves.

I’ll only add as a warning to remember that end users have the capability to add whatever HTTP headers they want to the requests they make. So, solutions should be developed with this in mind. In particular, if you are going to create a solution that depends on BPEL consuming an HTTP header created by an OAM response, you need to take steps to either ensure that this header really came from OAM (by signing or encrypting it) or take steps to ensure that all requests to BPEL really did originate by coming through the web tier with OAM.

Validating an Oracle IDM Environment (including a Fusion Apps build out)

In this post I walk you through how to validate an Oracle Identity Management build out containing OID, OVD, OIM, and OAM. This post was motivated by work I have done with Fusion Apps.

It is important to validate the IDM build out for Fusion Apps before you move on to the provisioning of Fusion Apps itself. Problems detected during the IDM build out are much easier to diagnose and fix than problems detected during FA provisioning, FA functional setup or FA operations themselves.

In addition, it is important to have documented validation steps for your Oracle IDM environment to use at other points as well. For instance, you will want to validate your IDM environment when you bring it back online following a backup.

Lastly, you will want to be able to go through validation steps for your IDM environment as a means of debugging IDM related application issues. For example, let’s say people come to you all of the sudden saying they can’t login to a Fusion HCM application. You’ll want to be able to go through the IDM validation steps to see what if anything is wrong with the IDM infrastructure that could be causing this issue.

Again, I wrote this with Fusion Apps in mind but everything here also applies to enterprise Oracle IDM build outs that use OID, OVD, OIM, and OAM. The only differences may be that for an enterprise deployment, the IDM services may be spread out across multiple WLS Domains and the system account being verified in the OID validation step may be different.

Recommended Validation Steps

The following are test cases for validating your IDM environment from bottom to top. We begin with just verifying that all services are running, move onto validating that the directory services are working, and then onto validating that OAM and OIM are working. We finish up with advanced but important tests that validate that SOA suite (the workflow provider for OIM) is working properly with OIM and that OAM/OIM integration is working.

These are descriptive test cases rather than fully documented click by click instructions. If you new to the Oracle IDM stack I encourage you to put in the time to flush this out into click by click instructions.

1) Verify all services are running. Login to IDM Domain admin server and ensure that all managed servers are up and running.
a. Go to environment –> Servers.

b. Make sure that the AdminServer and all 4 Managed Servers (OAM, OIM, SOA, and ODSM) are in Running state

2) Verify ODSM and OID. Go to ODSM connect to OID and verify that you can see all users and JPS root (for policy data).

a. Go to ODSM:

b. Click on Connect to a directory and choose OID

c. Go to Data Browser and verify the following folders under Root:

idm_jpsroot: this folder should look like this:

dc=com –> dc=mycompany should look like this:

Make sure the following users are present:

Make sure the following groups are there:

f. For each one of the groups below, make sure user membership is as follows:

cn=IDM Administrator
1)      3) Verify OVD 
a.       Go to ODSM and connect to OVD
b.      Go to Data Browser and verify that you can see the dc=mycompany, dc=com tree
c.      Verify that you can see change log data.  Verify ACL (security) during first validation, but this can be skipped on restart validation.
1)      4) Verify OID and OVD for LDAPS.  If doing LDAPS repeat steps 2 and 3 for LDAPS ports
1)      5) Verify OAM admin console 
a.       Go to OAM admin console and verify that login form is being served through “SSO” virtual host (  
b.      Verify that you can see policy data.   
c.       Sign out, you should see the login screen again.
1)      6) Verify OAM and EM
a.       Go to EM and verify that the login form is an OAM login form being served through the “SSO” virtual host (
b.       Verify that EM sees all the IDM services. 
c.       Logout.
1)      7) Verify OAM and OIM. 
a.       Go to OIM as xelsysadm and verify that the login form is the OAM login form being served through the “SSO” virtual host. 
b.      Verify that you can see all the users. 
                                                               i.      Go to Administration
                                                             ii.      On the left hand side perform a blank search for Users
                                                            iii.      Verify you can see the users from item #2 above
c.       Verify that you can see all the roles.
                                                               i.      On the left hand side perform a blank search for Users
                                                             ii.      Verify you can see the groups from item #2 above
1)      8) Verify OIM part 2. 
a.       Create user and a role in OIM
b.      Assign the user you created to the role you created
c.       Verify that it all shows up in OID
1)      9) Verify OIM part 3.

a.       Create user in OID and assign it to a group. 
b.      Login to OIM as xelsysadm and do reconciliation for both users and rolls. 
c.       Verify that you can login as that user into OIM, verify that the user shows up in OIM and that user has role that is mapped to group that you assigned user to in OID. 
1)      10) Verify OIM part 4.  Verify that SOA is working with OIM. 
a.       Login to OIM as xelsysadm, create another new role “test role 1”.  Logout. 
b.      Login as the test user you created, go to requests, create request, request for me, self assign role, then select “test role 1”.  Logout. 
c.       Login as xelsysadm and see that the request is awaiting your approval.  Approve the request.  You’ll have to do the approval twice.  The first approval is for the request and the 2nd approval is for the operation.
d.      Verify that the test user has been assigned the role they requested.
1)      11) Verify OAM/OIM integration and in particular OIM to OAM connectivity. 
a.       Create a new user in OIM and assign that user the IDM Administrator role. 
b.      Login to EM as that user.  You should be taken to OIM self service page to reset the user’s password and fill in forgotten password questions.  When that is complete you should be taken back to EM without having to login again.

Peripheral Responsibilities Required for Large IDM Build Outs (Including Fusion Apps)

Complexity and delay can occur during deployments of Oracle Identity and Access Management products (including the IDM build out for Fusion Apps) due to the fact that certain tasks required for the build out can sometimes only be performed by individuals that are not a part of the core team doing the deployment.

In many organizations IT responsibilities are very siloed. Some tasks during an IAM deployment may require assistance from individuals that operate in silos that are different from the team doing the deployment itself.

It is important to identify these tasks up front. When possible it is a good idea to make as many of these tasks as possible pre-requisites to the actual onsite installation/deployment. When that is not possible, then it is important to line up the assistance that will be required from role players who are outside of the core install/deployment project team to perform tasks that require their help.

The following are examples of such tasks:


1. Provisioning of virtual hosts and VIPs.

2. Configuration of load balancers.


1. Provisioning of DB including install, configuration, and creation of instances.

2. Running the RCU.

3. DB backups

Machine and Storage Provisioning

Provisioning shared storage and machines required for install. Provisioning of machines themselves including the installation and patching of OS. You’d think this would go without saying, but I’ve seen enough projects get delayed due to a lack of machines and storage that I feel I have to mention it.

Root Access

Root access is required during the creation of oraInventory and at several points during the web tier, OID, and OVD install. It is also required to do environment (file system) backups if backup is done as dictated by the EDG. One possible alternative is to do the backup as the install user and then separately backup the few files that are owned by root which do not change from the early stages of the install.

Certificates – PKI Administration

People often forget about the creation of certificates needed for SSL connections and web services security until they are actually needed. The trouble is that in many organizations, the team of people that create certificates for the organization is often small and the process by which certificates are requested and granted can take time. I recommend that when possible certificates be requested and created in advance.

When the request must come from a software component that is being installed as part of the deployment, it is still a good idea to talk to your PKI administrators in advance to make sure that the procedure for issuing the request is clear and to give them a heads up that you’d like the certificate issued as quickly as possible.

ADF Security and OPSS Policies – Sample Application

In the January / February issue of Oracle magazine, Frank Nimphius wrote a good article on ADF security and OPSS policies.  The article includes a good sample application that utilizes ADF and OPSS security, along with a pretty thorough explanat…

Planning an IDM Build Out for Fusion Apps Part 2 – Pre Build Out Checklist

In my last post I listed all of the architectural decisions that you’ll want to work through before diving into an IDM build out for Fusion Apps.

In this post, I’d like to take things one step further and put forth a checklist of tasks that you’ll want to accomplish before beginning the actual (onsite) build out.

Failure to complete these items before the build out will turn what is already a fairly long and intensive process into a longer and frustrating process. You want to make sure going into the actual build out that you have all the necessary hardware, software, and skill pre-requisites to ensure success.

The IDM build out for Fusion Apps and the Fusion Apps install in general is really a project where advance planning with pay off in spades.

So with that being said, I give you my list:

Machine Provisioning

• You should have all machines built out and patched to current OS patch levels before onsite install begins. Make sure that appropriate amounts of RAM, SWAP, and disk capacity has been allocated to each node in the install.

• You should also have all required system accounts created and available before onsite install begins.

• You should make sure there is graphical access to the machines being used in addition to command line. VNC (virtual terminal) is recommended over X-Windows forwarding as we’ve seen screen rendering issues with our install GUIs and X-Windows forwarding.

• Be sure that shared storage is mounted and reliable. The shared drive (NFS or CIFS) must support file locking. For NFS Version 3, the advisory locking must be configured for the NFS mount. This applies to all UNIX platforms. Please, make sure that your shared storage is really up to the task. I’ve seen a surprising number of FA install projects go bad over the last few months due to sub-standard shared storage.

Download all packages and patches

The Packages

Identity Management for Fusion Applications involves installation of the following:

• Oracle Database 11g R2

• JDK (JRockit 64-bit)

• Oracle WebLogic Server

• Oracle Fusion Middleware Web Tier (Oracle HTTP Server)

• Oracle Fusion Middleware SOA Suite

• Oracle Identity Management (OID and OVD)

• Oracle Identity and Access Management (OIM and OAM)

• Oracle Access Manager WebGate

The packages for the IDM build out are included in the eDelivery media kit for Fusion Apps. Search for Product Pack: Oracle Fusion Applications. You can also download each package indivivdually from OTN (Oracle Technical Network). Just make sure that whatever you do you are using the appropriate version of each package. For FA V1 RUP1, all IDM software should be but the web tier and IDM packages have to be installed at and then upgraded to

I also highly recommend that you do checksums on all downloaded packages before beginning the install to make sure that everything downloaded cleanly.

GCC Libraries for OAM 10g WebGate

The WebGate requires you to provide GCC runtime libraries during installation.

64 bit libraries for LINUX can be found in support article 840870.1

32 bit libraries can be gotten using the GCC Libraries for Oracle Identity Federation line on:

GCC libraries for other OS systems should be tracked down in advance of onsite time.

The Patches

As of right now, there are a fair number (8+) patches required for the IDM build out of Fusion Apps. It is important that you are applying the latest required list of patches. To obtain the current list of patches for the IDM build out, refer to the most recent version of the Fusion Apps release notes and IDM EDG for Fusion Apps. Once you have the list you can get the patches off of or through eDelivery.


Be sure you have downloaded and review the current version of the Enterprise Deployment Guide for Identity Management (Fusion Apps Edition) and the Fusion Applications Release Notes. For the release notes, this should include both the base release (V1) release notes and the patch set (RUP1) release notes. The release notes are very long but it is important that you review them for the following items:

1) The latest list of required patches for IDM.

2) Any additional configuration steps listed in the release notes that are not in the IDM EDG for FA.

3) Known issues that you should know about.

Database Build Out

Two Oracle Database instances should be created before the onsite install begins. One is for OID and the other is for the rest of the IDM components. You should verify up front that the database is the correct version, configured with the correct parameters, and the correct character set (ALT32UTF8).

It is also advisable that customers complete chapter 3 of the IDM EDG –Configuring Database Repositories:

There are several reasons to do this in advance:

1) This is the first actual step of the install.

2) In many organizations this will be performed by DBAs whose availability can be scarce.

3) Successfully running the RCU tool to configure the repositories validates that the there is a working DB that can be used for the install and that the necessary information to use it has been collected.

Network Prerequisites

DNS Aliases

DNS aliases for the following virtual hosts should be created before the onsite install begins. The usage of these virtual hostnames is discussed in detail in the IDM EDG for FA. – Resolves to load balancer or web server fronting WLS admin server for the IDM domain running on IDMHOST1. – Resolves to load balancer or web server fronting the OAM and OIM managed servers running on IDMHOST1 (and IDMHOST2 if HA) and OIMHOST1 (and OIMHOST2 if HA). – Resolves to load balancer or web server fronting WLS admin server for the OIM managed servers running on OIMHOST1 (and OIMHOST2 if HA). – Resolves to the load balancer fronting the LDAP identity store or the LDAP server itself. – Resolves to the load balancer fronting the LDAP policy store or the LDAP policy store itself.

Load Balancer Configuration

If one or more load balancers will be used in the environment, it is advisable to configure it in advance of the install. The following is a sample mapping of what will need to be provided to the network administrator responsible for configuring the load balancer.

Front End HTTP(S)

HTTP –> –> –>

HTTPS (SSL terminating at load balancer) –> 7777 7777 –> 7777 7777 –> 7777 7777

LDAP Load Balancer –> –>

LDAPS –> –>

Virtual IP Addresses

If customers are building an HA environment and wish to be able to bring up the WLS/OAM admin server on a secondary box (IDMHOST2) in the event that the first box becomes unavailable, then they will have to provision a virtual IP address to the subnet of IDMHOST1 and IDMHOST2 and initial configure the IP address for IDMHOST1.

Additionally, virtual IPs are recommended for each SOA and OIM managed server. This enables these servers to participate in server migration.

For more about virtual hostnames, see the IDM EDG for FA.

Certificate Creation

Customers should try to create any certificates needed for any of the SSL connections made to already existing infrastructure like the load balancer and should make arangments to generate certificates for any infrastructure that will be installed during the build out (like OHS or OID) where a “legitimate” certificate is desired.
In particular, it is advisable that the front end certificates being used for the browser to load balancer or browser to web server connections be “legitimate” certificates where the hostname in the certificate is correct and where the CA of the server cert is or can be imported into the trust store on browsers that will be using the environment.

Beyond the front end SSL connection, all other connections can function OK with self signed certificates produced in the install. It is up to each customer to decide as to whether or not this is sufficient.

Planning an IDM Build Out for Fusion Apps Part 1 – Discussion Topics

Today I am kicking of a series of posts on planning an Oracle IDM build out for Fusion Apps. I will start by discussing a bunch of topics that should be discussed and worked through before you move forward with an IDM build out for FA.

I will then continue the series with a pre-install checklist and discussion of supporting characters that will need to participate in the install.

So, with that in mind I’ll dive right in to the topics for discussion:

Network Considerations: Virtual Hostnames and IPs

Virtual host and VIP information should be reviewed before the onsite install beings so that the network can be prepared in advance.

The information on the IDM network requirements for FA can be found here.

The following virtual hostnames should be deployed to the load balancer handling front-end HTTP and HTTPS traffic to the IDM services or to the web server (OHS) handling front end traffic if no load balancer will be used: – Host for administering OIM environment (OAM, OIM, WLS, EM, ODSM)

• This virtual server is enabled on LBR1. It acts as the access point for all internal HTTP traffic that gets directed to the administration services. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address and in turn forward these to ports 7777 on WEBHOST1 and WEBHOST2. The services accessed on this virtual host include the WebLogic Administration Server Console, Oracle Enterprise Manager Fusion Middleware Control, and Oracle Directory Services Manager.
• Create rules in the firewall to block outside traffic from accessing the /console and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the virtual host. – Host for callbacks between OIM and FA.

• This virtual server is enabled on LBR1. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address and in turn forward these to ports 7777 on WEBHOST1 and WEBHOST2. The SOA Managed servers access this virtual host to callback Oracle Identity Manager web services
• Create rules in the firewall to block outside traffic from accessing this virtual host. Only traffic inside the DMZ should be able to access these URLs on the virtual host. – Front end host for OAM (logins) and OIM (user self service)

• This virtual server is enabled on LBR1. It acts as the access point for all HTTP traffic that gets directed to the single sign on services. The incoming traffic from clients is SSL enabled. Thus, the clients access this service using the address and in turn forward these to ports 7777 on WEBHOST1 and WEBHOST2. All the single sign on enabled protected resources are accessed on this virtual host.

• Configure this virtual server in the load balancer with both port 80 and port 443.
• This virtual host must be configured to preserve the client IP address for a request. In some load balancers, you configure this by enabling the load balancer to insert the original client IP address of a request in an X-Forwarded-For HTTP header.

The following virtual hostnames should be deployed for the load balancer fronting your LDAP directories or the LDAP directories themselves if no load balancer will be used.

• This virtual server is enabled on LBR2. It acts as the access point for all policy-based LDAP traffic, which is stored in the Oracle Internet Directory servers in the directory tier. Traffic to both the SSL and non-SSL is configured. The clients access this service using the address for SSL and for non-SSL.

Note:  Oracle recommends that you configure the same port for SSL connections on the LDAP server and Oracle Internet Directory on the computers on which Oracle Internet Directory is installed.

This is a requirement for most Oracle 10g products that use Oracle Internet Directory through the load balancing router.

• Monitor the heartbeat of the Oracle Internet Directory processes on OIDHOST1 and OIDHOST2. If an Oracle Internet Directory process stops on OIDHOST1 or OIDHOST2, or if either host OIDHOST1 or OIDHOST2 is down, the load balancer must continue to route the LDAP traffic to the surviving computer.

• This virtual server is enabled on LBR2. It acts as the access point for all Identity Store LDAP traffic. Traffic to both the SSL and non-SSL is configured. The clients access this service using the address for SSL and for non-SSL.

• If your identity store is accessed through Oracle Virtual Directory, monitor the heartbeat of the Oracle Virtual Directory processes on OVDHOST1 and OVDHOST2. If an Oracle Virtual Directory process stops on OVDHOST1 or OVDHOST2, or if either host OVDHOST1 or OVDHOST2 is down, the load balancer must continue to route the LDAP traffic to the surviving computer.

• If your identity store is in Oracle Internet Directory and is accessed directly, monitor the heartbeat of the Oracle Internet Directory processes on the Oracle Internet Directory Hosts. If an Oracle Internet Directory process stops on one OIDHOST or one OIDHOST is down, the load balancer must continue to route the LDAP traffic to the surviving computer.


The following questions related to SSL in the IDM environment build out. Note that this does not address non-IDM FA related SSL questions.

1) Will SSL be used for logins to FA? (Recommended)

2) Will OIM access to be over SSL?

3) Will admin console, OAM console, and EM access to be over SSL?

4) If there will be a load balancer, will you be terminating SSL at the load balancer or at the web server? (EDG recommendation is at the LBR) If at the web server, will they be providing your own certs or do you they want to create test, self signed certs?

5) Will web server to app server communication to be over SSL for the IDM related services? (EDG recommendation is no)

6) Will LDAP traffic for logins and/or identity management operations to be over SSL (EDG recommendation is no). If yes, will a “real enterprise” certificate or self signed certificate be used.

7) Does the customer want WebGate traffic to be over SSL? If yes, do they want to provide your own cert or use “simple mode”.

Note: If possible, create certificates for the appropriate components (LBR, OHS, OAM – WebGate communication, LDAP) where it has been decided that SSL is needed before the onsite install begins.

Load Balancer Usage

1) Will the IDM environment be using a load balancer for front end HTTP traffic to the IDM environment? If yes, then they will need to provision the appropriate virtual hostnames, routing rules, and certificates on the load balancer.

2) Will the IDM environment be using a load balancer for LDAP traffic? If yes, then they will need to configure the appropriate virtual hostnames, routing rules, and certificates (optionally) on the load balancer.

Topology/ Nodes
I recommend creating tables that provide a mapping of the logical hosts laid out in the IDM EDG for FA installation guide and the physical hosts that the customer will deploy the IDM components on. The logical nodes laid out in the EDG can be combined into fewer physical nodes. Indeed it is possible to install all the IDM components on one physical node. I discuss this in detail in my last post on simplification and host consolidation in the IDM build out for FA.

Directory (File System) Structure

Will the install be done on a shared file system or will everything be installed locally?

The recommendation for a full HA install is that the web tier be installed locally, the instances be local, the main IDM FMW home be shared, and there is some debate about shared/local for the domain, it might be good to just follow the EDG and go local.

The IDM FA build out includes 2-3 databases. 1-2 databases are required for OID, if the environment is going to have separate OID instances for the policy and identity stores then 2 will be required. If the environment is going to combine policy and identity stores then just 1 database for OID is required.

A second database is required as a store for all other IAM related products (OIM, OAM, OIF, etc).

You can run multiple database instances on a single physical server or RAC to satisfy this requirement but it is highly recommended that you not utilize a single database instance for both OID and other IAM products.

The FA IDM build out requires the running of the RCU utility to create schemas for each IDM product being installed.

To do: Make sure the following is done before the onsite IDM build out commences.

1. Have database infrastructure, through the creation of the required instances, ready before arriving onsite for the FA IDM build out.

2. ALT32UTF8 is the Database Character Set requirement

3. Have DBA prepared to run RCU. Some customers want detailed descriptions of what the RCUs and our installs will be laying down. Other customers won’t ask or care. Be sure to offer up this information up front and make sure everyone is comfortable and ready to build out the database tiers. It is a good idea to have customer run the RCU on their own or with remote assistance before arriving onsite. That way if there are issues with the customer DB configuration they can be addressed ahead of time.

4. Be sure that connection URLs, instance names, passwords, and schema passwords are available throughout the install.

5. Customer should have a clearly defined and tested backup strategy for the DB that they can use throughout the IDM build out process and subsequent FA install.

Identity Store
Fusion Applications requires an LDAP directory as an identity store where users will be authenticated out of and where certain FA specific attributes related to the user will be stored. OID is part of the standard IDM build out for FA and serves as the main identity store for FA where FA related user attributes and roles are stored.

However, a “split identity store” solution is possible where the IDM build out can be configured to authenticate users out of a separate corporate store consisting of an OID, DSEE, or AD directory.

Discuss what store(s) will be used in the install that is being planned. Discuss this both in terms of the initial install and the end state for the project. It is possible to migrate from using OID to a split ID store solution down the road.

Also discuss whether the initial install will include a bulk upload of users from another source to the identity store.

Will your customer want to achieve federation single sign-on to or from the FA environment? If so, then they will need to deploy OIF as part of the IDM build out. If not, then they can skip OIF. Note, that Federation is a viable option to achieve SSO between FA and the rest of the enterprise where the rest of the enterprise is using an SSO solution other than OAM (or more specifically the OAM being used by FA).


Hostname References and Architecture Simplification in the IDM Build Out for Fusion Apps

In my last post, I discussed the reference architecture for the Identity and Access Management build out of Fusion Apps.
The reference architecture is pretty complex in that it is completely HA, separates all the IDM services into 3 tiers for maximum network security, and separate many of the services onto different physical nodes to account for load separation for high volume production environments.
There are reasons one might want to simplify this for development, QA, or even production environments.  Specifically, you may want to consolidate physical hosts, not do HA, or not use a load balancer for some traffic that does in the reference architecture.  
I will now discuss how to use the IDM EDG (Oracle Identity Management Enterprise Deployment Guide, Fusion Apps Edition) as a guide for your build out even if you want to deviate from the reference architecture in some way.  The key to this is understanding how the EDG makes hostname references and understanding how these references translate to the environment you are creating.

 There are two types of host references in the EDG.  The first type is a reference to the logical name for a physical host.  These are the labels for each node name in the reference diagram above: WEBHOST1, IDMHOST1, OIMHOST1, OIDHOST1 etc.  The EDG uses these hosts when they want you to perform some task.  So, it will say things like “Follow these steps to configure the Oracle Internet Directory components, OIDHOST1 and OIDHOST2 on the directory tier with Oracle Internet Directory”.

The other type of host reference are references to the virtual hostnames that define the hosts that requests are made to in the system and here I am referring to requests made by end users and component to component communication which includes the IDM components themselves and components from the Fusion Apps domain.  These virtual hosts are described in chapter 2 of the EDG.  These hosts include,, and  In the reference architecture, all these hosts will resolve to load balancers.  Throughout the EDG, these virtual hostnames are referred to when you need to specify a URL or hostname in a components configuration.  For example, when configuring OAM you specify IDSTORE_HOST: in the properties file that the IDM config tool will utilize to help configure OAM.
What I recommend to people doing IDM build outs for Fusion Apps is to maintain a table that translates the logical names for physical hosts and virtual hostname references in the EDG to the real physical host and virtual hostnames in the environment.
EDG Node Name
Physical Host
WLS Admin (not running), OAM, ODSM, EM
OIM, SOA Suite
OIM, SOA Suite
You’ll notice in the above example I’ve defined a mapping for the physical host references that deviates a little from the EDG reference architecture in that the IDMHOSTs are combined with the OIMHOSTs and the OIDHOSTs are combined with the OVDHOSTs.
Virtual Host
Maps To
Likewise, you’ll notice that the above example of a virtual hostname mapping reflects that I’m using a single LDAP directory for both the policy store and identity store.
How to Simplify
So if you want to deviate from the EDG by consolidating physical hosts, simply create a mapping where the hosts you want to consolidate resolve to the same physical host.
If you want to not implement an HA environment or implement partial HA then just eliminate the 2nd host for each logical host in your table (WEBHOST2, IDMHOST2 etc.).
If you don’t want to use a load balancer for LDAP communication then have and resolve directly to the host of your LDAP directory (be it OID or OVD).
If you don’t want to user a load balancer for your HTTP traffic then have the sso, admin, and oiminternal hosts resolve directly to your OHS server.
For consolidation you can then just follow the instruction in the EDG using your map to guide you in making sure that you are really executing each step on the right host and entering the right host in the URL and hostname references that come up during the build out.
If you are skipping HA for some or all of the build out then you also have to skip the steps related to the build out of 2nd hosts but that is fairly self evident.

Identity Management for Fusion Applications Reference Architecture

As I’ve talked about in my last couple posts (here and here), Fusion Apps relies on an Oracle Identity and Access Management platform which must be created through a prescribed build out of Oracle’s IAM stack. The guide for the build out is the Enterprise Deployment Guide for Identity Management (Fusion Apps Edition), which we will refer to now simply as the ‘EDG’ for short.

The first chapter of the EDG includes a good diagram and description of Oracle’s reference architecture for the IAM platform for Fusion Apps. The rest of the EDG walks you through building out an IDM environment that fits this reference architecture.

In this post I’ll give a guided tour of this reference architecture and at the end discuss how you can still use the EDG to build out a simplified environment if that is the route that you want to take.

IDM Reference Architecture for FA Overview
Above you see the IDM reference architecture for FA (without the inclusion of OIF).  The IDM reference architecture for FA includes 12 hosts spread across 3 tiers where each tier is in a separate firewall zone.

From bottom to top we have:

1)  The directory or data tier consisting of the directory (OID), virtual directory (OVD) and databases supporting the whole IDM environment.

2)  The application tier consisting of all the services (OAM, OIM, ODSM, SOA) that run in WebLogic Server.

3)  The web tier consisting of the web server (OHS) and HTTP load balancer.

The reference architecture is fully highly available. For the databases, this is accomplished through use of RAC. For everything else, it is accomplished by having 2 nodes with redundant services and utilizing load balancing in some form or another for all communication. If you are no planning on building an HA environment or if you just want a simplified view of things, you can almost cut the above diagram in half and only consider one side.

The reference architecture is pretty complex in that it is completely HA, separates all the IDM services into 3 tiers for maximum network security, and separate many of the services onto different physical nodes to account for load separation for high volume production environments.

There are reasons one might want to simplify this for development, QA, or even production environments. Specifically, you may want to consolidate physical hosts, not do HA, or not use a load balancer for some traffic that does in the reference architecture.

These simplifications can all be done and I’ll discuss this in more detail in my next post. For now, just know that you can build a functional IDM environment for Fusion Apps without FA and on far less hosts than the reference architecture. In fact, the IDM environment can be consolidated all the way down to 2 hosts, 1 for the DBs and 1 for everything else.

A Walk through the Logical Hosts

Now that we are through the overview, let me walk you through what is contained in each of the twelve hosts present in the reference architecture. Going again from bottom to top…

There are two databases in the data tier. The OID RAC DB is the repository for OID and the other DB is the repository for everything else. The EDG shows these as separate databases. They can in fact be on the same physical host and be part of the same database install (ORACLE _HOME) but they should be separate instances. The DBs are specified as RAC but RAC is not required for non-HA environments.

Moving up from the DB in the directory/data tier we have the OIDHOST1, OIDHOST2, OVDHOST1, and OVDHOST2. These hosts contain the instances of OID and OVD respectively. Note, that this does not include ODSM, WLS, EM or other components that come when you do a basic install of OID and/or OVD on a single node. I’ll also mention that combining the OID and OVD hosts is a good way to consolidate nodes (while preserving the tiers) if you are looking to do that.

Moving up into the application tier we have IDMHOST1 and IDMHOST2. The IDMHOST is probably the most central host in the reference architecture. It is the “master node” for the WebLogic domain that will be the central part of the IDM environment. IDMHOST1 contains the following applications all running on WebLogic: WLS admin server, Enterprise Manager, OAM admin server, OAM managed server, and ODSM (the admin app for OID and OVD). IDMHOST2 contains the OAM managed server and ODSM and inactive instances of the WLS admin server, enterprise manager and the OAM admin server.

The reason that the WLS admin server, OAM admin server, and EM are inactive on IDMHOST2 is because you can only have one WLS admin server running in a domain at 1 time and all these apps run in the WLS admin server. In fact, the admin server for a domain is configured to bind to a single specific IP address and so if you want to be able to run it at all on IDMHOST2, you have to configure a virtual IP address (VIP) that can float between IDMHOST1 and IDMHOST2 for the admin server to bind to.

The other hosts in the application tier are OIMHOST1 and OIMHOST2 which host the managed servers for OIM and the OIM specific deployment of SOA suite. OIMHOST can be consolidated with IDMHOST if you are looking to do node/host consolidation. The thing to keep in mind is that OIM can chew up a lot (all) of a system’s resources when it does bulk operations like reconciliations. If you have a small number of users and/or aren’t using OIM as your enterprise identity management / provisioning solution then this probably isn’t too much of an issue. However, one should definitely keep this and mind and tread carefully when running OIM on the same box as other critical services.

Finally in the web tier we have an HTTP load balancer, WEBHOST1 and WEBHOST2 which contains the web servers (OHS). The OAM webgate is installed and enabled on both OHS servers. This is an important point to understand. OAM is used to protect the web interfaces in the IDM environment and all HTTP traffic into the IDM environment comes through the OHS servers in the web tier. There is no direct access to any of the services.

Lastly, I’ll point out that the naming conventions here are somewhat confusing. For instance, IDMHOST does not contain OIM. Rather it is the “master” host for the IDM domain and contains the admin server along with OAM and ODSM. Keep this in mind as you go through your build out as I’ve seen many people get understandably confused by this and attempt to execute steps on the wrong box during the build out.

Communication Links
Now let’s consider request flow and the communication links in the reference architecture. This time we’ll go from top to bottom.
HTTP requests (be they from users or web services) come into the system and hit the load balancer where they are dispatched to OHS running on one of the WEBHOSTs.

OHS sends the requests along to one of the WLS servers in the app tier on IDMHOST or OIMHOST. Here load balancing is done by the WLS plug-in for OHS (mod_wl_ohs). This plug-in is cluster aware and will perform session sticky load balancing without the need for any external load balancer.

When one of the services in the app tier needs to talk to the identity store and policy store, it will talk to OVD on OVDHOST and OID on OIDHOST (depending on specific configuration) over well… the LDAP protocol. More accurately, the services will talk to a load balancer that may or may not be the same as the load balancer used for the HTTP traffic. My point being that a load balancer is required here to load balance the LDAP traffic.

LDAP traffic will also come into the system from Fusion Apps itself which will query both the identity store and policy store. Requests to the policy store will come through the load balancer and be dispatched directly to OID. Requests to the identity store will come through the load balancer and be dispatched to either OID or OVD, again depending on the configuration.

In the reference architecture, SSL is terminated at the load balancer and it is assumed that network security will ensure integrity and confidentiality of traffic behind the load balancer.
That being said, SSL is supported at every communication link in the IDM environment for Fusion Apps.
You can configure OHS with SSL and put the load balancer in pass through mode so that the entire browser to OHS connection is over SSL.
You can configure WLS and mod_wl_ohs so that the OHS to WLS connections are over SSL.
Lastly, you can configure the directories and individual product configurations so that the connections to OID and OVD occur over SSL (LDAPS).

In my next post I’ll talk about the hostname references in the IDM EDG which is a cause of confusion for many people. I’ll also cover models for simplifying the IDM environment for Fusin Apps from the reference architecture and still use the EDG as your guide for the build out.

A Further Introduction to Oracle IDM and Fusion Apps

Last week I gave an introduction into the Fusion Middleware Security in Fusion Applications.  This week I’d like to expand on that introduction to talk specifically, but still at a high level, about how the the Oracle IDM products fit in Fusion Apps.  To review, here I’m talking specifically about OID, OVD, OAM, OIM, and optionally OIF.

Active Participants
If you are going to take anything away from what I have written or will write about Fusion Apps and IDM let it be this: Do not ignore the Identity and Access Management components of Fusion Applications or take them for granted.

Even more than the other FMW components in Fusion Apps, the IDM components are not black boxes. They are independent products that must be actively managed.

Independently Installed
This starts at the very beginning with the fact that unlike the other FMW components, the IDM components of Fusion Apps is installed separately from the actual Fusion Apps kit. In fact, what I like to call the IDM environment for Fusion Apps is a pre-requisite to the Fusion Apps install itself which in turn asks approximately 100,000 questions about the IDM environment that it will be leveraging. This IDM environment includes its own database and web tiers which are distinct from the Fusion Apps database and web tiers.

This process is really just a specific build out of the Oracle IDM Suite, very similar to what an Oracle IDM Suite customer might do for a traditional enterprise deployment.

So, to successfully deploy Fusion Apps, you must be able to successfully deploy the Oracle IDM suite.

Mission Critical
The IDM components of Fusion Applications are mission critical. If OVD, OID, or OAM aren’t working properly (or God forbid, aren’t working at all) then neither is Fusion Apps. It is that simple.

So, if you want a high available deployment of Fusion Apps, you better make OVD, OID, OAM, and OIM highly available.

If you want to be able to restore a backup of your Fusion Apps environment, you better know how to back the IDM components.

If you want to be able to monitor the health status of your Fusion Apps deployment, you better include the IDM components in that monitoring.

Smart people involved in the deployment and/or management of Fusion Apps will recognize this and give proper attention to deploying and tuning the IDM environment for Fusion Apps in a way that is consistent with the requirements for the total FA deployment.

Skill Sets You’ll Want to Have
During a Fusion Apps deployment and the build out of the IDM environment that is a part of that deployment you’ll want to be able to:

  • Understand the deployment options described in the IDM Enterprise Deployment Guide (Fusion Apps Edition).
  • Be able to use that guide to architect an appropriate IDM build out for your specific Fusion Apps requirements.
  • Be able to install OID, OVD, OAM, OIM, and optionally OIF; along with the related pre-requisite and auxiliary packages such as SOA suite, WLS, and OHS.
  • Be able to tune all the above components.
  • Be able to do basic configuration of each of the listed components. The specifics of what this means varies from component to component and even deployment to deployment.

On an ongoing basis you’ll want to be able to:

  • Enable and analyze debug logging for each component.
  • Monitor each component using Enterprise Manager (EM) or integrate the component with an existing monitoring framework in your enterprise.
  • Be able to take backups of the IDM environment.
  • Be able to start and stop each component.
  • Be able to patch each component.
  • Finally, you’ll still want to have basic configuration and administration knowledge for each component around for expected and unexpected changes and maintenance.

While being able to author complex OAM policies, write custom OVD adaptors, or create complex SOA composites for custom OIM approvals isn’t necessary for most if not all Fusion Apps projects; a foundational proficiency with the Oracle IDM stack where one can install, manage, and monitor each IDM product is required for a successful and stable deployment of Fusion Apps.

In the coming weeks I plan to write more about how to plan for, execute, and verify a successful IDM build out for Fusion Apps.

Fusion Security – Apps Edition

When we first started this blog more than 2 years ago, we debated about whether to name it “Fusion Security” or more specifically “Fusion Middleware Security”. We all work in the Fusion Middleware team on Fusion Middleware but even back then we saw Fusion Applications coming down the pipe and after all Fusion Apps is a set of big business applications whose principal distinction (in my opinion) is that it is the first set of business applications to be built on a truly modern middleware platform.

The much anticipated Fusion Applications was recently released. For those of you unfamiliar with Fusion Apps, it is composed of several families of applications (CRM, Financials, HR, Supply Chain, Procurement etc) that comprise the next generation version of Oracles Apps portfolio (PeopleSoft, E-Business Suite, Siebel etc.) and as I said it is built on top of most of the Fusion Middleware products that currently exist today.

Welcome Apps Community

I will start off by welcoming those in the Oracle Apps community to the Fusion Middleware community and specifically the FMW security community. The middleware products may seem complicated, even overwhelming at first, but they are good powerful products that you can build your business upon.

Why You Should Care

What does this mean for those of us in the Fusion Middleware Security community? Why should we care?

For one Fusion Apps has been driving much of the direction of Fusion Middelware for some time and now is your opportunity to see what it is all about and how the Middleware you know and love is used. In this post I’ll provide an overview of this usage and follow up with much more detail in the coming months.

Secondly, I think our community is about to get much larger. Every Fusion Apps customer will become a Fusion Middleware Security Customer. So, I’ll also take the opportunity now to say welcome to all the new Fusion Apps architects, developers, and administrators out there that may happen across this post.

Thirdly, Fusion Applications is a very large and complex set of applications. Oracle has created an Enterprise Deployment Guide specifically discussing how the Identity Management products that Fusion Apps utilizes should be deployed. It is worth reading this just to get an idea for what Oracle considers as reference architecture for an IAM environment that supports large business applications.  You can find the Enterprise Deployment Guide for Oracle Identity Management (Fusion Apps Edition) here.

I myself have been very involved in the initial rollout of Fusion Applications and will continue to be very much involved along with other members of this blog in helping to advise customers on the security technology involved in Fusion Apps deployments.

What This Doesn’t Mean

With all that being said, while I do think the release of Fusion Applications is exciting and important to those of us in the Fusion Middelware Security community, I have heard some messaging around Fusion Applications and its impact on Fusion Middleware that I think oversells the importance of Fusion Apps and is ultimately incorrect.

I’ve heard it said many times that customers should closely align their use of our Fusion Middleware products to how they are used in Fusion Applications. While I agree that customers should be mindful of how FMW is used in Fusion Apps, I simply don’t agree with that statement.

Fusion Applications is a set of specific applications, namely business applications, which use our Fusion Middleware Security stack in a specific set of ways. They do not make use of every feature or even every product in our FMW Security stack. Our Fusion Middleware customers use our middleware products in a wide variety of ways, to create and support a wide variety of applications, with a wide array of business requirements, in a large variety of environments. Some of the differences between what our customers are trying to achieve with Fusion Middleware vs. what we achieved with Fusion Middlware in Fusion Apps means that customers can and should take different approaches from what was taken with Fusion Applications.

What FMW Security Is In Fusion Apps

Now that my rant is out of the way, I’ll proceed to talk about how Fusion Middleware Security is used in Fusion Applications on a product by product basis. Again, for a more detailed discussion at this time see the Enterprise Deployment Guide for IDM (FA Edition).

  • Oracle Internet Directory (OID) serves as the store for OPSS security policies and as the default store for Fusion Apps users.
  • Oracle Virtual Directory (OVD) serves as a go-between layer for user stores when OID is not being used (and optionally when OID is being used. It is also always used in conjunction with OIM for a feature called LDAP sync which provides real time synchronization of users between OIM and an LDAP directory.
  • Oracle Access Manager (OAM) provides authentication and singles sign-on (SSO) for Fusion Apps. It is worth noting that OAM runs in a special mode in Fusion Apps build outs and does not by default provide authorization, even course grained, for Fusion Apps. This means that some careful consideration will have to be done by customers wanting to use a single OAM deployment for Fusion Apps and other applications in their environment.
  • Oracle Identity Manager (OIM) helps provision users to the FA environment and provides delegated management and self service user management services to the Fusion Apps environment.
  • Oracle Platform Security Services (OPSS) provides the fine grained authorization for the application in Fusion Apps as well as an assortment of other functions such as LDAP connectivity and key management.
  • Oracle Web Services Security Manager (OWSM) provides web services security (WS-SEC) for both FA internal web services communication and the external web services interfaces to FA.
  • WebLogic Server serves as the core container for Fusion Apps and so WLS security is part of the picture. Specifically, identity asserters and authenticators (SSPI providers) are configured in FA. Other WLS security areas such as transport (SSL) security and node manager security also come into play.
  • Oracle HTTP Server (OHS) serves as the web tier for Fusion Apps. There are actually two web tiers in a Fusion Apps deployment. The first web tier is the front end to the IDM environment and the 2nd is the front end to the Fusion Apps themselves. Both web tiers will have OAM webgates on them. Beyond that SSL is the main security consideration you will have to configure / manage.
  • SOA Suite – SOA Suite is widely used throughout Fusion Apps including (as most of you know) its use as the workflow engine for OIM. There is a good deal of security in SOA Suite to manage including transport and message level security.

More on Oracle Secure Token Services (OSTS)

Last week Andre made an excellent post introducing the Oracle Secure Token Services (OSTS) product.I wanted to follow this up by letting everyone know about a good case study on the OSTS written by Oracle’s partner the PathMaker Group.  The study …