Cloud Security: Seamless Federated SSO for PaaS and Fusion-based SaaS

Introduction Oracle Fusion-based SaaS Cloud environments can be extended in many ways. While customization is the standard activity to setup a SaaS environment for your business needs, chances are that you want to extend your SaaS for more sophisticated use cases. In general this is not a problem and Oracle Cloud offers a great number […]

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. […]

What is SCIM?

SCIM is a standard protocol for accessing identity information (users, roles, etc), including querying, retrieval, create, update and delete. The latest version of SCIM, SCIM 2.0, has been defined in a series of RFCs: RFC 7642, RFC 7643 and RFC 7644. What does SCIM stand for? Originally it was an acronym for “Simplified Cloud Identity […]

Simplified Role Hierarchy in R10

Introduction Our teammate Jack Desai published an article last year about Fusion Application Roles Concept. It gives you a great overview about the design to grant access to certain functionalities to specific users. His article familiarizes you with the concepts of Abstract Roles, Duty Roles, Job Roles or Data Roles and how they are used in […]

Java Flight Recorder

Overview Performance issues are some of the most difficult and expensive issues to diagnose and fix.  For JAVA applications there is a great tool called the Java Flight Recorder (JFR) that can be used to both proactively to find potential performance issues during testing before they become apparent through external metrics and reactively to troubleshoot […]

Configuring your Oracle Database for Kerberos authentication

Introduction I have two goals with this post. To show how to setup Kerberos authentication for the Oracle Database and also demonstrate that the use/configuration of Kerberos is pretty straightforward. At least with the versions and OS I have used for this setup. The Kerberos functionality is provided by the Advanced Security Option of the […]

Mass Reset Password-part1 OID

Introduction One of the great features that customers need to be aware of and it could be used, as post-process, on many different situations such as: P2T, T2P and clone is the ability to reset multiple passwords simultaneously. Imagine the customer is scaling out their environment because they need an additional UAT environment. This customer […]

Disabling Change Password and Forgot Password functionality in FA-IDM

Introduction Oracle Fusion Applications (FA) uses Oracle Identity Management (IDM) capabilities to implement the “change password” and “forgot password” functions. These functions, in turn, are enabled using capabilities provided by Oracle Access Management (OAM) and Oracle Identity Management (OIM). Frequently, in development and test environments, for the sake of convenience, the change password and forgot […]

Configuration of Users/External Roles Relationship in OES 11G for a Database Identity Store

Introduction Recently I worked with a customer who wanted to use their existing database that is tied to other applications as the identity store for OES11G implementation. We all know that for OES 11G, the Identity Store must be an LDAP based directory. So to address this use case we took the help of  OVD.  […]

Long-lived TCP connections and Load Balancers

I’ve talked about the subject of long lived TCP connections and load balancers for years, explaining to people why they may not need or want to use a load balancer between two servers. Each time I explain it I remind myself that I should probably write it down so I can just point to the […]

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 11.1.1.3 only.  There is a separate article (1360009.1) for OIM 11.1.1.5.

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 11.1.1.5 IDM EDG

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

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

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

13031196 for OVD 11.1.1.5.  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 (11.1.1.5 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.

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.

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 …

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: http://idmost.mycompany.com:7777/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:

Groups
Members
cn=IDM Administrator
cn=weblogic_idm
cn=OAMAdministrators
cn=oamadmin
cn=OIMAdminstrators
cn=oimldap
cn=orclFAGroupReadPrivilegeGroup
cn=idrouser
cn=oamldap
cn=orclFAGroupWritePrivilegeGroup
cn=idrwuser
cn=orclFAOAMUserWritePrivilegeGroup
cn=oamldap
Cn=orclFAUserReadPrivilegeGroup
cn=idrouser
cn=oamldap
cn=orclFAUserWritePrefsPrivilegeGroup
cn=idrouser
cn=orclFAUserWritePrivilegeGroup
cn=idrwuser
cn=orclPolicyAndCredentialReadPrivilegeGroup
cn=policyrouser
cn=orclPolicyAndCredentialWritePrivilegeGroup
cn=policyrwuser
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 (sso.mycompany.com).  
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 (sso.mycompany.com).
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:

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:

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 11.1.1.5 but the web tier and IDM packages have to be installed at 11.1.1.2 and then upgraded to 11.1.1.5.

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:

http://www.oracle.com/technetwork/middleware/ias/downloads/101401-099957.html

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 support.oracle.com or through eDelivery.

Documentation

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: http://download.oracle.com/docs/cd/E15586_01/fusionapps.1111/e21032/db_repos.htm#BABHBICE

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.

admin.mycompany.com – Resolves to load balancer or web server fronting WLS admin server for the IDM domain running on IDMHOST1.

sso.mycompany.com – 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).

