2 Introduction and Planning

This chapter describes and illustrates the enterprise deployment reference topologies 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.

You can use Appendix B, "Worksheets for Identity Management Topology" to help you keep track of information.

This chapter contains the following topics:

2.1 Planning Your Deployment

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

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

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

  • A highly available web tier which is used to access Identity 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 Management are encrypted, but without the overhead of having to enable SSL between the individual identity management components.

There are many ways that these component parts can be put together. Three topologies are shown in the next section. This guide explains in detail how to deploy them. These topologies are not the only ones supported by Oracle, but they are deemed to be the most common.

Note:

This guide does not show how to create Oracle Internet Directory instances or the Oracle Internet Directory domain.

This section contains the following topics:

2.1.1 Deployment Topologies

A topology is a deployment map of components. There are several different ways that Oracle Identity 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 the most common deployment topologies 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 three figures below show these two different deployment models.

This section contains the following topics:

2.1.1.1 Single Domain Topology

Figure 2-1 Single Domain Topology

Surrounding text describes Figure 2-1 .

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, including the following:

  • The Web Tier: There are two servers, each of which hosts an Oracle HTTP Server and Oracle WebGate.

  • The Application Tier: There are two servers, IDMHOST1 and IDMHOST2. Each contains managed servers for the following products:

    • Oracle Access Management, which hosts Access Server, Federation and corresponding JRF/OPSS processes

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

    • SOA, which hosts a SOA Server and corresponding JRF/OPSS processes

    • Oracle Unified Directory. Each host has an instance of Oracle Unified Directory which is used as the LDAP directory for identity information. Each Oracle Unified Directory instance is kept up to date through Oracle Unified Directory replication.

    IDMHOST1 also contains the WebLogic Administration Server, which hosts the WebLogic Console, Enterprise Manager Fusion Middleware Control, OAM Console, APM Console and ODSM (for Oracle Unified Directory). In the event of the failure of IDMHOST1, the WebLogic Administration Server can be started on IDMHOST2.

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

  • The Load Balancer: Inside the demilitarized zone (DMZ) is a load balancer which directs requests received on SSO.mycompany.com, ADMIN.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. ADMIN.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 IDMHOST1 and IDMHOST2, using the load balancer virtual host IDSTORE.mycompany.com

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

For more information, refer to the descriptions of the topology tiers in the sections that follow the diagrams. The instructions in this guide describe how to install and configure the software for this topology.

2.1.1.2 Split Domain Topology

Figure 2-2 Split Domain Topology

Surrounding text describes Figure 2-2 .

This figure is similar to Figure 2-1. It differs in that the WebLogic managed servers for Oracle Access Management are placed into a domain called IDMDomain, and the managed servers for Oracle Identity Manager and SOA components are placed into a domain called OIMDomain

In addition, a second administration server is configured on IDMHOST1 to support the second domain, OIMDomain.

Chapter 16, "Creating a Split Domain Topology," describes how to install and configure the software for this topology.

For more information, refer to the descriptions of the topology tiers in the sections that follow the diagrams.

2.1.1.3 Three Domain Topology

Figure 2-3 Three Domain Topology

Surrounding text describes Figure 2-3 .

This figure is similar to Figure 2-2. It differs in that Oracle Unified Directory is replaced by Oracle Internet Directory. The Oracle Internet Directory components are moved into the Database Tier, which has been renamed Directory Tier.

In the Directory Tier, there are two new hosts, OIDHOST1 and OIDHOST2. These hosts contain the Oracle Internet Directory instances. There is also a separate domain called OIDDomain which contains a WebLogic Administration Server and a pair of WebLogic managed servers, each of which hosts ODSM.

The Directory Tier also contains an additional database, which contains the Oracle Internet Directory schemas.

For more information, refer to the descriptions of the topology tiers in the sections that follow the diagrams.

2.1.2 Which Topology Should I Use?

The single domain topology and the split domain topology each have advantages and disadvantages.

This section contains the following topics:

2.1.2.1 Single Domain Topology

The advantages of the single domain topology are:

  • It is suitable for the majority of implementations

  • Every component is contained within a single WebLogic domain, making setup, management and patching simpler.

  • It is simpler to set up than the Split Domain Model.

  • The same topology is suitable for production and non-production systems

  • This is the same deployment model used by Identity Management for Fusion Applications

  • There are no complications introduced by having different IAM components in different domains.

  • Enterprise Manager Fusion Middleware Control shows a single consolidated view of all of the identity management components.

