2 Introduction and Planning

This chapter describes and illustrates the enterprise deployment reference topology employed in this guide.

The key to a successful Enterprise Deployment is planning and preparation. The road map for installation and configuration at the end of this chapter directs you to the appropriate chapters for the tasks you need to perform. Use this chapter to help you map the examples used in this guide to your own deployment.

This chapter contains the following topics:

• Section 2.1, "Planning Your Deployment"

• Section 2.3, "Understanding the Topology"

• Section 2.4, "Hardware Requirements for an Enterprise Deployment"

• Section 2.5, "Software Components for an Enterprise Deployment"

• Section 2.6, "Road Map for the Reference Topology Installation and Configuration"

• Section 2.7, "Additional Documentation"

2.1 Planning Your Deployment

An enterprise deployment for Identity And Access Management consists of the following parts:

• A highly available database for storing policy information and information specific to the identity and access management components being deployed.

• Identity And Access Management components installed in a highly available manner to support the creation and management of identity information, as well as to restrict access to resources based on the policies and identities stored within the database and identity store. Identity And Access Management components can be divided into three categories:

  • Directory Services: one or more highly available directories for storing identity information

  • Identity Management Provisioning: Oracle Identity Manager

  • Access Control: Oracle Access Management Access Manager

• A highly available web tier which is used to access Identity and Access Management components, to restrict access to those components and to ascertain the identity of people and processes trying to gain access to corporate resources.

• A highly available load balancer, which is used to distribute load between the web servers. The load balancer can also be used to off load SSL encryption to ensure that communication between user sessions and Oracle Identity and Access Management are encrypted, but without the overhead of having to enable SSL between the individual Identity and Access Management components.

There are many ways that these component parts can be put together. This guide explains in detail how to deploy one topology. This topology is not the only one supported by Oracle, but it is deemed to be the most common.

This section contains the following topics:

• Section 2.1.1, "Deployment Topology"

• Section 2.1.2, "Benefits of Using the Split Domain Topology"

2.1.1 Deployment Topology

A topology is a deployment map of components. There are several different ways that Oracle Identity and Access Management components can be installed to provide a working Identity and Access management solution. A topology can also be described as an architectural blueprint. This guide shows a common deployment topology for Oracle Identity and Access Management.

There are many different ways that Oracle Identity and Access Management can be deployed in an Enterprise Deployment. The two most common deployment models involve placing everything into a single domain and separating operational and managerial components into different domains. The figure below shows the split domain deployment model.

Figure 2-1 Split Domain Topology

This figure is a graphical representation of the enterprise topology. It includes icons and symbols that represent the hardware load balancer, host computers, firewalls, and other elements of the topology. At a high level, it shows the main components of the topology. The instructions in this guide describe how to install and configure the software for this topology.

For more information, refer to Section 2.3, "Understanding the Topology."

The topology is divided into tiers, including the following:

2.1.1.1 The Web Tier

There are two servers, each of which hosts an Oracle HTTP Server and Oracle WebGate.

2.1.1.2 The Application Tier

The Application Tier consists of the following components:

• An Oracle WebLogic Administration Server for each domain. Inside the administration server are managerial and navigational components for the domain, such as: Oracle WebLogic Console, Oracle Enterprise Manager Fusion Middleware Control, and Access Management Console.

  A WebLogic Administration server is a singleton process. That is, it can only be started on one server at a time. In the event that the host running the administration server fails, the Administration server can be manually started on a different host. The WebLogic managed servers for Oracle Access Management are placed into a domain called IAMAccessDomain, and the managed servers for Oracle Identity Manager and SOA components are placed into a domain called IAMGovernanceDomain

• Oracle Access Management Access Manager, which hosts Access Server, Federation and corresponding Java Required Files/Oracle Platform Security Services processes

• Oracle Adaptive Access Manager Server and Oracle Adaptive Access Management Administration and corresponding Java Required Files/Oracle Platform Security Services processes

• Oracle Identity Manager, which hosts an Oracle Identity Manager Server and corresponding JRF/OPSS processes

