2 Understanding the IAM Enterprise Deployment

This chapter introduces and describes the Oracle Identity and Access Management deployment topologies on commodity hardware. These topologies represent specific reference implementations of the concepts described in Chapter 1, "Understanding a Typical Enterprise Deployment."

This chapter contains the following topics:

2.1 Understanding the Primary and Build-Your-Own Enterprise Deployment Topologies

This guide focuses on two primary reference topologies for Oracle Identity and Access Management. The components installed into each topology are the same. The difference being that one deployment is concentrated onto a small number of highly specified servers and the second is distributed amongst a larger number of smaller machines.

The exact Oracle Identity and Access Management topology you install and configure for your organization might vary, but for the two primary topologies, this guide provides step-by-step instructions for installing and configuring those topologies. To simplify the installation and configuration process this guide utilizes the IAM deployment wizard, which once you tell it how to layout your topology will automatically configure it for you.

Once you have created your deployment, this guide will show you how to extend it to include additional IAM products, which you may wish to use. The procedures in this book do not cover every IAM product. The steps in this guide can easily be adapted to any other IAM product you may wish to include.

2.2 Diagrams of the Primary Oracle Identity and Access Management Topology

The following sections provide diagrams of the two primary Oracle Identity and Access Management enterprise deployment topologies:

2.2.1 Diagram of Oracle Identity and Access Management on Consolidated Hardware

Figure 2-1 shows a diagram of the four-node topology with Oracle HTTP Server.

In this topology, the software is consolidated on a limited number of hosts: two hosts for the Web tier and two hosts for the application tier. You deploy both Oracle Access Management and Oracle Identity Manager on each application tier host.

This topology is a typical deployment if you are using relatively powerful, physical host computers. For information about the system requirements for each host, see Section 5.1.2, "Host Computer Hardware Requirements".

Figure 2-1 Four-Node Topology with Oracle HTTP Server

Description of Figure 2-1 follows
Description of ''Figure 2-1 Four-Node Topology with Oracle HTTP Server''

2.2.2 Diagram of Oracle Identity and Access Management on Distributed Hardware

Figure 2-2 shows a diagram of the eight-node distributed topology.

In this topology, the software is distributed across eight hosts: two hosts for the Web tier and four hosts for the application tier, and four hosts for the directory services.

This topology is a typical deployment if you are using virtual machines (VMs) that are less powerful, but easy to create and manage. You deploy key components, such as Oracle Access Manager, Oracle Identity Manager, and Directory Services on their own dedicated hosts.

For information about the system requirements for each host, see Section 5.1.2, "Host Computer Hardware Requirements".

Figure 2-2 Eight-Node Distributed Topology

Description of Figure 2-2 follows
Description of ''Figure 2-2 Eight-Node Distributed Topology''

2.3 Understanding the Primary Oracle Identity and Access Management Topology Diagrams

This section describes the Primary Oracle Identity and Access Management Topology diagrams.

This section contains the following topics:

2.3.1 Product Separation

An IAM deployment is made up of a number of components. These components include:

  • Web Servers

  • WebLogic

  • LDAP

  • Database

Figure 2-1 and Figure 2-2 depict a separation between each component. The Oracle Identity and Access Management components are split into two different domains: IAMAccessDomain and IAMGovernanceDomain. Products are distributed as follows:

  • IAMAccessDomain contains Oracle Access Manager, Oracle Mobile Security Suite, Oracle Adaptive Access Manager.

  • IAMGovernanceDomain contains Oracle Identity Manager, Oracle Business Intelligence, Oracle Privileged Account Manger.

This split is due to the different operational and availability requirements demanded of the individual components. Typically components in the IAMAccessDomain have a higher availability requirement than those in the IAMGovernanceDomain. By separating these components out, you can manage the availability requirements differently. You can patch governance components independently of access components, and you can shutdown the governance instance without impacting the access components.

This separation is extended to the Directory tier as well, which is often released at a different time to that of the Web tier and the Application tier components. Separation of the directory provides the same benefits as splitting the domains, for example, Independent upgrade and patching.

A further benefit of this separation is that you can build a topology in a modular fashion. You can start off with a directory and extend it to Access Components, then later extend it to Governance components, without needing to affect the deployed software or configuration of existing components, unless you are wiring them together.

2.3.2 Understanding the Directory Tier

The Directory tier consists of two physical host computers, where an LDAP compliant directory is installed. Typically, this is Oracle Internet Directory (OID) or Oracle Unified Directory (OUD).

The Directory tier is often combined with the Data tier.

