Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management
11g Release 1 (11.1.1.5)

Part Number E12035-10
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

1 Enterprise Deployment Overview

Oracle Identity Management presents a comprehensive suite of products for all aspects of identity management.This guide describes four reference enterprise topologies for the Oracle Identity Management Infrastructure components of Oracle Fusion Middleware. It also provides detailed instructions and recommendations to create the topologies by following the enterprise deployment guidelines.

This chapter includes the following topics:

1.1 What is an Enterprise Deployment?

An enterprise deployment is an Oracle best practices blueprint based on proven Oracle high-availability technologies and recommendations for Oracle Fusion Middleware. The high-availability best practices described in this book make up one of several components of high-availability best practices for all Oracle products across the entire technology stack—Oracle Database, Oracle Fusion Middleware, Oracle Applications, Oracle Collaboration Suite, and Oracle Grid Control.

An Oracle Fusion Middleware enterprise deployment:

For more information on high availability practices, visit:

http://www.oracle.com/technetwork/database/features/availability/maa-090890.html

1.2 Terminology

Table 1-1 provides definitions for some terms that define the architecture of an Oracle Fusion Middleware environment:

Table 1-1 Oracle Fusion Middleware Architecture Terminology

Term Definition

Oracle Fusion Middleware home

A Middleware home consists of the Oracle WebLogic Server home, and, optionally, one or more Oracle homes.

A Middleware home can reside on a local file system or on a remote shared disk that is accessible through NFS.

WebLogic Server home

A WebLogic Server home contains installed files necessary to host a WebLogic Server. The WebLogic Server home directory is a peer of other Oracle home directories underneath the Middleware home directory.

Oracle home

An Oracle home contains installed files necessary to host a specific product. For example, the Oracle Identity Management Oracle home contains a directory that contains binary and library files for Oracle Identity Management.

An Oracle home resides within the directory structure of the Middleware home. Each Oracle home can be associated with multiple Oracle instances or Oracle WebLogic Server domains.

Oracle instance

An Oracle instance contains one or more system components, such as Oracle Web Cache, Oracle HTTP Server, or Oracle Internet Directory. The system components in an Oracle instance must reside on the same machine. An Oracle instance directory contains updatable files, such as configuration files, log files, and temporary files.

An Oracle instance is a peer of an Oracle WebLogic Server domain. Both contain specific configurations outside of their Oracle homes.

The directory structure of an Oracle instance is separate from the directory structure of the Oracle home. It can reside anywhere; it need not be within the Middleware home directory.

Oracle WebLogic Server domain

A WebLogic Server domain is a logically related group of Java components. A WebLogic Server domain includes a special WebLogic Server instance called the Administration Server, which is the central point from which you configure and manage all resources in the domain. Usually, you configure a domain to include additional WebLogic Server instances called Managed Servers. You deploy Java components, such as Web applications, EJBs, and Web services, and other resources to the Managed Servers and use the Administration Server for configuration and management purposes only.

Managed Servers in a WebLogic Server domain can be grouped together into a cluster.

An Oracle WebLogic Server domain is a peer of an Oracle instance. Both contain specific configurations outside of their Oracle homes.

The directory structure of an WebLogic Server domain is separate from the directory structure of the WebLogic Server home. It can reside anywhere; it need not be within the Middleware home directory.

system component

A system component is a manageable process that is not WebLogic Server. For example: Oracle HTTP Server, WebCache, and Oracle Internet Directory. Includes the JSE component.

Java component

A Java component is a peer of a system component, but is managed by the application server container. Generally refers to a collection of applications and resources, with generally a 1:1 relationship with a domain extension template. For example: SOA and WebCenter Spaces.

Oracle Fusion Middleware farm

Oracle Enterprise Manager Fusion Middleware Control is a Web browser-based, graphical user interface that you can use to monitor and administer an Oracle Fusion Middleware farm.

An Oracle Fusion Middleware farm is a collection of components managed by Fusion Middleware Control. It can contain WebLogic Server domains, one or more Managed Servers and the Oracle Fusion Middleware system components that are installed, configured, and running in the domain.

Active/Active

This indicates that the application is available on more than one node simultaneously. Accessing the application on either node has the same outcome.

Active/Passive

This indicates that an application is available on only one node at a time. If that node fails, the application must be restarted on another node before service can be resumed.


1.3 Benefits of Oracle Recommendations