oiminternal.mycompany.com – Resolves to load balancer or web server fronting WLS admin server for the OIM managed servers running on OIMHOST1 (and OIMHOST2 if HA).

idstore.mycompany.com – Resolves to the load balancer fronting the LDAP identity store or the LDAP server itself.

policystore.mycompany.com – 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

admin.mycompany.com:80 –> webhost1.mycompany.com:7777 webhost2.mycompany.com:7777

sso.mycompany.com:80 –> webhost1.mycompany.com:7777 webhost2.mycompany.com:7777

oiminternal.mycompany.com:80 –> webhost1.mycompany.com:7777 webhost2.mycompany.com:7777

HTTPS (SSL terminating at load balancer)

admin.mycompany.com:443 –> webhost1.mycompany.com: 7777 webhost2.mycompany.com: 7777

sso.mycompany.com:443 –> webhost1.mycompany.com: 7777 webhost2.mycompany.com: 7777

oiminternal.mycompany.com:443 –> webhost1.mycompany.com: 7777 webhost2.myco.com: 7777

LDAP Load Balancer

policystore.mycompany.com:389 –> oidhost.mycompany.com:389 oidhost2.mycompany.com:389

idstore.mycompany.com:389 –> oidhost.mycompany.com:389 oidhost2.mycompany.com:389

LDAPS

policystore.mycompany.com:636 –> oidhost.mycompany.com:636 oidhost2.mycompany.com:636

idstore.mycompany.com:636 –> oidhost.mycompany.com:636 oidhost2.mycompany.com:636

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:

admin.mycompany.com – 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 admin.mycompany.com:80 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 admin.mycompany.com virtual host.

oiminternal.mycompany.com – 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 oiminternal.mycompany.com:80 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 oiminternal.mycompany.com virtual host.

sso.mycompany.com – 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 sso.mycompany.com:443 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.

policystore.mycompany.com

• 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 policystore.mycompany.com:636 for SSL and policystore.mycompany.com:389 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.

idstore.mycompany.com

• 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 idstore.mycompany.com:636 for SSL and idstore.mycompany.com:389 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.

SSL

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.

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

Federation
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 11.1.1.5 EDG.  These hosts include sso.mycompany.com, admin.mycompany.com, and idstore.mycompany.com.  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: idstore.mycompany.com 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
Components
Physical Host
WEBHOST
OHS
web-3231
WEBHOST 2
OHS
web-3232
IDMHOST
WLS Admin, OAM, ODSM, EM
app-7473
IDMHOST2
WLS Admin (not running), OAM, ODSM, EM
app-7474
OIMHOST
OIM, SOA Suite
app-7473
OIMHOST2
OIM, SOA Suite
app-7474
OIDHOST
OID
dir-1351
OIDHOST2
OID
dir-1352
OVDHOST
OVD
dir-1351
OVDHOST2
OVD
dir-1352
OIDDBHOST
DB
db-1
OIMDBHOST
DB
db-2
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.
 
And
 
 
Virtual Host
Maps To
sso.mycompany.com
sso.acme.com
oiminternal.mycompany.com
oiminternal.acme.com
admin.mycompany.com
Idm-fa-admin.acme.com
policystore.mycompany.com
ldap-lbr.acme.com
idstore.mycompany.com
ldap-lbr.acme.com
 
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 policystore.mycompany.com and idstore.mycompany.com 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.

SSL
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).
Teaser

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.