This release of the Enterprise Deployment Guide supports three different LDAP directories. You may be creating these directories for the first time, or you may be using existing directories from within the organization. The different directories supported are:

  • Oracle Unified Directory (OUD)

  • Oracle Internet Directory (OID)

  • Microsoft Active Directory (AD)

The directory you choose will be organization dependent.

2.3.3 Understanding Oracle Unified Directory Assured 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.

2.3.4 Summary of Oracle Identity and Access Management Load Balancer Virtual Server Names

In order to balance the load on servers and to provide high availability, a hardware load balancer is required. This hardware load balancer should exist on redundant hardware to ensure maximum availability. The hardware load balancer must be configured to recognize a set of virtual server names.

The hardware load balancer in Oracle Identity and Access Management deployments must recognize the following virtual server names.

  • login.example.com - This virtual server name is used for all incoming Access traffic. It acts as the access point for all HTTP traffic to the runtime Access Management components. The load balancer routes all requests to this virtual server name over SSL. As a result, clients access this service using the following secure address:

    login.example.com:443

  • prov.example.com - This virtual server name is used for all incoming Governance traffic. It acts as the access point for all HTTP traffic to the runtime Governance components. The load balancer routes all requests to this virtual server name over SSL. As a result, clients access this service using the following secure address:

    prov.example.com:443

    Note that, in previous releases of the Enterprise Deployment Guide, login.example.com and prov.example.com were the same entry point. This release allows for them to be separated out. This will enable smarter routing from the load balancer, allow a more modular deployment and will facilitate future Multi-datacenter deployments. If desired these two entry points can still be combined to provide a single point of entry into the IAM deployment.

  • msas.example.com - This virtual server name is used for all incoming Mobile Security traffic. It acts as the access point for all HTTPS traffic to the runtime Mobile Security Access Service. The load balancer routes all requests to this virtual server name over SSL. As a result, clients access this service using the following secure address:

    msas.example.com:9002

  • iadadmin.example.com - This virtual server name is enabled on the load balancer. It acts as the access point for all internal HTTP traffic that gets directed to the administration services in the IAMAccessDomain. The incoming traffic from clients is non-SSL enabled. Therefore, the clients access this service using the following address:

    iadadmin.example.com:80

    This in turn is forwarded to port 7777 on WEBHOST1 and WEBHOST2.

    The services accessed on this virtual host include the WebLogic Administration Server Console and Oracle Enterprise Manager Fusion Middleware Control.

    Create rules in the firewall to block outside traffic from accessing the /console and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the iadadmin.example.com virtual host.

  • igdadmin.example.com - This virtual server name is enabled on the load balancer. It acts as the access point for all internal HTTP traffic that gets directed to the administration services in the IAMGovernanceDomain. The incoming traffic from clients is non-SSL enabled. Therefore, the clients access this service using the following address:

    igdadmin.example.com:80

    This in turn is forwarded to port 7777 on WEBHOST1 and WEBHOST2.

    The services accessed on this virtual host include the WebLogic Administration Server Console and Oracle Enterprise Manager Fusion Middleware Control.

    Create rules in the firewall to block outside traffic from accessing the /console and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the igdadmin.example.com virtual host.

  • iadinternal.example.com - This virtual server name is for internal communications between the application tier components in the Access Domain only and is not exposed to the Internet. The primary use of this virtual server is to allow the Mobile Security Access Service to communicate with either the Oracle HTTP server, which is being used to distribute requests to Oracle Mobile Security Manager, or it can be used to send requests directly to the WebLogic Managed Servers hosting Mobile Security Manager.

    The traffic from clients to this virtual server is not SSL-enabled. Clients access this service using the following address and the requests are forwarded to port 7777 on WEBHOST1 and WEBHOST2:

    iadinternal.example.com:7777

  • igdinternal.example.com - This virtual server name is for internal communications between the application tier components in the Governance Domain only and is not exposed to the Internet. This virtual server is used for both Oracle OIM Suite and Oracle SOA Suite internal communications.

    The traffic from clients to this virtual server is not SSL-enabled. Clients access this service using the following address and the requests are forwarded to port 7777 on WEBHOST1 and WEBHOST2:

    igdinternal.example.com:80

  • idstore.example.com - This virtual server name is used for all incoming identity store traffic. It acts as the access point to the LDAP directory instances. This virtual server is not exposed to the internet.

    The traffic from clients to this virtual server may or may not be SSL-enabled, depending on the type of LDAP directory in use. Typically, this will be non-SSL enabled for Oracle Unified Directory and Oracle Internet Directory and enabled for Microsoft Active Directory. Clients access this service using this virtual server name and the requests are forwarded to the LDAP instances.