The Oracle Fusion Middleware configurations discussed in this guide are designed to ensure security of all transactions, maximize hardware resources, and provide a reliable, standards-compliant system for enterprise computing with a variety of applications. The security and high availability benefits of the Oracle Fusion Middleware configurations are realized through isolation in firewall zones and replication of software components.

This section contains the following topics:

1.3.1 Built-in Security

The Enterprise Deployment architectures are secure because every functional group of software components is isolated in its own DMZ, and all traffic is restricted by protocol and port. The following characteristics ensure security at all needed levels, as well as a high level of standards compliance:

  • All external communication received on port 80 is redirected to port 443.

  • External communication uses the Secure Socket Layer (SSL) secure Web Protocol. This is terminated at the site's load balancer.

  • Communication from external clients does not go beyond the Load Balancing Router level.

  • No direct communication from the Load Balancing Router to the data tier DMZ is allowed.

  • Components are separated between DMZs on the web tier, application tier, and the directory tier.

  • Direct communication across two firewalls at any one time is prohibited.

  • If a communication begins in one firewall zone, it must end in the next firewall zone.

  • Oracle Internet Directory is isolated in the directory tier DMZ.

  • Identity Management components are in the application tier DMZ.

  • All communication between components across DMZs is restricted by port and protocol, according to firewall rules.

1.3.2 High Availability

The Enterprise Deployment architectures are highly available, because each component or functional group of software components is replicated on a different computer, and configured for component-level high availability.

1.4 The Enterprise Deployment Reference Topologies

Oracle Identity Management consists of a number of products, which can be used either individually or collectively. The Enterprise Deployment Guide for Identity Management enables you to build four different enterprise topologies. This section provides diagrams of the topologies.

See Also:

Oracle Fusion Applications system requirements and supported platforms documentation.

1.4.1 Oracle Access Manager 11g

Figure 1-1 is a diagram of the Oracle Access Manager 11g topology.

Figure 1-1 Oracle Access Manager 11g

Surrounding text describes Figure 1-1 .

1.4.2 Oracle Access Manager 11g and Oracle Identity Manager 11g

Figure 1-2 is a diagram of the Oracle Access Manager 11g and Oracle Identity Manager 11g topology.

Figure 1-2 Oracle Access Manager 11g and Oracle Identity Manager 11g

Surrounding text describes Figure 1-2 .

1.4.3 Oracle Adaptive Access Manager 11g

Figure 1-3 is a diagram of the Oracle Adaptive Access Manager 11g topology.

Figure 1-3 Oracle Adaptive Access Manager 11g

Surrounding text describes Figure 1-3 .

1.4.4 Oracle Identity Federation 11g

Figure 1-4 is a diagram of the Oracle Identity Federation 11g topology.

Figure 1-4 Oracle Identity Federation 11g Topology

Surrounding text describes Figure 1-4 .

1.5 Understanding the Topology Tiers

The topologies contain three product tiers. This section describes them.

This section contains the following topics:

1.5.1 Understanding the Directory Tier

The directory tier is in the Intranet Zone. The directory tier is the deployment tier where all the LDAP services reside. This tier includes products such as Oracle Internet Directory and Oracle Virtual Directory. The directory tier is managed by directory administrators providing enterprise LDAP service support.The directory tier is closely tied with the data tier. Access to the data tier is important 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.

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.

Typically protected by firewalls, applications above the directory tier access LDAP services through a designated LDAP host port. The standard LDAP port is 389 for the non-SSL port and 636 for the SSL port. LDAP services are often used for white pages lookup by clients such as email clients in the intranet.

The directory tier stores two types of information:

  • Identity Information: Information about users and groups

  • Oracle Platform Security Services (OPSS): Information about security policies and about configuration.

You must always store policy information in Oracle Internet Directory. You may store identity information in Oracle Internet Directory or in another directory such as Microsoft Active Directory.

If you store the Identity details in a non-OID 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 non-OID directory to Oracle Internet Directory.

A split directory configuration is one where identity data is stored in multiple directories, possibly in different locations. Use this kind of deployment when you do not want to modify the existing Identity Store by extending the schema. In that case, deploy a new Oracle Internet Directory or ODSEE instance to store the extended attributes. Alternatively, you can use the Oracle Internet Directory instance deployed for Policy Store for this purpose. In this scenario, use Oracle Virtual Directory to present all the identity data in a single consolidated view that Oracle Identity Management components can interpret.

