2 Prerequisites for Enterprise Deployments

This chapter describes the prerequisites for the Oracle Identity Management Infrastructure enterprise deployment topology.

This chapter includes the following topics:

• Section 2.1, "Hardware Resource Planning"

• Section 2.2, "Network Prerequisites"

• Section 2.3, "WebLogic Domain Considerations"

• Section 2.4, "Shared Storage and Recommended Directory Structure"

2.1 Hardware Resource Planning

The typical hardware requirements for the Enterprise Deployment on Linux operating systems are listed in Table 2-1. The memory figures represent the memory required to install and run an Oracle Fusion Middleware server; however, for most production sites, you should configure at least 4GB of physical memory.

For detailed requirements, or for requirements for other platforms, see the Oracle Fusion Middleware Installation Guide for that platform.

Table 2-1 Typical Hardware Requirements

Server	Processor	Disk	Memory	TMP Directory	Swap
INFRADBHOSTn	4 or more X Pentium 1.5 GHz or greater	nXm n=Number of disks, at least 4 (striped as one disk). m=Size of the disk (minimum of 30 GB)	6-16 GB	Default	Default
WEBHOSTn	2 or more X Pentium 1.5 GHz or greater	10 GB	4 GB	Default	Default
IDMHOSTn, OAMHOSTn	2 or more X Pentium 1.5 GHz or greater	10 GB	4 GB	Default	Default
OAMADMINHOST	2 or more X Pentium 1.5 GHz or greater	10 GB	4 GB	Default	Default
OIDHOSTn, OVDHOSTn	2 or more X Pentium 1.5 GHz or greater	10 GB	4 GB	Default	Default

These are the typical hardware requirements. For each tier, carefully consider the load, throughput, response time and other requirements to plan the actual capacity required. The number of nodes, CPUs, and memory required can vary for each tier based on the deployment profile.Production requirements may vary depending on applications and the number of users.

The Enterprise Deployment configurations described in this guide use two servers for each tier to provide failover capability; however, this does not presume adequate computing resources for any application or user population. If the system workload increases such that performance is degraded, you can add servers to the configuration by repeating the instructions for the second server (that is, WEBHOST2, IDMHOST2, OIDHOST2, OVDHOST2, INFRADBHOST2) to install and configure additional servers where needed.

2.2 Network Prerequisites

This section describes the network prerequisites for the enterprise deployment topology:

• Load balancers

• Configuring virtual server names and ports on the load balancer

• Administration Server Virtual IP

• Managing Oracle Fusion Middleware component connections

• Oracle Access Manager communication protocols and terminology

• Firewall and port configuration

2.2.1 Load Balancers

This enterprise topology uses an external load balancer. This external load balancer should have the following features:

