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