Secure Access to Oracle Identity Manager 11g R2 PS3 REST APIs

REST APIs for Oracle Identity Manager (OIM) 11g R2 PS3 were released recently. The availability of REST APIs enables a variety of newer integrations with the product in addition to already available mechanisms using Java APIs. In this article, we discuss various ways of accessing these REST APIs in a secure manner. Please note that […]

Loading Identity Data Into Oracle Identity Cloud Services: A Broad High-level Survey

Introduction Oracle Identity Cloud Services (IDCS) – Oracle’s comprehensive Identity and Access Management platform for the cloud – was released recently. Populating identity data – such as user identities, groups and group memberships – is one of most important tasks that is typically needed initially and on an on-going basis in any identity management system. […]

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 users and their emails after FA-P2T in On-Prem Environments

Introduction The P2T – Prodution to Test – procedure is a very popular feature that FA customers utilize. It allows them to have their production data copied to another environment. Nowadays, P2T is a very common cloud SAAS and on-premise procedure. An important aspect that is not discussed frequently is the post-process of P2T. This […]

Oracle IAM 11g R2 docs are now available

The docs for the OAM 11g R2 release are now up and available either online at http://docs.oracle.com/cd/E27559_01/index.htm or as a download on via eDelivery.To get your very own copy from eDelivery: go to http://edelivery.oracle.com/ Sign in Pick “Ora…

Scripts to ease building your Identity Management environment

One of my mottos is “why do something by hand if you can automate it in twice the time?” So a while back I put together a bunch of scripts to do just that. They’ve been handed around by a few people and Warren Strange eventually had the sensible idea …

Error message “Can not resolve hostname for interface any” from opmnctl

I ran into a problem with opmnctl on one of the many virtual machines and I know that someone else out there will have the same problem. This was a machine with the Identity Management bits (OID, OVD and OIF) that I had just patched up to 11.1.1.5. Whe…

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.