• Ability to load-balance traffic to a pool of real servers through a virtual host name: Clients access services using the virtual host name (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.

• Port translation configuration

• Monitoring of ports (HTTP and HTTPS)

• Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:

  • The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for OracleAS Clusters, the load balancer needs to be configured with a virtual server and ports for HTTP and HTTPS traffic.

  • The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through the virtual server names.

• Ability to detect node failures and immediately stop routing traffic to the failed node.

• Resource monitoring / port monitoring / process failure detection: The load balancer must be able to detect service and node failures (through notification or some other means) and to stop directing non-Oracle Net traffic to the failed node. If your external load balancer has the ability to automatically detect failures, you should use it.

• Fault tolerant mode: It is highly recommended that you configure the load balancer to be in fault-tolerant mode.

• Other: It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the backend services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.

• Sticky routing capability: Ability to maintain sticky connections to components based on cookies or URL.

• SSL acceleration (this feature is recommended, but not required)

• Configure the virtual server(s) in the load balancer for the directory tier with a high value for the connection timeout for TCP connections. This value should be more than the maximum expected time over which no traffic is expected between the Oracle Access Manager and the directory tier.

2.2.2 Configuring Virtual Server Names and Ports on the Load Balancer

Four virtual servers and associated ports must be configured on the load balancer for different types of network traffic and monitoring. These should be configured to the appropriate real hosts and ports for the services running. Also, the load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This will ensure that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.

There are two load balancer devices in the recommended topology. One load balancer is set up for external HTTP traffic and the other load balancer is set up for internal LDAP traffic. A deployment may choose to have a single load balancer device due to a variety of reasons. While this is supported, the deployment should consider the security implications of doing this and if found appropriate, open up the relevant firewall ports to allow traffic across the various DMZs. It is worth noting that in either case, it is highly recommended to deploy a given load balancer device in fault tolerant mode. The rest of this document assumes that the deployment is the one shown in Figure 1-1.

oid.mycompany.com

• This virtual server is enabled on LBR2. It acts as the access point for all LDAP traffic to 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 oid.mycompany.com:636 for SSL and oid.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 need to use Oracle Internet Directory via 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.

ovd.mycompany.com

• This virtual server is enabled on LBR2. It acts as the access point for all LDAP traffic to the Oracle Virtual Directory servers in the directory tier. Traffic to both the SSL and non-SSL is configured. The clients access this service using the address ovd.mycompany.com:636 for SSL and ovd.mycompany.com:389 for non-SSL.

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

admin.mycompany.com

• 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 and Oracle Directory Services Manager.

sso.mycompany.com

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

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

• Configure this virtual server in the load balancer with both port 80 and port 443. Any request that goes to port 80 must be redirected to port 443 in the load balancer.

In addition, ensure that the virtual server names are associated with IP addresses and are part of your DNS. The computers on which Oracle Fusion Middleware is running must be able to resolve these virtual server names.

2.2.3 Administration Server Virtual IP

idmhost-vip.mycompany.com

A virtual IP should be provisioned in the application tier so that it can be bound to a network interface on any host in the application tier. The WebLogic Administration Server will be configured later to listen on this virtual IP address, as discussed later in this manual. The virtual IP address fails over along with the Administration Server from IDMHOST1 to IDMSHOST2, or vice versa.

2.2.4 Managing Oracle Fusion Middleware Component Connections

In order to ensure consistent availability of all services, ensure that the connection timeout values for all Oracle Fusion Middleware components are set to a lower timeout value than that on the firewall and load balancing router. If the firewall or load balancing router drops a connection without sending a TCP close notification message, then Oracle Fusion Middleware components will continue to try to use the connection when it is no longer available.

2.2.5 Oracle Access Manager Communication Protocol and Terminology

Oracle Access Manager components use proprietary protocols called Oracle Access Protocol (OAP) and Oracle Identity Protocol (OIP) to communicate with each other.

2.2.5.1 Oracle Access Manager Protocols

Oracle Access Protocol (OAP) enables communication between Access System components (for example, Policy Manager, Access Server, WebGate) during user authentication and authorization. This protocol was formerly known as NetPoint Access Protocol (NAP) or COREid Access Protocol.

Oracle Identity Protocol (OIP) governs communications between Identity System components (for example, Identity Server, WebPass) and a Web server. This protocol was formerly known as NetPoint Identity Protocol (NIP) or COREid Identity Protocol).

2.2.5.2 Overview of User Request

The request flow when a user requests access is described below:

1. The user requests access to a protected resource over HTTP or HTTPS.

2. The WebGate intercepts the request.

3. The WebGate forwards the request to the Access Server over Oracle Access Protocol to determine if the resource is protected, how, and whether the user is authenticated (if not, there is a challenge).

4. The Access Server checks the directory server for credentials such as a user ID and password, sends the information back to WebGate over Oracle Access Protocol, and generates an encrypted cookie to authenticate the user.

5. Following authentication, the WebGate prompts the Access Server over Oracle Access Protocol and the Access Server looks up the appropriate security policies, compares them to the user's identity, and determines the user's level of authorization.

   • If the access policy is valid, the user is allowed to access the desired content and/or applications.

   • If the policy is false, the user is denied access and redirected to another URL determined by the organization's administrator.

2.2.6 Firewall and Port Configuration

Many Oracle Fusion Middleware components and services use ports. As an administrator, you must know the port numbers used by these services, and to ensure that the same port number is not used by two services on a host.

Most port numbers are assigned during installation.