• Oracle SOA, which hosts a SOA Server and corresponding Java Required Files/Oracle Platform Security Services processes

• Oracle Unified Directory, which is the LDAP directory for identity information. Oracle Unified Directory instance is kept up to date through Oracle Unified Directory replication.

The Application Tier components in the figure are shown on logical hosts within physical hosts. These logical hosts can be virtual machines or lower specification hardware servers.You can deploy these components either in a distributed topology, using the logical hosts, or in a consolidated topology where the logical hosts are combined into larger physical hosts.

Distributed Topology

In a Distributed Topology the Application Tier components are located as follows:

Table 2-1 Location of Components in a Distributed Topology

Machine	Component	Domain
OAMHOST1	WebLogic Administration Server Oracle Access Management Access Manager Oracle Adaptive Access Manager	IAMAccessDomain
OIMHOST1	WebLogic Administration Server Oracle Identity Manager Oracle SOA Oracle Authorization Policy Manager	IAMGovernanceDomain
LDAPHOST1	Oracle Unified Directory
OAMHOST2	WebLogic Administration Server (Passive) Oracle Access Management Access Manager Oracle Adaptive Access Manager	IAMAccessDomain
OIMHOST2	WebLogic Administration Server (Passive) Oracle Identity Manager Oracle SOA	IAMGovernanceDomain
LDAPHOST2	Oracle Unified Directory

Consolidated Topology

In a Consolidated Topology the Application Tier components are located as follows:

Table 2-2 Location of Components in a Consolidated Topology

Machine	Component	Domain
IAMHOST1	WebLogic Administration Server Oracle Access Management Access Manager Oracle Adaptive Access Manager	IAMAccessDomain
	WebLogic Administration Server Oracle Identity Manager Oracle SOA Oracle Authorization Policy Manager	IAMGovernanceDomain
	Oracle Unified Directory
IAMHOST2	WebLogic Administration Server (Passive) Oracle Access Management Access Manager Oracle Adaptive Access Manager	IAMAccessDomain
	WebLogic Administration Server (Passive) Oracle Identity Manager Oracle SOA	IAMGovernanceDomain
	Oracle Unified Directory

Oracle Adaptive Access Manager is an optional component in the deployment.

2.1.1.3 The Data Tier

This is where the databases reside. The databases contain customer data and the schemas required by the application tier products.

2.1.1.4 The Load Balancer

Inside the demilitarized zone (DMZ) is a load balancer which directs requests received on SSO.mycompany.com, IADADMIN.mycompany.com and IDMINTERNAL.mycompany.com and directs requests to the Oracle HTTP servers. In the case of SSO.mycompany.com, requests are SSL encrypted. This is terminated at the load balancer. IGDADMIN.mycompany.com and IDMINTERNAL.mycompany.com handle requests using the HTTP protocol.

In addition, the load balancer distributes LDAP requests among the Oracle Unified Directory instances on LDAPHOST1 and LDAPHOST2, using the load balancer virtual host IDSTORE.mycompany.com

2.1.1.5 Firewalls

These are used to separate the Web, Application, and Data tiers into different zones. WEBHOST1 and WEBHOST2 reside in the DMZ.

2.1.2 Benefits of Using the Split Domain Topology

The split domain topology is suitable for large organizations requiring individual control over each component in the deployment.

The main advantages of the Split Domain topology are related to patching flexibility. Specifically:

• As each component (Oracle Identity Manager and Access Manager) reside in different domains, you can apply patches (even domain level ones) so that they update only the component they are targeted at.

• You can patch Administrative Components such as Oracle Identity Manager without the need for a controlled outage, which you would require when updating an Operational component such as Access Manager).

2.2 About Oracle Directory Services Manager

Oracle Directory Services Manager provides direct access to the configuration and data installed inside the LDAP directory. This is considered a development tool and is therefore not included in the Enterprise Deployment topology.

2.3 Understanding the Topology