The disadvantages of the single deployment model are:

  • Identity Provisioning and Access Control are provided by the same deployment.

  • If a patch must be applied, and application of that patch requires the entire domain to be stopped, then service is interrupted to both Provisioning and Access Control.

  • A patch set that contains domain level updates can introduce compatibility issues. This is less likely to occur in a domain which has only Identity and Access Management installed, that is, a domain with no Oracle Internet Directory, Oracle Virtual Directory, or Oracle Identity Federation.

2.1.2.2 Split Domain Topology

The split domain topology is suitable for large organizations requiring finite 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).

The disadvantage of the split deployment topology are:

  • It is more complex to setup.

  • Components must be configured to work cross-domain.

  • Multiple software deployments are required, so there are more Middleware Homes.

  • Generic patches must be deployed to each domain.

  • Management of the domain is more complex. Specifically:

    • Two Administration Consoles

    • Two instances of Fusion Middleware Control

    • No single view of all the identity management components

2.1.2.3 Three Domain Topology

This topology is essentially the same as the split domain topology, but it uses Oracle Internet Directory instead of Oracle Unified Directory. In order to facilitate patching of Oracle Internet Directory independently of other components, Oracle Internet Directory is configured using a separate domain.

The guide assumes that you already have a highly available Oracle Internet Directory deployed, and does not cover its setup. For information on setting up highly available Oracle Internet Directory, see the "Oracle Internet Directory High Availability" section in Oracle Fusion Middleware High Availability Guide.

2.1.2.4 Summary

Unless you specifically require complete control of patching, that is, the ability to patch each identity management component separately, Oracle recommends that you use the single domain topology.

2.2 Understanding the Topologies

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.

Each of the diagrams above 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 is most commonly done in deployments using Oracle Internet Directory, which is closely tied to a database.

This section contains the following topics:

2.2.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 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 Oracle Directory Services Manager 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 component) in Oracle HTTP Server uses Oracle Access Protocol (OAP) to communicate with Access Manager running on IDMHOST1 and IDMHOST2, in the Identity Management DMZ. 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.2.1.1 Architecture Notes

Oracle HTTP Servers on WEBHOST1 and WEBHOST2 are configured with mod_wl_ohs, and proxy requests for the Oracle Enterprise Manager, Oracle Directory Integration Platform, and Oracle Directory Services Manager Java EE applications deployed in WebLogic Server on IDMHOST1 and IDMHOST2.

2.2.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.2.1.3 Security Provisions

The Oracle HTTP Servers process requests received using the URLs SSO.mycompany.com and ADMIN.mycompany.com. The name ADMIN.mycompany.com is 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.2.2 About the Application Tier

The application tier is the tier where Java EE applications are deployed. Products such as Oracle Identity Manager, Oracle Directory Integration Platform, Oracle Directory Services 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 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 and Oracle Directory Services Manager are administration tools that provide 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.

In the application tier, IDMHOST1 and IDMHOST2 include the following components:

  • The operational component of the infrastructure. This component is Oracle Access Management Access Manager (OAM). This is an J2EE applications which is run within Oracle WebLogic Server.

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

  • The administrative components of Identity 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:

  • IDMHOST1 hosts an Oracle WebLogic Administration Server. Inside the administration server are managerial and navigational components for the domain including: Oracle WebLogic Console, Oracle Enterprise Manager Fusion Middleware Control, Oracle Access Management Console, and Oracle Directory Services Manager (ODSM) for Oracle Unified Directory. 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.2.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 context of Identity Management, it is recommended that you deploy the Identity Management components, plus SOA, in a separate WebLogic Server domain from the one where SOA, Web Center Portal and other customer applications 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. Oracle Identity Manager can be deployed into a separate dedicated domain so that it can be patched independently of other products.

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.2.2.2 About LDAP Directories

Identity information is stored with an LDAP compliant directory. Oracle supports the following directories natively:

  • Oracle Unified Directory

  • Oracle Internet Directory

If you want to use a different directory, such as Microsoft Active Directory, you can either use Oracle Virtual Directory to present that information or use Oracle Directory Integration Platform to synchronize the users and groups from the other directory.

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, Oracle Internet Directory, or Oracle Virtual Directory hosts using a hardware load balancer.

If you have a complex directory implementation where identity information is split among multiple back end directories, you can use this implementation with Oracle Identity Management by using Oracle Virtual Directory.

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

2.2.2.2.1 About Oracle Unified Directory

If you store your identity information in Oracle Unified Directory, this information is stored 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.

Patch 16943171 allows Oracle Identity Manager to use a newer, more reliable Oracle Unified Directory mechanism for tracking changes, which relies on the use of cookies. This mechanism eliminates the issues that can arise on failover of Oracle Unified Directory. After Patch 16943171 is installed, Oracle Identity Manager uses cookie mode when automatically creating reconciliation jobs. If you decide to create custom reconciliation jobs, then you must force the use of Oracle Unified Directory cookie mode.

