2 Introduction and Planning

This chapter describes and illustrates the enterprise deployment reference topology described in this guide and helps you plan your deployment.

This chapter contains the following topics:

2.1 Planning Your Deployment

This section provides information to help you plan the deployment of Oracle Identity Management on Exalogic:

2.1.1 Why the Deployment Topology in This Guide?

When planning your deployment, you should be aware that this guide provides detailed instructions for implementing the specific reference topology described in this chapter.

This topology takes advantage of key features of the Exalogic platform, including:

  • The high bandwidth and performance of the Exalogic internal Infiniband (IPoIB) network fabric

  • The software load balancing capabilities of Oracle Traffic Director.

In this specific topology, Oracle Traffic Director is used as both a Web Listener and as a client-side load balancer for internal communication.

In this configuration, you can take advantage of the Exalogic default IPoIB network for all internal communications between the Traffic Director instances and the Identity Management compute nodes.

Only external traffic between the Traffic Director instances and external users is on the Exalogic Ethernet over IB (EoIB) network.

2.1.2 Alternative Deployment Topologies

Besides the topologies discussed in this guide, you can consider alternative Oracle Identity Manager topologies on Exalogic.

This guide does not provide specific instructions for implementing these alternative topologies, but consider the following when you are preparing your environment for an Oracle Identity Manager deployment on Exalogic:

2.1.2.1 Using an External Oracle HTTP Server Web Tier Instead of Oracle Traffic Director

As described in Section 2.1.1, the topology in this guide uses Oracle Traffic Director as both a Web server and an internal load balancer. This configuration requires that you dedicate two compute nodes to hosting the Oracle Traffic Director instances.

If you cannot dedicate two compute nodes for Oracle Traffic Directory, or if you would rather use a dedicated Oracle HTTP Server Web Tier, then it is possible to deploy Oracle HTTP Server on an external Web tier, which is located outside the Exalogic machine.

Refer to Appendix C, "Enterprise Topology with Oracle HTTP Server" for a diagram of a typical Oracle Identity Manager topology on Exalogic with an external Oracle HTTP Server Web tier.

2.1.2.2 Using Oracle Exadata Instead of an Oracle RAC Database

The reference topology in this guide provides information on using an external Real Application Clusters (RAC) database as the repository for product schemas and security stores.

The topology assumes that the RAC database is hosted on dedicated servers. These servers can either be independent or as part of an Oracle Exadata database machine.

If an Oracle Exadata machine is used then this should be connected to the Exalogic machine via the infiniband fabric. For more information, see "Connecting Exalogic and Exadata Machines" in the Oracle Exalogic Elastic Cloud Multi-Rack Cabling Guide.

2.1.3 Using a Worksheet to Plan for the Deployment Topology

The key to a successful Enterprise Deployment is planning and preparation. The road map for installation and configuration in this chapter directs you to the appropriate chapters for the tasks you need to perform.

Use this chapter to help you plan your Oracle Identity Management enterprise deployment on an Exalogic platform.

You can also use Appendix A, "Worksheet for Identity Management Topology" to help you keep track of information, such as host names, IP addresses, and other important information as you procure and identify the machines and resources required for this deployment.

2.2 Understanding the Oracle Identity Management Deployment Topology on Exalogic

Figure 2-1 provides a diagram of a standard, reference topology for Oracle Identity Management on Exalogic.

In this specific topology, the Web tier consists of Oracle Traffic Director instances, and the Exalogic machine is connected to a remote Oracle RAC database over a 10 Gb Ethernet connection.

For a detailed description of the elements of the topology, see Section 2.3, "Understanding the Topology Components".

Figure 2-1 Oracle Identity Management on Exalogic, Deployed with Oracle Traffic Director and an Oracle RAC Database

IDM on Exalogic with Oracle Traffic Director
Description of "Figure 2-1 Oracle Identity Management on Exalogic, Deployed with Oracle Traffic Director and an Oracle RAC Database"

