Split profile setup with AD and OID for Fusion Apps IDM

I have discussed split profile set up scenario for Fusion Applications IDM Environment with AD and OID , process of creation of Adapters needed in OVD for consolidating the two directory servers AD and OID and the configuration changes needed in OAM , OIM  and WLS of IDM Environment in these 2 Blog posts.

Part1 , Part 2

This process is relevant to FA Release RUP1 . From release RUP2 some of these manual steps have been automated, which i will discuss in a future blog.

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.

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.

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:

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:

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.

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.

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.

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