See Also:

"Configuring an Identity Store with Multiple Directories" in Oracle Fusion Middleware Integration Overview for Oracle Identity Management Suite for information about configuring Oracle Virtual Directory in a split directory environment.

Although you can use a single Oracle Internet Directory instance for storing both the identity and policy information, in some cases it might be required that you use two separate Oracle Internet Directory installations - one for the Policy Store and another for Identity Store. Examples include the following scenarios:

  • The throughput or enterprise directory requirements dictate separating out the two stores

If you intend to separate your identity and policy information, you must create two separate clusters of highly available Oracle Internet Directory. These Oracle Internet Directory clusters can share the same machines but they should use separate Real Application Clusters databases as their data store.

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

This guide assumes that you are creating two virtual names: one for your Policy Store (policystore.mycompany.com) and one for your Identity Store (idstore.mycompany.com). When using a single Oracle Internet Directory for both your identity and policy information, you can either create two virtual host names, both pointing to the same directory, or combine them into a single suitable virtual host name in the load balancer.

1.5.2 Understanding 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 Identity Federation, 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:

  • In some cases, 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 have the WebLogic Server with the Administration Console, Oracle Enterprise Manager Fusion Middleware Control, Oracle Directory Integration Platform, Oracle Directory Services Manager and Oracle Access Management Server installed. IDMHOST1 and IDMHOST2 run both the WebLogic Server Administration Servers and Managed Servers. Note that the Administration Server is configured to be active-passive, that is, although it is installed on both nodes, only one instance is active at any time. If the active instance goes down, then the passive instance starts up and becomes the active instance.

    The Oracle Access Management Server communicates with the directory tier to verify user information.

  • On the firewall protecting the application tier, the HTTP ports, and OAP port are open. The OAP (Oracle Access Protocol) port is for the WebGate module running in Oracle HTTP Server in the web tier to communicate with Oracle Access Manager to perform operations such as user authentication.

  • In the OAM and OIM topology, OIMHOST1 and OIMHOST2 have Oracle Identity Manager and Oracle SOA installed. Oracle Identity Manager is user provisioning application. Oracle SOA deployed in this topology is exclusively used for providing workflow functionality for Oracle Identity Manager.

  • In the OAAM topology, OAAMHOST1 and OAAMHOST2 have the WebLogic Server with the Oracle Adaptive Access Manager Server and Console installed.

  • OIFHOST1 and OIFHOST2 have the WebLogic Server with Oracle Identity Federation installed.

1.5.2.1 Architecture Notes

  • Oracle Enterprise Manager Fusion Middleware Control is integrated with Oracle Access Manager using the Oracle Platform Security Services (OPSS) agent.

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

  • The 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 WLS_ODS1 Managed Server on IDMHOST1 and WLS_ODS2 Managed Server on IDMHOST2 are in a cluster and the Oracle Directory Services Manager and Oracle Directory Integration Platform applications are targeted to the cluster.

  • The WLS_OAM1 Managed Server on IDMHOST1 and WLS_OAM2 Managed Server on IDMHOST2 are in a cluster and the Access Manager applications are targeted to the cluster.

  • Oracle Directory Services Manager and Oracle Directory Integration Platform are bound to the listen addresses of the WLS_ODS1 and WLS_ODS2 Managed Servers. By default, the listen address for these Managed Servers is set to IDMHOST1 and IDMHOST2 respectively.

  • In the OAM + OIM topology, the WLS_OIM1 Managed Server on OIMHOST1 and WLS_OIM2 Managed Server on OIMHOST2 are in a cluster and the Oracle Identity Manager applications are targeted to the cluster.

  • In the OAM + OIM topology, the WLS_SOA1 Managed Server on OIMHOST1 and WLS_SOA2 Managed Server on OIMHOST2 are in a cluster and the Oracle SOA applications are targeted to the cluster

  • In the OAAM topology, the WLS_OAAM1 Managed Server on OAAMHOST1 and WLS_OAAM2 Managed Server on OAAMHOST2 are in a cluster and the Oracle Adaptive Access server applications are targeted to the cluster.

  • In the OAAM topology, the WLS_OAAM_ADMIN1 Managed Server on OAAMHOST1 and WLS_OAAM_ADMIN2 Managed Server on OAAMHOST2 are in a cluster and the Oracle Adaptive Access Administration console applications are targeted to the cluster.

  • The WLS_OIF1 Managed Server on OIFHOST1 and WLS_OIF2 Managed Server on OIFHOST2 are in a cluster and the Oracle Identity Federation applications are targeted to the cluster.