Each topology is divided into tiers for increased security and protection. The tiers are separated by firewalls that control access from one tier to the next. The goal is to prevent unauthorized traffic. In an Internet-facing topology, for instance, it should not be possible to directly access a database from the Internet zone. Only applications deployed in the application zone should have access to the database.

The diagram shows three tiers:

• Web Tier

• Application Tier

• Database Tier

Although it is not shown on the figures, there can also be a directory tier (which is often included in the database tier). If a dedicated directory tier is introduced, LDAP directories can be placed within that tier.

This section contains the following topics:

• Section 2.3.1, "About the Web Tier"

• Section 2.3.2, "About the Application Tier"

• Section 2.3.3, "About the Optional Directory Tier"

• Section 2.3.4, "About the Database Tier,"

2.3.1 About the Web Tier

The web tier is in the DMZ Public Zone. The HTTP Servers are deployed in the web tier.

Most of the Identity and Access Management components can function without the web tier, but for most enterprise deployments, the web tier is desirable. To support enterprise level single sign-on using products such as Oracle Single Sign-On and Access Manager, the web tier is required.

While components such as Oracle Enterprise Manager Fusion Middleware Control and WebLogic Console can function without a web tier, they can be configured to use a web tier, if desired.

In the web tier:

• WEBHOST1 and WEBHOST2 have Oracle HTTP Server, WebGate (an Access Manager component), and the mod_wl_ohs plug-in module installed. The mod_wl_ohs plug-in module enables requests to be proxied from Oracle HTTP Server to a WebLogic Server running in the application tier.

• WebGate (an Oracle Access Management Access Manager component) in Oracle HTTP Server uses Oracle Access Protocol (OAP) to communicate with Access Manager running on OAMHOST1 and OAMHOST2, in the Identity Management zone. WebGate and Access Manager are used to perform operations such as user authentication.

On the firewall protecting the web tier, the HTTP ports are 443 (HTTP_SSL_PORT) for HTTPS and 80 (HTTP_PORT) for HTTP. Port 443 is open.

2.3.1.1 Architecture Notes

Oracle HTTP Servers on WEBHOST1 and WEBHOST2 are configured with mod_wl_ohs, to proxy requests to Oracle Identity and Access Management J2EE applications deployed in WebLogic Servers on OAMHOST1, OAMHOST2, OIMHOST1, and OIMHOST2.

2.3.1.2 High Availability Provisions

If the Oracle HTTP server fails on the WEBHOST, Oracle Process Management and Notification (OPMN) server attempts to restart it.

2.3.1.3 Security Provisions

The Oracle HTTP Servers process requests received using the URLs SSO.mycompany.com, IGDADMIN.mycompany.com, and IADADMIN.mycompany.com. The names IADADMIN.mycompany.com and IGDADMIN.mycompany.com are only resolvable inside the firewall. This prevents access to sensitive resources such as the Oracle WebLogic Server console and Oracle Enterprise Manager Fusion Middleware Control console from the public domain.

2.3.2 About the Application Tier

The application tier is the tier where Java EE applications are deployed. Products such as Oracle Identity Manager and Oracle Enterprise Manager Fusion Middleware Control are the key Java EE components that can be deployed in this tier. Applications in this tier benefit from the High Availability support of Oracle WebLogic Server.

The Identity and Access Management applications in the application tier interact with the directory tier as follows:

• They leverage the directory tier for enterprise identity information.

• In some cases, they leverage the directory tier (and sometimes the database in the data tier) for application metadata.

• Oracle Enterprise Manager Fusion Middleware Control is an administration tool that provides administrative functionalities to the components in the application tier as well as the directory tier.

• WebLogic Server has built-in web server support. If enabled, the HTTP listener exists in the application tier as well. However, for the enterprise deployment shown in Figure 1-1, customers have a separate web tier relying on web servers such as Apache or Oracle HTTP Server.

The application tier includes the following components. Their locations within the application tier are described in Table 2-1, "Location of Components in a Distributed Topology" and Table 2-2, "Location of Components in a Consolidated Topology".