2.2.2.2.2 About Oracle Internet Directory and Oracle Virtual Directory

If you are using Oracle Internet Directory as your Identity Store, you can configure it to use multimaster replication as described in the Oracle Fusion Middleware High Availability Guide chapter Configuring Identity Management for Maximum High Availability. This enables you to maintain the same naming contexts on multiple directory servers. It can improve performance by providing more servers to handle queries and by bringing the data closer to the client. It improves reliability by eliminating risks associated with a single point of failure.

Oracle Identity Management, which includes Oracle Internet Directory, is on a different release cycle from Oracle Identity and Access Management. If your identity information is in Oracle Internet Directory, Oracle recommends that, for ease of patching, you place the Oracle Identity Management components, such as ODSM, in a separate MW_HOME and domain. It is, however, supported to have the components reside in the same domain. If you do not intend to manage your directories using Oracle Directory Services Manager, then you do not need to have a separate WebLogic domain as described in the directory topologies.

If you are using Oracle Unified Directory or Oracle Internet Directory exclusively, you do not need to use Oracle Virtual Directory.

Oracle Internet Directory and Oracle Virtual Directory are closely tied to the database tier for the following reasons:

  • Oracle Internet Directory relies on Oracle Database as its back end.

  • Oracle Virtual Directory provides virtualization support for other LDAP services or databases or both.

2.2.2.2.3 High Availability Provisions

In addition to the directory deployments, which are typically active/active, the following features provide high availability for the directories:

  • If the Oracle Internet Directory fails, Oracle Process Management and Notification (OPMN) server attempts to restart it.

  • If the Oracle Virtual Directory fails, Oracle Process Management and Notification (OPMN) server attempts to restart it.

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

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

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

  • The Oracle WebLogic Server console, Oracle Enterprise Manager Fusion Middleware Control, and Oracle Access Management console are always bound to the listen address of the 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 Access Manager applications deployed to the cluster.

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

2.2.2.4 High Availability Provisions

  • OAM 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 the Administration Server on IDMHOST1 does not start, the Administration Server on the secondary host can be started. If a WebLogic managed server fails, the node manager running on that host attempts to restart it.

2.2.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.2.3 About the Optional Directory Tier

No directory tier is shown in Section 2.1.1, "Deployment Topologies," as this Guide features the use of Oracle Unified Directory, which typically resides in the application tier. If you are using Oracle Internet Directory or Oracle Virtual Directory, however, you might need a directory 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.

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

2.2.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 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. This is most likely to be required in deployments which use Oracle Internet Directory, which requires access to a database for storing its information.

2.3 Hardware Requirements for an Enterprise Deployment

The deployments shown in the topology diagrams use a small number of powerful servers, which makes the deployment simpler. It is, however, not mandatory to use such powerful servers. You can, alternatively, distribute managed servers over a larger number of smaller servers.

If you are planning to deploy on the same number of servers shown in the diagrams, these servers should have the minimum specification shown in Table 2-1.

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

Table 2-1 Typical Hardware Requirements

Server Processor Disk Memory TMP Directory Swap

Database Host IDMDBHOSTn

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

4 or more X Pentium 1.5 GHz or greater

20 GB

16 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 17.4, "Scaling Enterprise Deployments".

Note:

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

2.4 Software Components for an Enterprise Deployment

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

This section contains the following topics:

2.4.1 Software Versions

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

Table 2-2 Software Versions Used

Short Name Product Version

OHS11G

Oracle HTTP Server

11.1.1.6.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.1.0

SOA

Oracle SOA Suite

11.1.1.6.0

WebGate

WebGate 11g

11.1.2.1.0

RCU

Repository Creation Assistant

11.1.2.1.0

OUD

Oracle Unified Directory

11.1.2.1.0

IDM (optional)

Oracle Identity Management

11.1.2.1.0

2.4.2 About Obtaining Software

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

2.4.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-3 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-3 Summary of Homes

Home Name Home Description Products Installed

MW_HOME

Consists of the Oracle WebLogic Server home and, optionally, one or more Oracle homes.

  

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

IDM_ORACLE_HOME

Contains the binary and library files for Oracle Identity Management and is located in: IAM_MW_HOME/idm.

Oracle Internet Directory

Oracle Virtual Directory

Oracle Directory Services Manager

IAM_ORACLE_HOME

Contains the binary and library files required for Oracle Identity and Access Management and is located in IAM_MW_HOME/iam.

Oracle Access Manager

Oracle Identity Management

OUD_ORACLE_HOME

Contains the binary and library files required for Oracle Unified Directory and is located in IAM_MW_HOME/oud

Oracle Unified Directory

WEB_ORACLE_HOME