2.3.5 Summary of the Managed Servers and Clusters on the Application Tier Hosts

The Application tier hosts the Administration Server and Managed Servers in the Oracle WebLogic Server domains.

Depending upon the components you select, the Oracle WebLogic Server domain for the Oracle Identity and Access Management consists of the clusters shown in Table 2-1. These clusters function as active-active high availability configurations.

Table 2-1 Domain Clusters and Managed Servers

Domain Cluster Managed Servers

IAMAccessDomain

Oracle Access Manager

wls_oam1, wls_oam2
 

Oracle Policy Manager

wls_ama1, wls_ama2
 

Oracle Mobile Security Manager

wls_msm1, wls_msm2

IAMGovernanceDomain

Oracle Identity Manager

wls_oim1, wls_oim2
 

Oracle SOA Suite

wls_soa1, wls_soa2
 

Oracle Business Intelligence

wls_bi1, wls_bi2

2.3.6 Understanding Mobile Security Access Server

The Mobile Security Access Server is used to serve requests from Mobile Security clients.

Mobile clients access the load balancer using the HTTPS protocol. The load balancer then forwards those requests to the Mobile Security Access server using HTTPS. The Mobile Security Server then interacts with the Oracle Mobile Security Managed Servers through the Oracle HTTP Server. These requests are sent using HTTP.

Figure 1-1, "Typical Enterprise Deployment Topology Diagram" shows these requests going through the main Oracle HTTP servers. It is possible to increase performance by directing the request to dedicated Oracle HTTP Servers (which do not have Web gate configured), or alternatively, to the Mobile Security managed servers directly through another load balancer.

  • MSAS can continue to operate while MSM is down. This is known as the disconnected mode of operation. In this mode – MSAS will not pull any management/artifact changes done via the UI or WLST in MSM – but will continue to enforce security.

    Note:

    MSAS needs MSM to be up and running when configMSAS is run to create an instance. Therefore, MSAS must connect at least once to MSM.

  • MSAS has a persistent local file-based cache. So MSAS can be taken down and brought back up and should continue to operate.

  • There are number of message exchanges through Secure Mobile Container and MSAS during authentication (KINIT/PKINIT/OAuth). The end result of the authentication process is the creation of a Session Token (STOKEN). The load balancer session must be sticky during the authentication process (usually 1 SSL connection), but not for subsequent requests.

    MSAS has dedicated authentication urls and so we will need to configure the MSAS authentication urls to be sticky.

    Note:

    If the load balancer is not sticky during the authentication process – there is no guarantee that authentication will succeed.

  • There is a session synchronization through MSAS physical instances. So if the STOKEN (Session Token) is created by MSAS instance running on Host 1 initially, and subsequent load balancing results in the mobile traffic being routed to Host 2, the MSAS instance running on Host 2 automatically connects to Host 1 for the STOKEN.

    Note:

    Since Host 2 needs to connect to Host#1 at-least once (if the original STOKEN was created by Host 1), Host 1 must be up and running at that time. However once Host 2 has connected with Host 1, Host 1 can fail.

    In ability to perform session sync results in having to log in again. The session synchronization using multiple MSAS physical instances happens over HTTP(S).

  • Some of the authentication scenarios require one-way SSL, or two-way SSL using the Mobile Secure Container and MSAS. As long as the MSAS physical instances are configured with the same MSAS Instance ID (a single logical instance), MSAS ensures the SSL certificates and keys, are replicated automatically to all the physical instances.

  • MSAS supports automatic recovery from failures at the MSAS physical instance level. When you create and run an MSAS instance (physical), it starts a heartbeat process that is created and runs in the background. This heartbeat process is local to the instance and monitors/pings the MSAS instance to check if it is alive. If not, it tries to restart the MSAS instance. The number of attempts to restart the MSAS instance, is configurable. The heartbeat process uses UDP to ping MSAS.

2.4 Using the Identity and Access Management Deployment Wizard

This guide makes use of the new Identity and Access Management Deployment Tool. It is also possible to create the deployment manually. The benefits of using the deployment tool are:

  • Simplified wizard driven deployment.

  • EDG Best practices incorporated into the tool.

  • Faster more reliable deployment of the Enterprise Deployment topology.

  • Access to post deployment life cycle management tools such as simpler patch application.

The deployment tool does not build all deployments but it speeds up the building of those parts of the deployment it does address. Extending the deployment beyond the products included in the deployment tool is still a manual task, which is covered by this guide.

2.5 Roadmap for Implementing the Primary IAM Suite Topologies