• Oracle Access Management Access Manager (OAM). This is an J2EE applications which is run within Oracle WebLogic Server.

• Oracle Adaptive Access Manager (OAAM).

• Oracle Identity Manager and Oracle Entitlements Server Policy Manager, which are used for user provisioning and policy management.

• The governance components, which are Oracle Authorization Policy Manager (APM), Oracle Identity Manager (OIM), and Oracle SOA Suite (SOA).

• The administrative components of Identity and Access Management, including Oracle Identity Manager, which is used for user provisioning. Note: These servers also run Oracle SOA which is used exclusively by Oracle Identity Manager. Oracle Identity Manager (OIM) communicates with the directory tier.

In addition:

• OAMHOST1 in the distributed topology, or IAMHOST1 in the consolidated topology, hosts an Oracle WebLogic Administration Server for IAMAccessDomain. Inside the administration server are managerial and navigational components for the domain including: Oracle WebLogic Console, Oracle Enterprise Manager Fusion Middleware Control, and Access Management console.

• OIMHOST1 in the distributed topology, or IAMHOST1 in the consolidated topology, hosts an Oracle WebLogic Administration Server for IAMGovernanceDomain. Inside the administration server are managerial and navigational components for the domain including: Oracle WebLogic Console, Oracle Enterprise Manager Fusion Middleware Control, and Oracle Authorization Policy Manager.

• The WebLogic Administration server is a singleton process. That is, it can only be started on one server at a time. In the event that the host running the administration server fails, the Administration server can be manually started on a different host.

2.3.2.1 About WebLogic Domains

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 topology used in this version of the guide, Access and Governance domains are in separate WebLogic Server domains from the one where customer applications might be deployed. Oracle Identity Manager is deployed into a separate, dedicated domain so that it can be patched independently of other products.

2.3.2.2 About LDAP Directories

Identity information is stored with an LDAP compliant directory. In this implementation, it is Oracle Unified Directory. Oracle Unified Directory is an all-in-one directory solution with storage, proxy, synchronization and virtualization capabilities. It ensures scalability to billions of entries, ease of installation, elastic deployments, enterprise manageability and effective monitoring. Its flexible deployment architecture provides high performance levels to meet application requirements.

Note:

This release of Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity and Access Management does not support Oracle Internet Directory and Active Directory as directory stores. Configuring the deployed environment for Oracle Internet Directory or Active Directory must be done outside of the Deployment process

The standard LDAP port is 389 (LDAP_LBR_PORT) for the non-SSL port and 636 (LDAP_LBR_SSL_PORT) for the SSL port. LDAP services are often used for white pages lookup by clients such as email clients in the intranet. The ports 389 and 636 on the load balancer are typically redirected to the non-privileged ports used by the individual directory instances. LDAP requests are distributed among the Oracle Unified Directory hosts using a hardware load balancer.

Many organizations have an existing directory deployment. If you do not have an existing deployment, then you can use this guide to learn how to configure Oracle Unified Directory to take on this role. If you have an existing directory, you can use this guide to learn how to configure that directory for use with Oracle Identity and Access Management. If you do not have a directory and you want to use a directory other than Oracle Unified Directory, refer to your directory documentation for information about configuring these directories in a highly available manner.

Oracle Unified Directory stores information locally in a Berkeley database. To ensure high availability, this information is replicated to other Oracle Unified Directory instances using Oracle Unified Directory replication.

Oracle Unified Directory server instances natively use replication to keep their embedded databases in sync. By default, replication employs a loose consistency model in which the updates are replicated to replicas AFTER returning the operation result to the application. In this model it is therefore possible to write some data to a replica, and read outdated information from another replica for a short time after the write. Great efforts have been made in Oracle Unified Directory replication to ensure that the replication process is fast and can achieve replication in the order of one millisecond.

Oracle Unified Directory can be configured to use the Assured Replication model, which has been developed to guarantee that the data in the replicas is consistent. When using the Safe Read mode of Assured Replication, applications have the guarantee that the replication process is completed before returning the result of a write operation.