2.3 Understanding the Topology Components

The topologies consist of three tiers, which are described in the following sections:

2.3.1 About EoIB and IPoIB Communication

When you initially set up your Exalogic machine, the default network is running IP over Infiniband (IPoIB). For the different purposes of the topology described in this guide, you must configure Ethernet over Infiniband (EoIB) network access in addition to the IPoIB network. For more information, see "Configuring Ethernet Over InfiniBand" in the Oracle Exalogic Elastic Cloud Machine Owner's Guide.

In an Exalogic deployment the two different types of network are used as follows:

  • IPoIB is used for internal communications for components within the Exalogic machine rack. This network is not visible outside of the Exalogic machine rack itself.

  • EoIB is used for components inside the Exalogic machine rack to communicate with components external to the Exalogic machine rack.

The following four types of communication must be configured for the Oracle Identity and Access Management enterprise deployment on Exalogic:

  • For the Oracle Traffic Director hosts, the IP addresses must be EoIB addresses accessible from the load balancer. The Oracle Traffic Director IP addresses are the only addresses accessible from the DMZ network.

  • For the application tier, the IDMHOST machines IP addresses must be EoIB addresses that can access the Oracle RAC database SCAN and VIP addresses, Additionally, IDM servers use IPoIB address as main listen addresses for internal invocations and for RMI interactions inside the Exalogic rack.

  • Communication and routing between Oracle Traffic Director hosts and the application tier must be only over IPoIB.

  • For communication between the application tier components, for example, internal JMS destinations routing must be on IPoIB. Any front end address that is exposed ONLY for internal consumption, uses and IPoIB virtual IP on Oracle Traffic Director hosts.

  • IDM Servers can also be accessed externally for RMI/JMS/T3 invocations and HTTP invocations. These take place for remote deployments, for external JMS producers and consumers and for other operations that use a listen address of the IDM servers that is available outside the Exalogic rack (EoIB).

For more information about IPoIB and EoIB network configuration, see Chapter 3, "Configuring the Network for an Enterprise Deployment".

2.3.2 About the Load Balancer

In an Exalogic deployment, a hardware load balancer sits outside the Exalogic machine rack. Its function is to receive external requests for the IAM deployment and pass them on to each of the Web hosts. These Web hosts can either be Oracle HTTP Servers or Oracle Traffic Director servers.

The load balancers are configured to receive HTTP and HTTPS requests. If an HTTPS request is received at the load balancer, the SSL is decrypted at the load balancer and passed on to the Web Servers using the HTTP protocol. This is known as SSL Termination at the load balancer.

The communication from the hardware load balancer to the Web tier (WEBHOST1 and WEBHOST2, in this case) is entirely over EoIB.

The load balancer is used to route both application and administrative requests to the Web servers. Administrative requests originate inside the organization's intranet. Application requests may be received through the intranet or the internet.

2.3.3 About the Web Tier

With Exalogic, you can take advantage of Oracle Traffic Director capabilities.

In particular, the architecture of Oracle Traffic Director enables it to handle large volumes of application traffic with low latency. It is optimized for use in Oracle Exalogic Elastic Cloud. It communicates with WebLogic Servers in the back end over Exalogic's InfiniBand fabric (IPoIB).