Table 2-2 provides a roadmap for implementing the primary IAM suite topologies on commodity hardware.

Table 2-2 Roadmap for Implementing Primary IAM Suite Topologies on Commodity Hardware

Scenario Tasks For More Information, See

Creating an IAM Enterprise Deployment manually on commodity hardware

Understand a typical enterprise deployment and review the primary deployment topologies.

Chapter 1, "Understanding a Typical Enterprise Deployment"

Section 2.2, "Diagrams of the Primary Oracle Identity and Access Management Topology"

Section 2.3, "Understanding the Primary Oracle Identity and Access Management Topology Diagrams"

Review the hardware and software requirements and procure the resources for the enterprise deployment.

Chapter 5, "Procuring Resources for an Enterprise Deployment"

Prepare the load balancers and firewalls.

Chapter 6, "Preparing the Load Balancer and Firewalls for an Enterprise Deployment"

Prepare the storage and understand the directory structure.

Chapter 7, "Preparing Storage for an Enterprise Deployment"

Configure the host computers.

Chapter 9, "Configuring the Host Computers for an Enterprise Deployment"

Prepare the database.

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

Install the required softwares.

Chapter 11, "Installing Oracle Fusion Middleware in Preparation for an Enterprise Deployment"

Configure Oracle LDAP.

Chapter 12, "Configuring Oracle LDAP for an Identity and Access Manager Enterprise Deployment"

Prepare the identity store.

Chapter 13, "Preparing The Identity Store"

Configure the Oracle Web Tier.

Chapter 14, "Configuring the Oracle Web Tier"

Create the WebLogic domains.

Chapter 15, "Creating Domains for an Enterprise Deployment"

Set up the Node Manager.

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

Configure Oracle Access Management (OAM).

Chapter 17, "Configuring Oracle Access Management"

Configure Oracle Mobile Security Services (OMSS).

Chapter 18, "Configuring Oracle Mobile Security Services"

Configure Oracle Identity Manager (OIM).

Chapter 19, "Configuring Oracle Identity Manager"

Configure Oracle BI Publisher (BIP).

Chapter 20, "Configuring BI Publisher"

Configure server migration settings.

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

Configure Single Sign-On (SSO).

Chapter 22, "Configuring Single Sign-On"
     

Creating an IAM Enterprise Deployment using Life Cycle Management Tools (IDMLCM), on commodity hardware

Understand the automated deployment process.

Chapter 23, "Introduction to the Life Cycle Management (LCM) Tools"

Install the Oracle Identity and Access Management Life Cycle Management Tools.

Chapter 24, "Installing Oracle Identity and Access Management Life Cycle Management Tools"

Create a deployment response file for the topology you are deploying.

Chapter 25, "Creating a Deployment Response File"

Deploy Identity and Access Management.

Chapter 26, "Deploying Identity and Access Management"

Perform the required post-deployment tasks.

Chapter 27, "Performing Post-Deployment Configuration"

2.6 Building your Own Oracle Identity and Access Management Topology

This document provides step-by-step instructions for configuring the two primary enterprise topologies for Oracle Identity and Access Management.

However, Oracle recognizes that the requirements of your organization may vary, depending on the specific set of Oracle Fusion Middleware products you purchase and the specific types of applications you deploy.

In many cases, you can install and configure an alternative topology--one that includes additional components, or one that does not include all the Oracle SOA Suite products shown in the primary topology diagrams.

The following sections describe some alternative Oracle Identity and Access Management topologies you can implement, using some variations of the instructions in this guide. For more information, refer to the resources available on the Oracle Maximum Availability Architecture (MAA) Web site.

  • OAM Only with an Existing Directory

  • OAM Only with OAAM

  • OIM Only with an Existing Directory

  • OIM Only with OPAM

  • OAM/OIM Integrated in a Modular Deployment

  • OAM/OIM Integrated with an Existing Directory

  • OAM/OIM with OAAM

  • OAM/OIM with OPAM

2.7 About Using Server Migration to Enable High Availability of the Oracle Identity and Access Management Enterprise Topology

To ensure high availability of the Oracle Identity and Access Management Suite products and components, this guide recommends that you enable Oracle WebLogic Server Whole Server Migration for the Oracle Identity Manager, Oracle SOA Suite, and Oracle Business Intelligence clusters that you create as part of the reference topology.

Whole server migration provides for the automatic restart of a server instance, with all of its services, on a different physical machine. When a failure occurs in a server that is part of a cluster that is configured with server migration, the server is restarted on any of the other machines that host members of the cluster.

For more information, see Chapter 21, "Configuring Server Migration for an Enterprise Deployment."