Using Assured Replication has a negative impact on the response time of write operations because it requires some communications with remote replicas before returning the operation result. The amount of the delay varies, depending on the network being used and the capacity of the servers hosting Oracle Unified Directory. Using Assured replication has little if any impact on read operations.

If you expect to regularly perform large writes to your directory, consider configuring your load balancer to distribute requests to your Oracle Unified Directory instances in an active/passive mode. This will remove the chance of you reading out of date data from a replica, but could result in overall performance degradation if your Oracle Unified Directory host is not capable of processing all of the requests.

For the purposes of this Guide, it is assumed that the ability to have multiple servers processing requests is more important than the extra overhead incurred with writing requests in Assured mode. To that end, this Guide shows the configuration of Oracle Unified Directory using Assured Replication. Both of the following Oracle Unified Directory configurations, however, are supported:

• Active/Active in an assured configuration

• Active/Passive in a non assured configuration

For more information, see the Assured Replication section of Oracle Fusion Middleware Administrator's Guide for Oracle Unified Directory.

Oracle Unified Directory normally keeps track of changes by using an internal change number. The change number is specific to each Oracle Unified Directory instance, which can cause issues if one Oracle Unified Directory instance fails without the entry being replicated. Such a failure can impact Oracle Identity Manager reconciliation.

Note:

There is no automatic restart if Oracle Unified Directory fails. Oracle Unified Directory relies on requests being redirected to a surviving instance by the load balancer.

2.3.2.3 Architecture Notes

• An embedded version of Oracle Entitlement Server is used to control access to Oracle Fusion Middleware components.

• Oracle Entitlements Server uses a centralized policy store that is stored within a database.

• Oracle Adaptive Access Manager is an optional component.

• Access Manager uses the OPSS Policy Store to store policy information.

• In a split domain configuration, Oracle Identity Manager and SOA are installed into a separate domain from other components.

• The Oracle WebLogic Server console, Oracle Enterprise Manager Fusion Middleware Control, and Access Management console are always bound to the listen address of an Administration Server.

• The WebLogic administration server is a singleton service. It runs on only one node at a time. In the event of failure, it is restarted on a surviving node.

• The managed servers WLS_OAM1 and WLS_OAM2 are deployed in a cluster and Access Manager applications deployed to the cluster.

• The managed servers WLS_OIM1 and WLS_OIM2 are deployed in a cluster and Identity Manager applications deployed to the cluster.

• The managed servers WLS_SOA1 and WLS_SOA2 are deployed in a cluster and Identity Manager applications deployed to the cluster.

2.3.2.4 High Availability Provisions

• Access Manager Server, Oracle Identity Manager, and SOA are active-active deployments; these servers communicate with the data tier at run time.

• The WebLogic Administration Server and Oracle Enterprise Manager deployment is active-passive (where other components are active-active). There is one Administration Server per domain.

• The WebLogic Administration Server is a singleton component deployed in an active-passive configuration. If the primary fails or an Administration Server does not start on its assigned host, the Administration Server can be started on a secondary host. If a WebLogic managed server fails, the node manager running on that host attempts to restart it.

2.3.2.5 Security Provisions

Oracle WebLogic Server Console, Oracle Enterprise Manager Fusion Middleware Control console, and Oracle Access Management Console are only accessible through a virtual host configured on the load balancer, which is only available inside the firewall.

2.3.3 About the Optional Directory Tier

No directory tier is shown in Section 2.1.1, "Deployment Topology," as this Guide features the use of Oracle Unified Directory, which typically resides in the application tier. You can also put Oracle Unified Directory in a directory tier for added security, as the directory tier is typically protected by firewalls. Applications above the directory tier access LDAP services through a designated LDAP host port and sometimes a management port, which should be opened in that firewall.

The directory tier is typically managed by directory administrators providing enterprise LDAP service support.

2.3.4 About the Database Tier

Starting with 11g Release 2 (11.1.2), policy information is stored in the database. The database is also used for storing information specific to the Identity and Access Management components being deployed.