Table 2-2 lists the ports used in the Oracle Identity Management topology, including the ports that you need to open on the firewalls in the topology.

Firewall notation:

• FW0 refers to the outermost firewall.

• FW1 refers to the firewall between the web tier and the application tier.

• FW2 refers to the firewall between the application tier and the directory tier.

Table 2-2 Ports Used in the Oracle Identity Management Enterprise Deployment Topology

Type	Firewall	Port and Port Range	Protocol / Application	Inbound / Outbound	Timeout
Browser request	FW0	80	HTTP / Load balancer	Both	Timeout depends on all HTML content and the type of process model used for Oracle Identity Management.
Browser request	FW0	443	HTTPS / Load balancer	Both	Timeout depends on all HTML content and the type of process model used for Oracle Identity Management.
Oracle WebLogic Administration Server access from web tier	FW1	7001	HTTP / Oracle HTTP Server and Administration Server	Inbound	N/A
Enterprise Manager Agent - web tier to Enterprise Manager	FW1	5160	HTTP / Enterprise Manager Agent and Enterprise Manager	Both	N/A
Oracle HTTP Server to WLS_ODS	FW1	7006	HTTP / Oracle HTTP Server to WebLogic Server	Inbound	Timeout depends on the mod_weblogic parameters used.
Oracle Process Manager and Notification Server (OPMN) access in web tier	FW1	OPMN remote port	HTTP / Administration Server to OPMN	Outbound	N/A
Oracle HTTP Server proxy port	FW1	9999	HTTP / Administration Server to Oracle HTTP Server	Outbound	N/A
Access Server access	FW1	6021	OAP	Both	N/A
Oracle WebLogic Administration Server access from directory tier	FW2	7001	HTTP / Oracle Internet Directory, Oracle Virtual Directory, and Administration Server	Outbound	N/A
Enterprise Manager Agent - directory tier to Enterprise Manager	FW2	5160	HTTP / Enterprise Manager Agent and Enterprise Manager	Both	N/A
OPMN access in directory tier	FW2	OPMN remote port	HTTP / Administration Server to OPMN	Inbound	N/A
Oracle Virtual Directory proxy port	FW2	8899	HTTP / Administration Server to Oracle Virtual Directory	Inbound	N/A
Database access	FW2	1521	SQL*Net	Both	Timeout depends on all database content and on the type of process model used for Oracle Identity Management.
Oracle Internet Directory access	FW2	389	LDAP	Inbound	You should tune the directory server's parameters based on the load balancer, and not the other way around. Ideally, these connections should be configured not to time out.
Oracle Internet Directory access	FW2	636	LDAP SSL	Inbound	You should tune the directory server's parameters based on the load balancer, and not the other way around. Ideally, these connections should be configured not to time out.
Oracle Virtual Directory access	FW2	6501	LDAP	Inbound	Ideally, these connections should be configured not to time out.
Oracle Virtual Directory access	FW2	7501	LDAP SSL	Inbound	Ideally, these connections should be configured not to time out.
Load balancer to Oracle HTTP Server	N/A	7777	HTTP	N/A	N/A
Session replication within a WebLogic Server cluster	N/A	N/A	N/A	N/A	By default, this communication uses the same port as the server's listen address.
Node Manager	N/A	5556	TCP/IP	N/A	N/A
WebGate access from OAMADMINHOST	N/A	This is optional. You can use the listen port of the Oracle HTTP Server where the WebGate is configured (7777)	OAP	N/A	N/A
WebPass access from OAMADMINHOST	N/A	6022	OIP	N/A	N/A
Identity Server access	N/A	6022	OIP	N/A	N/A

Note:

Additional ports might need to be opened across the firewalls to enable applications in external domains, such as SOA or WebCenter Domains, to authenticate against this Identity Management Domain.

2.3 WebLogic Domain Considerations

A domain is the basic administration unit for WebLogic Server instances. A domain consists of one or more WebLogic Server instances (and their associated resources) that you manage with a single Administration Server. You can define multiple domains based on different system administrators' responsibilities, application boundaries, or geographical locations of servers. Conversely, you can use a single domain to centralize all WebLogic Server administration activities.