In this topology, the Oracle Traffic Director instances serve two purposes:

  • They receive HTTP requests coming in from the hardware load balancer (over the EoIB network) and then route those requests (over the IPoIB network) to the compute nodes in the application tier.

  • They route requests from the application tier components (over the IPoIB network) to other application tier components, such as requests from Oracle Access Manager to the Oracle Unified Directory directory service.

    The internal application to application requests, which are routed only over the internal IPoIB network, are routed via a virtual IP address that is depicted as VIP1 in the topology diagram (Figure 2-1).

    The Oracle Traffic Director instances are configured as part of a failover group. In this configuration, Oracle Traffic Director uses an implementation of the Virtual Routing Redundancy Protocol (VRRP) to provide failover capabilities. If an Oracle Traffic Director instance fails, IP addresses enabled on it are migrated to surviving instances, via VRRP.

  • Requests are routed from the Oracle Traffic Director servers to an Oracle WebLogic Server running in the application tier.

  • WebGate uses Oracle Access Protocol (OAP) to communicate with Oracle Access Manager to perform operations such as user authentication.

  • Oracle Traffic Director performs the following actions.

    • Distributes the requests that it receives from clients to servers in the application tier based on the specific load-balancing method

    • Routes the requests based on specified rules

    • Caches frequently accessed data

    • Prioritizes traffic and controls the quality of service

  • Oracle Traffic Director can be used to route HTTP or LDAP requests.

    • Used for internal load balancing (always required).

    • Acts as a Web server

2.3.4 About the DMZ

A DMZ is a means of restricting access to components of your infrastructure to those that actually need it. In the examples in this guide, there is a public DMZ. This is where the outside world gains access to your systems. You place into this zone only those components that the outside world must access, such as the Load Balancers and Web Tiers. If users from the outside world attempts to access any servers or services below this zone, they are prevented from doing so by firewalls. The public zone is configured so that the servers in this zone can interact with the application servers in the private zone.

  • The public zone–This is where the outside world gains access to your systems. You place into this zone only those components that the outside world must access, such as the Load Balancers and Web Tiers. If users from the outside world attempts to access any servers or services below this zone, they are prevented from doing so by firewalls.

    The public zone is configured so that the servers in this zone can interact with the application servers in the private zone.

  • The intranet zone–This is where you place servers that contain core services, such as databases. These services are very tightly controlled by the organization as they contain the most sensitive data.

By using this approach, you restrict access to information to only those components that require it. This approach is useful where you have users coming in from outside of your organization. If, instead of an extranet, you are setting up an intranet, where all communication is from trusted sources, then you might reasonably decide to do away with the public DMZ.

2.3.5 About the Application Tier

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

In the application tier, IDMHOST1 and IDMHOST2 include the following components, which are installed on Managed Servers in the Oracle WebLogic Server domain:

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

  • The administrative components of Identity management, including Oracle Identity Manager, which is used for user provisioning.

  • Oracle SOA Suite (SOA), which is required by Oracle Identity Management for process workflows to manage request approvals.

IDMHOST1 hosts an Oracle WebLogic Administration Server. The Administration Server hosts the Oracle WebLogic Console, Oracle Enterprise Manager Fusion Middleware Control, Oracle Access Management Console, and Oracle Directory Services Manager (ODSM) for OUD.

Note that the Oracle WebLogic Server Administration Server is a singleton process. That is, only one Administration Server can be running at a time within a domain. In the event that the host running the Administration Server fails, the Administration Server can be manually started on a different host.

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

  • 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 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.3.5.2 High Availability Provisions

  • Oracle Traffic Director can be configured for high availability in active-passive mode. Virtual Hosts/IP addresses are started on a single OTD instance. A heart beat exists between each OTD instance. Using this heatbeat, a secondary OTD instance will enable the virtual host/IP address in the event of the failure of the primary OTD instance.

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

  • Oracle Traffic Director directs HTTP and LDAP requests to all WebLogic managed servers or OUD Instances ensuring maximum availability.

  • 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.3.5.3 Security Provisions

The adminitration tools for this deployment (for example, Oracle WebLogic Server Console, Oracle Enterprise Manager Fusion Middleware Control console, and Oracle Access Management Console) are accessible only through a virtual host (admin.mycompany.com) configured on the hardware load balancer, which is only available inside the firewall.

2.3.6 About the Identity Stores

Identity information is stored in an LDAP compliant directory. In this topology, Oracle supports the Oracle Unified Directory natively.

2.4 Hardware Requirements for the Identity Management on Exalogic

The following sections describe the hardware requirements for the Identity Management enterprise topologies on Exalogic:

2.4.1 Hardware Load Balancer Requirements

The Oracle Fusion Middleware enterprise deployment requires a hardware load balancer to route requests to the Web tier. For information about the minimum set of features required for the load balancer in this topology, see Section 3.9.1, "Load Balancer Requirements."

2.4.2 Exalogic Machine Requirements

Exalogic machines consist of virtual or physical machines, a storage appliance, as well as required InfiniBand and Ethernet networking components. The number of these components in each machine varies based on the hardware configuration.

For complete information about the hardware options available for Exalogic machines, see "Exalogic Hardware Configurations" in the Oracle Exalogic Elastic Cloud Machine Owner's Guide.

For any of the topologies described in this guide, an Exalogic machine eighth rack can be used. For more information, see Section 2.2, "Understanding the Oracle Identity Management Deployment Topology on Exalogic".

You can assign the Exalogic machines, as follows:

  • Assign two machines to the Application Tier. These will be referred to as IDMHOST1 and IDMHOST2.

  • If you are using the Oracle Traffic Director topology, assign two additional machines to the Oracle Traffic Director instances. These will be referred to as WEBHOST1 and WEBHOST2.

Note that you can also assign compute nodes for a standard Oracle RAC database, but this guide assumes your database will be hosted on a remote set of hosts.

2.5 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.5.1 Software Required for the Oracle Identity Management Deployment Topology on Exalogic

Table 2-1 lists the Oracle software you need to obtain before starting the procedures in this guide.

Table 2-1 Software Versions Used

Short Name Product Version

OTD

Oracle Traffic Director

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

SOA

Oracle SOA Suite

11.1.1.6.0

WebGate

WebGate 11g

11.1.2.0.0

RCU

Repository Creation Assistant

11.1.2.0.0

OUD

Oracle Unified Directory

11.1.2.0.0

2.5.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.5.3 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 in each patch archive.

2.6 Road Map for the Reference Topology Installation and Configuration

Before beginning your Oracle Identity Management enterprise deployment, review the flow chart in Figure 2-2, "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-2 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.6.1 Flow Chart of the Oracle Identity Management Enterprise Deployment Process

Figure 2-2, "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-2 Flow Chart of the Oracle Identity Management Enterprise Deployment Process

Flow chart of the deployment process

2.6.2 Steps in the Oracle Identity Management Enterprise Deployment Process

Table 2-2 describes each of the steps in the enterprise deployment process flow chart for Oracle Identity 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-2 Steps in the Oracle Identity Management Enterprise Deployment Process

Step Description More Information

Review the Enterprise Deployment Topology

Review the recommended topology and plan the topology best suited for organization and applications.

Section 2.1, "Planning Your Deployment"

Prepare the Network for an 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, "Configuring the Network for an Enterprise Deployment"

Prepare your File Storage Appliance for an 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, "Configuring Storage for an Enterprise Deployment"

Prepare the Compute Nodes 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 multi-homed systems.

Chapter 5, "Configuring the Compute Nodes for an Enterprise Deployment"

Prepare the Oracle RAC Database for an Enterprise Deployment

To prepare an Oracle RAC 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, "Configuring a Database for an Enterprise Deployment"

Install and Configure Oracle Unified Directory

Install and configure Oracle Unified Directory, which is used as the Identity Store in the recommended topologies.

Configure two instances of Oracle Unified Directory by using Oracle Unified Directory configuration assistant.

Chapter 8, "Installing and Configuring Oracle Unified Directory"

Create the Initial WebLogic Server Domain

Run the Configuration Wizard to create the initial WebLogic Server domain.

Chapter 9, "Running the Configuration Wizard to Create a Domain"

Install and Configure Oracle Traffic Director on Exalogic Compute Nodes

Install and configure Oracle Traffic Director.

Chapter 7, "Installing and Configuring Oracle Traffic Director 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"

Configure SSO for the Administration Console

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"

Configure 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"