In some cases, the directory tier and data tier might be managed by the same group of administrators. In many enterprises, however, database administrators own the data tier while directory administrators own the directory tier.

Although not shown in the diagram, you might be required to place directories into the Database tier for added security.

2.4 Hardware Requirements for an Enterprise Deployment

You can deploy either a distributed or a consolidated topology. The consolidated topology uses a small number of powerful servers, which makes the deployment simpler. It is, however, not mandatory to use such powerful servers. The distributed topology uses a larger number of smaller servers.

These servers should have the minimum specification shown in Table 2-3, "Typical Hardware Requirements for a Distributed Topology" or Table 2-4, "Typical Hardware Requirements for a Consolidated Topology".

For detailed requirements, or for requirements for other platforms, see Oracle Fusion Middleware System Requirements and Specifications.

Table 2-3 Typical Hardware Requirements for a Distributed Topology

Server	Processor	Disk	Memory	TMP Directory	Swap
Database Host IAMDBHOSTn	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
OIMHOSTn	6 or more X Pentium 1.5 GHz or greater	10 GB	8 GB	Default	Default
OAMHOSTn	6 or more X Pentium 1.5 GHz or greater	10 GB	8 GB	Default	Default
LDAPHOSTn	2 or more X Pentium 1.5 GHz or greater	10 GB	4 GB	Default	Default

Table 2-4 Typical Hardware Requirements for a Consolidated Topology

Server	Processor	Disk	Memory	TMP Directory	Swap
Database Host IAMDBHOSTn	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	25 GB	4 GB	Default	Default
IAMHOSTn	6 or more X Pentium 1.5 GHz or greater	30 GB	25 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. This, however, 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 WebLogic servers or directory/OHS instances as described in Section 14.4, "Scaling the Web Tier."

Note:

Oracle recommends configuring all nodes in the topology identically with respect to operating system levels, patch levels, user accounts, and user groups.

2.5 Software Components for an Enterprise Deployment

This section describes the software required for an Oracle Identity and Access Management enterprise deployment.

This section contains the following topics:

• Section 2.5.1, "Software Versions"

• Section 2.5.2, "About Obtaining Software"

• Section 2.5.3, "Summary of Oracle Homes"

• Section 2.5.4, "Applying Patches and Workarounds"

2.5.1 Software Versions

Table 2-5, "Software Versions Used" lists the Oracle software you need to obtain before starting the procedures in this guide.

Table 2-5 Software Versions Used

Short Name	Product	Version
OHS11G	Oracle HTTP Server	11.1.1.7.0
JRockit	Oracle JRockit	jrockit-jdk1.6.0_29-R28.2.0-4.0.1 or newer
WLS	Oracle WebLogic Server	10.3.6.0
IAM	Oracle Identity and Access Management	11.1.2.2.0
SOA	Oracle SOA Suite	11.1.1.7.0
WebGate	WebGate 11g	11.1.2.2.0
RCU	Repository Creation Assistant	11.1.2.2.0
OUD	Oracle Unified Directory	11.1.2.2.0

2.5.2 About Obtaining Software

To perform an automated installation of Oracle Identity and Access Management 11g Release 2 (11.1.2.2), download the Oracle Identity and Access Management Deployment Repository 11.1.2.2.0 from:

• The Oracle Software Delivery Cloud: http://edelivery.oracle.com/

• The Oracle Identity and Access Management download page: http://www.oracle.com/technetwork/middleware/id-mgmt/downloads/oid-11gr2-2104316.html

Note:

• If you downloaded a version of the Oracle Identity and Access Management Deployment Repository prior to April 8, 2014, you must replace it with a newer version before proceeding.

• If you are running RCU on a 64-bit Linux machine which does not have 32-bit system libraries available, you must either install such libraries for compatibility, or separately download the 64-bit version of RCU 11.1.2.2.0 and use that instead of the one present in the Deployment Repository.