In the context of Identity Management, it is recommended that the Identity Management components be deployed in a separate WebLogic Server domain from SOA, WebCenter and other customer applications that might be deployed. In a typical enterprise deployment, the administration of identity management components such as LDAP directory, single sign-on solutions, and provisioning solutions is done by a different set of administrators from those who administer the middleware infrastructure and applications.

It is technically possible to deploy everything in a single domain in a development or test environment. However, in a production environment, the recommendation to use separate domains creates a logical administrative boundary between the identity management stack and the rest of the middleware and application deployment.

2.4 Shared Storage and Recommended Directory Structure

This following section details the directories and directory structure that Oracle recommends for an EDG topology. Other directory layouts are possible and supported, but the model adopted in this guide is chosen for maximum availability, providing both the best isolation of components and symmetry in the configuration and facilitating backup and disaster recovery. The rest of the document uses this directory structure and directory terminology.

2.4.1 Directory Structure Terminology and Environment Variables

This section describes directory structure terminology and environment variables.

• ORACLE_BASE: This environment variable and related directory path refers to the base directory under which Oracle products are installed.

• MW_HOME: This environment variable and related directory path refers to the location where Oracle Fusion Middleware resides. A MW_HOME has a WL_HOME, a COMMON_ORACLE_HOME and one or more ORACLE_HOMEs.

• WL_HOME: This environment variable and related directory path contains installed files necessary to host a WebLogic Server.

• ORACLE_HOME: This environment variable and related directory path refers to the location where Oracle Fusion Middleware Identity Management is installed.

• COMMON_ORACLE_HOME: This environment variable and related directory path refers to the location where the Oracle Fusion Middleware Common Java Required Files (JRF) Libraries and Oracle Fusion Middleware Enterprise Manager Libraries are installed.

• DOMAIN directory: This directory path refers to the location where the Oracle WebLogic domain information (configuration artifacts) is stored. Different WebLogic Servers can use different domain directories even when in the same node as described Section 2.4.2, "Recommended Locations for the Different Directories."

• ORACLE_INSTANCE: An Oracle instance contains one or more system components, such as Oracle Web Cache, Oracle HTTP Server, or Oracle Internet Directory. An Oracle instance directory contains updateable files, such as configuration files, log files, and temporary files.

2.4.2 Recommended Locations for the Different Directories

Oracle Fusion Middleware 11g allows the separation of the product binaries and the runtime artifacts.

In this enterprise deployment model, for the web tier and the data tier, it is recommended to have one ORACLE_HOME (for product binaries) per host and one ORACLE_INSTANCE for an instance, installed on the local or shared disk. The ORACLE_HOME can be shared by all the instances running on the host. Each instance has its own ORACLE_INSTANCE location. Both ORACLE_HOME and ORACLE_INSTANCE can also be located on a shared disk mounted to the respective boxes. Additional servers (when scaling out or up) of the same type can use one of these MW_HOME without requiring more installations.

For the application tier, it is recommended to have Middleware Home (MW_HOME) on a shared disk. It is recommended to have two MW_HOME in the domain for High Availability. An application Tier node mounts either one of these on a mount point. This mount point should be the same on all the application tier nodes. Additional servers (when scaling out or up) of the same type can use one of these MW_HOME without requiring more installations.

Based on the above recommendations, Table 2-3 lists the recommended directory structure. The directory locations listed are examples and can be changed. However, Oracle recommends that these locations be used for uniformity, consistency and simplicity.

Note:

In the table below, wherever shared storage is required for a directory, the shared storage column specification is qualified with the word Yes. When using local disk or shared storage is optional, the shared storage column specification is qualified with the word Optional. The shared storage locations are examples and can be changed as long as the provided mount points are used.

Table 2-3 Recommended Directory Structure

	Environment Variable	Mount Point or Directory Structure	Shared Storage Location	Hostname	Shared Storage
Common	ORACLE_BASE	/u01/app/oracle
	MW_HOME	ORACLE_BASE/product/fmw
Web Tier	ORACLE_HOME	MW_HOME/web			Optional
	ORACLE_INSTANCE	ORACLE_BASE/admin/instanceName			Optional
