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"

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	4 or more X Pentium 1.5 GHz or greater	10 GB	4 GB	Default	Default
IDMHOSTn, OAMHOSTn	4 or more X Pentium 1.5 GHz or greater	10 GB	4 GB	Default	Default
OAMADMINHOST	4 or more X Pentium 1.5 GHz or greater	10 GB	4 GB	Default	Default
OIDHOSTn, OVDHOSTn	4 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.myco mpany.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.myco mpany.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.my company.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.mycom pany.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 Virt ual 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 Acc ess 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 (NIP) 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:

The user requests access to a protected resource over HTTP or HTTPS.
The WebGate intercepts the request.
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).
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.
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 Por t 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 num bers 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 U sed 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	NAP	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)	NAP	N/A	N/A
WebPass access from OAMADMINHOST	N/A	6022	NIP	N/A	N/A
Identity Server access	N/A	6022	NIP	N/A	N/A

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.3.1 Directory Structure Terminology and Recommendations

This section provides directory structure terminology and recommendations for the enterprise deployment.

2.3.1.1 Directory Stru cture Terminology

This section describes directory structure terminology and environment variables.

ORAC LE_BASE: This environment variable and related directory path refers to the base directory under which Oracle products are installed.
MW_H OME: This environment variable and related directory path refers to the location where Oracle Fusion Middleware resides.
WL_HO ME: This environment variable and related directory path contains installed files necessary to host a WebLogic Server.
ORACL E_HOME: This environment variable and related directory path refers to the location where Oracle Fusion Middleware Identity Management is installed.
DOM AIN 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.3.1.2, "Directory Structure Recommendations."
ORACL E_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.3.1.2 Directory Structure Recommendations

Oracle Fusion Middleware 11g allows the separation of the product binaries and the runtime artifacts. The product binaries are under the ORACLE_HOME directory and the runtime time artifacts are located under the ORACLE_INSTANCE directory.

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 disk. The ORACLE_HOME is shared among all the instances running on the host, whereas each instance has its own ORACLE_INSTANCE location. Additional, servers (when scaling out or up) of the same type can use either one of the same location without requiring more installations.

For the application tier, it is recommended to have one Middleware Home (MW HOME) per host (each of which has a WLS HOME and an ORACLE_HOME for each product suite) installed on the local disk. Additional servers (when scaling out or up) of the same type can use the same location without requiring more installations.

Separation of the domain directory and the MW_HOME is not supported. The domain directory is under the MW_HOME and is shared between all the Administration Servers and Managed Servers running on the host.

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.

Table 2-3 Directory Structure for Enterprise Deployment

Tier	Parameter/Values
Common	ORACLE_BASE=/u01/app/oracle MW_HOME=ORACLE_BASE/product/fmw ORACLE_INSTANCE=ORACLE_BASE/admin/instanceName
Web Tier	ORACLE_HOME=MW_HOME/web
Application Tier	ORACLE_HOME =MW_HOME/idm DOMAIN_HOME=MW_HOME/user_projects/domains/domainName APPLICATIONS_HOME=MW_HOME/user_projects/applications
Oracle Access Manager	OAM_BASE=MW_HOME/oam IDENTITY_SERVER_ORACLE_HOME=OAM_BASE/identity ACCESS_SERVER_ORACLE_HOME=OAM_BASE/access WEBPASS_ORACLE_HOME=OAM_BASE/webcomponents/identity POLICY_MANAGER_ORACLE_HOME=OAM_BASE/webcomponents/access WEBGATE_ORACLE_HOME=OAM_BASE/webgate
Data Tier	ORACLE_HOME=MW_HOME/idm

Figure 2-1 shows the recommended directory structure.

Figure 2-1 Oracle Home Directories for Components in This Manual

Description of "Figure 2-1 Oracle Home Directories for Components in This Manual"