For complete information about downloading Oracle Fusion Middleware software, see the Oracle Fusion Middleware Download, Installation, and Configuration Readme for this release, at: http://docs.oracle.com/cd/E23104_01/download_readme.htm

2.5.3 Summary of Oracle Homes

Oracle binaries are installed into an Oracle Fusion Middleware home. Individual products are installed into Oracle homes within the Middleware home. Table 2-6 is a summary of the Middleware homes and Oracle homes used in this document.

The installation and configuration of Oracle Identity Management is outside the scope of this Guide. See Oracle Fusion Middleware High Availability Guide for more information.

Table 2-6 Summary of Homes

Home Name	Home Description	Products Installed
IAD_MW_HOME	The Oracle Middleware Home containing the ORACLE_HOMEs required by Oracle Identity Manager.
IGD_MW_HOME	The Oracle Middleware Home containing the ORACLE_HOMEs required by Oracle Access Manager.
DIR_MW_HOME	The Oracle Middleware Home containing the ORACLE_HOMEs required by Oracle Unified Directory.
WL_HOME	This is the root directory in which Oracle WebLogic Server is installed. The WL_HOME directory is a peer of Oracle home directory and resides within the MW_HOME.	Oracle WebLogic Server
IAD_ORACLE_HOME	Contains the binary and library files required for Oracle Identity and Access Management and is located in IAD_MW_HOME/iam.	Access Manager
IGD_ORACLE_HOME	Contains the binary and library files required for Oracle Identity and Access Management and is located in IGD_MW_HOME/iam.	Oracle Identity Manager
OUD_ORACLE_HOME	Contains the binary and library files required for Oracle Unified Directory and is located in IAD_MW_HOME/oud	Oracle Unified Directory
WEBGATE_ORACLE_HOME	Contains the binaries for Oracle WebGate and is located in WEB_MW_HOME/web.	Oracle WebGate
SOA_ORACLE_HOME	Contains the binary and library files required for the Oracle SOA Suite. Located in IGD_MW_HOME/soa.	Oracle SOA Suite
ORACLE_COMMON_HOME	Contains the generic Oracle home files. This Oracle home is created automatically by any product installation and is located in MW_HOME/oracle_common.	Generic commands
LCM_HOME	Lifecycle Repository.
REPOS_HOME	Software Repository.
WEB_MW_HOME	The Oracle Middleware Home containing the ORACLE_HOMEs required by the web tier.
WEB_ORACLE_HOME	Contains the binary and library files required for Oracle HTTP server.

2.5.4 Applying Patches and Workarounds

See the Oracle Fusion Middleware Release Notes for your platform and operating system for a list of patches to apply. You must apply the patches to ensure that your software operates as expected.

Patches are available for download from http://support.oracle.com. You can find instructions for deploying each patch in the enclosed README.html file.

Before starting the deployment, download any patches that are listed in the Release Notes, plus any other patches that are appropriate for your environment. The deployment tool can apply these patches automatically at the time it runs.

Download the patches from http://support.oracle.com and unzip each patch to the directory appropriate for the product, as listed in Table 2-7. If the directory does not exist, create it.

After unzipping the patch make sure that the Patch Directory (as listed in Table 2-7) contains a directory which is a number. That directory contains directories and files similar to:

• etc

• files

• README.txt

This is the directory layout for most patches. In some cases, such as bundle patches, the layout might be similar to:

bundle_patch_no/product/product_patch_no

In this case make sure that it is product_patch_no which appears in the Patch Directory not bundle_patch_no.

If a bundle patch contains fixes for muiltiple products make sure that the individual patches appear in the correct Patch Directory as listed below.

Table 2-7 Product Patch Directories

Product	Patch Directory
Oracle Common	REPOS_HOME/installers/oracle_common/patch
Directory	REPOS_HOME/installers/oud/patch/oud REPOS_HOME/installers/oud/patch/odsm
Oracle Access Management Access Manager	REPOS_HOME/installers/iamsuite/patch/oam
OHS	REPOS_HOME/installers/webtier/patch
WebGate	REPOS_HOME/installers/webgate/patch
Oracle Identity Manager	REPOS_HOME/installers/iamsuite/patch/oim
SOA	REPOS_HOME/installers/soa/patch
WebLogic Server	REPOS_HOME/installers/weblogic/patch