1.5.2.2 High Availability Provisions

  • The Oracle Access Manager Servers are active-active deployments.

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

  • In the OAAM topology, the Oracle Adaptive Access Servers are active-active deployments; they might 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).

  • The Identity Federation Servers are active-active deployments; the Oracle Identity Federation Server may communicate with the data tier at run time.

  • The WebLogic Administration Server is a singleton component deployed in an active-passive configuration. If IDMHOST1 fails or the Administration Server on IDMHOST1 does not start, the Administration Server on IDMHOST2 can be started. All Managed Servers and components on IDMHOST1 and IDMHOST2 must be configured with the Administration Server virtual IP address.

1.5.2.3 Security Provisions

Oracle WebLogic Server Console, Oracle Enterprise Manager Fusion Middleware Control console, and Oracle Access Manager console are only accessible through admin.mycompany.com, which is only available inside the firewall.

1.5.3 Understanding 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 Oracle 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 Oracle 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 Manager component) in Oracle HTTP Server uses Oracle Access Protocol (OAP) to communicate with Oracle Access Manager running on IDMHOST1 and IDMHOST2, in the Identity Management DMZ. WebGate and Oracle Access Manager are used to perform operations such as user authentication.

On the firewall protecting the web tier, only the HTTP ports are open: 443 for HTTPS and 80 for HTTP.

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

1.5.3.2 Security Provisions

The Oracle HTTP Servers process requests received using the URL's sso.mycompany.com and admin.mycompany.com. The nameadmin.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.

1.6 Using This Guide

Follow these steps to install the software and extend your domain with the components required in your environment.

  1. Read the current chapter, Chapter 1, "Enterprise Deployment Overview."

  2. Ensure that you have performed all prerequisite steps, as described in Chapter 2, "Prerequisites for Enterprise Deployments."

  3. Configure the database repository, as described in Chapter 3, "Configuring the Database Repositories."

  4. Install the software, as described in Chapter 4, "Installing the Software."

  5. Configure the Web Tier, as described in Chapter 5, "Configuring the Web Tier."

  6. Create the WebLogic domain, as described in Chapter 6, "Creating the WebLogic Server Domain for Identity Management."

  7. Extend the domain with Oracle Internet Directory, as described in Chapter 7, "Extending the Domain with Oracle Internet Directory."

  8. Extend the domain with Oracle Directory Integration Platform (optional) and ODSM, as described in Chapter 8, "Extending the Domain with Oracle Directory Integration Platform and ODSM."

  9. If you intend to store your identity data in a directory other than Oracle Internet Directory or in a split directory, perform the procedures described in Chapter 9, "Extending the Domain with Oracle Virtual Directory" and in "Configuring an Identity Store with Multiple Directories" in Oracle Fusion Middleware Integration Overview for Oracle Identity Management Suite.

    If your Identity Store includes only Oracle Internet Directory, skip this step.

  10. Prepare the Identity and Policy Stores. See Chapter 10, "Preparing Identity and Policy Stores."

  11. If you are using Oracle Access Manager, follow the steps in Section 1, "Enterprise Deployment Overview." Otherwise, ignore this step.

  12. If you are using Oracle Adaptive Access Manager, follow the steps in Section 12, "Extending the Domain with Oracle Adaptive Access Manager." Otherwise, skip this step.

  13. If you are using Oracle Identity Navigator, follow the steps in Section 13, "Extending the Domain with Oracle Identity Navigator." Otherwise, skip this step.

  14. If you are using Oracle Identity Manager, follow the steps in Section 11, "Extending the Domain with Oracle Access Manager 11g" and in Section 17, "Configuring Server Migration for Oracle Identity Manager." Otherwise, skip this step.

  15. If you are using Oracle Identity Federation, follow the steps in Section 15, "Extending the Domain with Oracle Identity Federation." Otherwise, skip this step.

  16. Set up Node Manager. See Section 16, "Setting Up Node Manager."

  17. Integrate components as described in Section 18, "Integrating Components."

  18. Configure single sign-on for administration modules. See Section 19, "Configuring Single Sign-on for Administration Consoles."