Identity Management Application Tier	MW_HOME	ORACLE_BASE/product/fmw	/vol/MW_HOME1	IDMHOST1	Yes
	MW_HOME	ORACLE_BASE/product/fmw	/vol/MW_HOME2	IDMHOST2	Yes
	ORACLE_HOME	MW_HOME/idm			Yes
	WL_HOME	MW_HOME/wlserver_version			Yes
	ORACLE_INSTANCE	ORACLE_BASE/admin/instanceName			Optional
	ASERVER_HOME	ORACLE_BASE/admin/domainName/aserver	/vol/admin	IDMHOST1	Yes
	ASERVER_DOMAIN_HOME	ASERVER_HOME/domainName
	ASERVER_APP_HOME	ASERVER_HOME/applications
	MSERVER_HOME	ORACLE_BASE/admin/domainName/mserver			Optional
	MSERVER_DOMAIN_HOME	MSERVER_HOME/domainName
	MSERVER_APP_HOME	MSERVER_HOME/applications
OAM Application Tier	OAM_BASE	MW_HOME/oam			Optional
	IDENTITY_SERVER_ORACLE_HOME	OAM_BASE/identity			Optional
	ACCESS_SERVER_ORACLE_HOME	OAM_BASE/access			Optional
	WEBPASS_ORACLE_HOME	OAM_BASE/webcomponents/identity			Optional
	POLICY_MANAGER_ORACLE_HOME	OAM_BASE/webcomponents/access			Optional
	WEBGATE_ORACLE_HOME	OAM_BASE/webgate			Optional
Directory Tier	ORACLE_HOME	MW_HOME/idm			Optional
	ORACLE_INSTANCE	ORACLE_BASE/admin/instanceName			Optional

The following commands are examples. Use the appropriate commands for your Operating System.

• To mount the MW_HOME1 volume on the shared storage to the MW_HOME mountpoint on IDMHOST1 run the following command on IDMHOST1 as root:

  mount storageHost:/Path_to_MW_HOME1_volume_on_SharedDisk 
  MW_HOME_moutpoint_on_IDMHOST1 
  -t nfs 
  -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
  

  For Example:

  mount storageHost:/vol/MW_HOME1 /u01/app/oracle/product/fmw -t nfs \
     -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
  

• To mount the MW_HOME2 volume on the shared storage to the MW_HOME mountpoint on IDMHOST2 run the following command on IDMHOST2 as root:

  mount storageHost:/Path_to_MW_HOME2_volume_on_SharedDisk 
  MW_HOME_moutpoint_on_IDMHOST2 
  -t nfs 
  -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
  

  For Example:

  mount storageHost:/vol/MW_HOME2 /u01/app/oracle/product/fmw -t nfs \
     -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
  

• To mount the ADMIN volume on the shared storage to the AServer_Home mountpoint on IDMHOST1 run the following command on IDMHOST1 as root:

  mount storageHost:/Path_to_ADMIN_volume_on_SharedDisk 
  ASERVER_HOME_moutpoint_on_IDMHOST1 
  -t nfs 
  -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
  

  For Example:

  mount storageHost:/vol/ADMIN /u01/app/oracle/admin/IDMDomain/aserver -t nfs \
     -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
  

Figure 2-1 shows the recommended directory structure.

Figure 2-1 Directory Structure for Identity Management

Description of "Figure 2-1 Directory Structure for Identity Management"

Table 2-4 explains what the color-coded elements in Figure 2-1 mean. The directory structure in Figure 2-1 does not show other required internal directories such as ORACLE_COMMON and jrockit.

Table 2-4 Directory Structure Elements

Element	Explanation
	The Administration Server domain directories, applications, deployment plans, file adapter control directory, JMS and TX logs, and the entire MW_HOME are on a shared disk.
	The Managed Server domain directories can be on a local disk or a shared disk. Further, if you want to share the Managed Server domain directories on multiple nodes, then you must mount the same shared disk location across the nodes. The instance_name directory for the web tier can be on a local disk or a shared disk.
	Fixed name.
	Installation-dependent name.