2.6 Road Map for the Reference Topology Installation and Configuration

Before beginning your Oracle Identity and Access Management enterprise deployment, review the flow chart in Figure 2-2, "Flow Chart of the Oracle Identity and Access Management Enterprise Deployment Process". This flow chart illustrates the high-level process for completing the enterprise deployment documented in this guide. Table 2-8 describes the steps in the flow chart and directs you to the appropriate section or chapter for each step.

This section covers the following topics:

• Section 2.6.1, "Flow Chart of the Oracle Identity and Access Management Enterprise Deployment Process"

• Section 2.6.2, "Steps in the Oracle Identity and Access Management Enterprise Deployment Process"

2.6.1 Flow Chart of the Oracle Identity and Access Management Enterprise Deployment Process

Figure 2-2, "Flow Chart of the Oracle Identity and Access Management Enterprise Deployment Process" provides a flow chart of the Oracle Identity and Access Management enterprise deployment process. Review this chart to become familiar with the steps that you must follow, based on the existing environment.

Figure 2-2 Flow Chart of the Oracle Identity and Access Management Enterprise Deployment Process

2.6.2 Steps in the Oracle Identity and Access Management Enterprise Deployment Process

Table 2-8 describes each of the steps in the enterprise deployment process flow chart for Oracle Identity and Access Management, shown in Figure 2-2. The table also provides information on where to obtain more information about each step in the process.

Table 2-8 Steps in the Oracle Identity and Access Management Enterprise Deployment Process

Step	Description	More Information
Prepare your Network for Enterprise Deployment	To prepare your network for an enterprise deployment, understand concepts, such as virtual server names and IPs and virtual IPs, and configure your load balancer by defining virtual host names.	Chapter 3, "Preparing the Network for an Enterprise Deployment"
Prepare your Storage for Enterprise Deployment	To prepare your file system for an enterprise deployment, review the terminology for directories and directory environment variables, and configure shared and local storage.	Chapter 4, "Preparing Storage for an Enterprise Deployment"
Prepare your Servers for an Enterprise Deployment	To prepare your servers for an enterprise deployment, ensure that your servers meet hardware and software requirements, enable Unicode support and Virtual IP Addresses, mount shared storage, configure users and groups, and, if necessary, install software onto multihomed systems.	Chapter 5, "Configuring the Servers for an Enterprise Deployment"
Prepare automation (optional)	Prepare scripts for One command deployment if desired	Appendix A, "Automation of the Process"
Prepare your Database for Enterprise Deployment	To prepare your database for an enterprise deployment, review database requirements, create database services, load the metadata repository in the Oracle RAC database, configure Identity and Access Management schemas for transactional recovery privileges, and back up the database.	Chapter 6, "Preparing the Database for an Enterprise Deployment"
Prepare for Deployment	To prepare for Deployment, assemble required information, create a repository, verify Java, install the tools, and verify port availability	Chapter 7, "Preparing for Deployment"
Create a Deployment Profile	Run the wizard to create a Deployment response file.	Chapter 8, "Creating a Deployment Profile"
Deploy Identity and Access Management	Use the tools to perform all stages of Deployment.	Chapter 9, "Deploying Identity and Access Management"
Perform Post-Deployment Configuration	Perform post-Deployment tasks.	Chapter 10, "Performing Post-Deployment Configuration"
Validate Deployment	Perform validation checks.	Chapter 11, "Validating Deployment"
Extend a Domain to Include Oracle Adaptive Access Manager	Extend the domain with this optional component.	Chapter 12, "Extending the Domain to Include Oracle Adaptive Access Manager"

2.7 Additional Documentation

For up-to-date information, see Note: 1662923.1: Updates for Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity and Access Management 11g Release 2 (11.1.2.2.0). This document is available on My Oracle Support at https://support.oracle.com.