Contains the binary and library files required for Oracle HTTP Server.

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.Required only when creating topologies with OIM and is located in 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

2.4.4 About Installing Software

You perform software installation using the Oracle Installer, which resides on the installation media. In this guide, you deploy software into different directories, which are described in Chapter 4, "Preparing Storage for an Enterprise Deployment."

The installation tasks you must perform can be summarized as follows:

  • Install OHS onto local storage on hosts in the web tier

  • Install Oracle WebGate onto local storage on hosts in the web tier

  • Install Oracle WebLogic Server onto shared storage available to hosts in the application tier.

  • Install Oracle Identity and Access Management onto shared storage available to hosts in the application tier

  • If you use Oracle Unified Directory, install it onto shared storage available to hosts in the application tier.

  • If you are using Oracle Internet Directory or Oracle Virtual Directory, you install Oracle Identity Management onto hosts in the Data Tier. If you plan to use these products and do not have a highly available directory, you must create one as described in the Oracle Fusion Middleware High Availability Guide. In addition to Oracle Internet Directory or Oracle Virtual Directory, you must also install ODSM for Oracle Internet Directory and Oracle Virtual Directory.

If you are creating a split domain configuration, you must install Oracle Identity Management into two separate locations on the application tier to facilitate independent patching.

Detailed instructions for the installation of the Oracle software are found in the component chapters in this book.

Some products, such as Oracle Internet Directory and Oracle Virtual Directory, require you to run a script that sets the permissions of some files to root.

Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.

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

Caution:

In particular, Patch 16943171 is critical if you are using Oracle Unified Directory in active-active mode, as shown in the topology diagrams. Failure to apply this patch might result in data inconsistency in the event of a failover.

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

2.5 Road Map for the Reference Topology Installation and Configuration

Before beginning your Oracle Identity Management enterprise deployment, review the flow chart in Figure 2-4, "Flow Chart of the Oracle Identity Management Enterprise Deployment Process". This flow chart illustrates the high-level process for completing the enterprise deployment documented in this guide. Table 2-4 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:

2.5.1 Flow Chart of the Oracle Identity Management Enterprise Deployment Process

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

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

Flow chart of the deployment process

2.5.2 Steps in the Oracle Identity Management Enterprise Deployment Process

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

Table 2-4 Steps in the Oracle Identity 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 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, "Preparing the Servers for an Enterprise Deployment"

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 Management schemas for transactional recovery privileges, and back up the database.

Chapter 6, "Preparing the Database for an Enterprise Deployment"

Extend the Domain for Oracle Unified Directory?

Extend the existing WebLogic domain by running the Configuration Wizard to configure Oracle Unified Directory.

Chapter 7, "Installing and Configuring Oracle Unified Directory."

Create a Domain

Run the Configuration Wizard to create the domains (OIMDomain) and include OAM and OIM.

Chapter 8, "Creating a Domain for an Enterprise Deployment"

Prepare Identity and Policy Stores

Prepare the Identity and Policy Stores in an Oracle Identity Management enterprise deployment.

Chapter 9, "Preparing Identity Stores"

Configure the Web Tier

Configure the Oracle Web Tier by associating the Oracle Web tier with the Oracle WebLogic Domain, Configuring Oracle HTTP Server with the load balancer, and configuring virtual host names.

Chapter 10, "Installing and Configuring Oracle Web Tier for an Enterprise Deployment"

Extend the Domain for Oracle Access Management?

Run the Configuration Wizard again and extend the domain to include Oracle Access Management.

Chapter 11, "Extending the Domain to Include Oracle Access Management"

Extend the Domain for Oracle Identity Manager?

Run the Configuration Wizard again and extend the domain to include Oracle Identity Manager.

Chapter 12, "Extending the Domain to Include Oracle Identity Manager"

Set up Node Manager

Set up Node manager by enabling host name verification, starting Node Manager, and configuring WebLogic Servers to use custom keystores.

Chapter 13, "Setting Up Node Manager for an Enterprise Deployment"

Configure Server Migration

Configure server migration for the WLS_OIM1, WLS_SOA1, WLS_OIM2, and WLS_SOA2 Managed Servers. The WLS_OIM1 and WLS_SOA1 Managed Server are configured to restart on IDMHOST2 should a failure occur. The WLS_OIM2 and WLS_SOA2 Managed Servers are configured to restart on IDMHOST1 should a failure occur.

Chapter 14, "Configuring Server Migration for an Enterprise Deployment"

Configure Single Sign-on for Administration Consoles in an Enterprise Deployment

Configure single sign-on (SSO) for administration consoles in an Identity Management Enterprise deployment.

Chapter 15, "Configuring Single Sign-on for Administration Consoles in an Enterprise Deployment"