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.

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:

Network

1. Provisioning of virtual hosts and VIPs.

2. Configuration of load balancers.

DB

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.

Configuring Design Console for OIM 11g

In OIM 11g, Design Console still is a required tool for system configuration, custom development and customization. But differently from OIM 9.x, Design Console 11g does not have its own installer anymore. It is installed and configured along with the OIM server installation.

One of the common questions around Design Console 11g is: if there is no installer anymore, how do I get it working on my desktop/laptop without installing the whole Identity and Access Management pack?

This is an easy task and this post describes the steps for getting it done:

1. If you don't have a JDK 1.6 in your laptop, you will have to install it.

2. Run the configuration script for OIM once again. The script is available at $IAM_HOME/bin (where IAM_HOME is the folder where the ‘Identity and Access Management Pack’ was installed). You have to run the ‘config.sh’ that is available at $IAM_HOME/bin folder and NOT the one available at ‘$IAM_HOME/common/bin/config.sh’

3. In the configuration wizard, select ‘Design Console’ checkbox ONLY.

4. In the next screen, enter the OIM server host and port name. The wizard will configure the Design Console files for you

WebLogic Domain Models for Installing the Oracle Identity Management Suite – Part 2

A couple days ago I wrote what I consider to be an important post about whether different Oracle middleware packages (or bundles) should be installed together in a single domain or installed in separate domains.

I’ve received a few questions asking a logical extension of that topic which is what about the individual products within one package? Should individual products within one package be installed together in a single domain (which is really the default behavior) or be spread across several domains? For example, if you are deploying the Identity Management package with OID,OVD, and OIF, should you install them all in one domain or maybe put OIF in one domain and OID in a separate domain?

There are a number of things to consider in answering this question.

Let’s begin by looking at the issues that led me to recommend that you not install multiple packages/bundles in a single domain.

The first issue was the risk of incompatibilities between the packages and the difficulty in dealing with such issues when they arise. I would have to say that this issue does not apply to multiple products within one package. After all, the package was explicitly developed and tested with the idea that all the products would be running in same domain.

The second issue I raised was the notion that deploying multiple packages to one domain could complicate patching and upgrading; even potentially leading to a situation where you will be kept from upgrading due to version incompatibilities. Again, since we are now talking about products within one package, there is less of a concern about patching and upgrades. However, since even a single product patch could include components that are common across the entire package, having all the products from a package in a single domain means that you should really test every product that you use in the domain before deploying the patch to production. I don’t see this as being a huge deal but it is something to consider.

The next consideration which I did not address in my last post is delegation of duty or purpose for a domain. Some customers segregate certain WLS domains for certain purposes. Often this is seen as a security practice such as the case where a customer deploys all intranet apps to one domain , extranet apps to a second domain, and utility services to a third domain. If you are a customer that does this you may see some products in a package as falling in a different category from another. One example of this is that many customers will see OID and OVD as being “internal” or “utility” applications where as they might see OIF as being an “external “– end user facing application. This might lead them to deploy these applications from the Identity Management package into separate domains.

The last consideration is to note that some of the integrations between products in a package only work if the products are installed in the same domain. Two examples of this are the OAM/OIM integration and the native integration between OAM and OAAM. If you want to use the integrated functionality offered by these packages, you have to deploy them in the same WLS domain.

Important Topic: WebLogic Domain Models for installing the Oracle Identity Management Suite

As most of you know, the current 11g version of the Oracle Identity Management Suite runs on top of a tech stack based on WebLogic Server. In essence, when you install any package from the 11g Identity Management Suite, you end up deploying the applications from the package into a WLS domain.

There are 2 basic models of domain architecture for the Oracle IAM suite:

1) Install a given package into a new, self contained, WLS domain.

2) Extend an existing domain. In other words, deploy the apps from the Identity Management package you are installing into a domain that is also running other software. This model includes several variations based on what else you are running in the domain. One variation is installing the different Identity Management suite packages (namely the Identity Management package containing OID, OVD, and OIF; and the Identity and Access Management package containing OAM, OIM, and OAAM) into one domain. Another variation would be installing one of the Identity Management Suite packages into a domain running another Oracle product such as WebCenter or SOA Suite. Finally, one might even consider installing an Identity Management Suite package into a domain running custom application code.

Basic coverage of the topic can be found in the documentation here: http://download.oracle.com/docs/cd/E14571_01/install.1111/e12002/extend.htm

My Advice

It might seem like one or more of the scenarios listed above in the “extend an existing domain model “option above would make life simpler. In particular, I think that many people who use the entire Oracle Identity Management suite might be tempted to create a single monolithic “IAM domain” containing both major packages such that (OID,OVD,OIF,OAM,OAAM, and OIM) would all run in the same domain.

However, I’m here to tell you that running multiple packages in one domain is most likely a bad way to go. The reason is that it introduces the risk that different components (libraries, jars, utilities) from the different packages that you are installing in the domain might be incompatible and cause problems across your entire domain.

I actually had this happen when I accidently installed the IAM package (OAM) into a domain that was only running the PS1 version (instead of the PS2 version) of the IM package (OID and OVD). The IAM package is only certified to run in the same domain as the PS2 version of the IM package and sure enough many things in the domain broke.

To make matters worse, there is little you can do outside of restoring a previous full OS backup to fix the situation if such an incompatibility occurs.

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. Let’s say a new patch set of the Identity Management package (OID and OVD) comes out. If you have installed the package into its own domain then you are good to go. However, if you have installed it into a domain with WebCenter or OAM/OIM then you must consider whether the patch set will be compatible with those other packages. So, you’ll have to open a support case to ask and if the answer is no then you might have to wait months for those other packages to catch up.

One 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.

Conclusion

While installing multiple Identity Management packages (or Fusion Middleware packages in general) into one domain might seem like a good idea as it gives you just less domains to manage, it is safer and better to install each Identity Management package into a separate, isolated domain.

To be clear, I am recommending that customers install the IAM package (OAM,OIM,OAAM) into a separate domain from the IDM package (OID,OVD,OIF).  I am not necessarily recommending that you install the various products inside of each package in separate domains.  If and when to do that is a topic for another discussion which I will try and post about soon.

Tell what patches are installed in your Oracle IAM 11g deployments using OPatch

People often want to know how they can tell what versions (including patches) of software they are running in their different environments. Fortunately, there is a simple standard way to get this information for all software that uses the Oracle Universal Installer. The method I speak of uses the OPatch utility that is standard for all Oracle products that use the universal installer. This includes most, if not all of Fusion Middleware 11g and all of the 11g Identity Management packages.


OPatch is the utility used to patch Oracle products that utilize the Oracle Universal Installer. It is included in most product/package installs under that package’s ORACLE_HOME/OPatch.

Now, keep in mind that when you execute OPatch it will operate on the ORACLE_HOME that is set in the environment. So, if you are operating in an environment where you have multiple products/packages installed under one Fusion Middleware Home (FMW_HOME) you want to make sure that you have an ORACLE_HOME environment variable pointed to the product/package you are interested in patching or analyzing.

To get information on the version and patch levels of your Oracle product/packages run ‘opatch lsinventory’. Again, make sure that ORACLE_HOME is set to the product/package that you want the information for. If it is not set, then OPatch picks some default ORACLE_HOME from your FMW_HOME in a manor I have yet to figure out.

You can also use OPatch to tell you all the ORACLE_HOMEs that exist under your FMW_HOME by running ‘opatch lsinventory -all’.

The documentation for OPatch can be found in the Oracle Universal Installer and OPatch User Guide