3 About 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 About a Typical Enterprise Deployment.

This chapter contains the following topics:

• Understanding the Primary and Build-Your-Own Enterprise Deployment Topologies
  
• Diagram of Oracle Identity and Access Management on Distributed Hardware
  
• About the Primary Oracle Identity and Access Management Topology Diagrams
  
• About the Forgotten Password Functionality
  
• Integrating OIG, OAM and LDAP
  
• Roadmap for Implementing the Primary IAM Suite Topologies
  
• Building your Own Oracle Identity and Access Management Topology
  
• About Using Service or Server Migration to Enable High Availability of the Enterprise Topology
  

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.

Diagram of Oracle Identity and Access Management on Distributed Hardware

The sample topology in this section shows 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 two 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 Management, Oracle Identity Governance, and Directory Services on their own dedicated hosts.

The following illustration shows the Oracle Identity and Access Management topology. The diagram is shown with complete separation of components. If you wish to use less hardware, then you can collocate the components as required. For information about the system requirements for each host, see Host Computer Hardware Requirements.

Figure 3-1 Oracle Identity and Access Management Topology

Description of "Figure 3-1 Oracle Identity and Access Management Topology"

About 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:

• Product Separation
  
• Understanding the Directory Tier
  
• Understanding Oracle Unified Directory Assured Replication
  
• Summary of Oracle Identity and Access Management Load Balancer Virtual Server Names
  
• Summary of the Managed Servers and Clusters on the Application Tier Hosts
  

Product Separation

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

• Web Servers

• WebLogic Application Servers

• LDAP

• Database

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 Management (OAM).

• IAMGovernanceDomain contains Oracle Identity Governance.

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.

Understanding the Directory Tier

The Directory tier consists of two or more physical host computers, where an LDAP compliant directory is installed. Typically, this is 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 this directory for the first time, or you may be using existing directory from within the organization. The Oracle Unified Directory (OUD) directory is supported.

The directory you choose will be organization dependent.

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.

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.

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

• 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:7777

• 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. Clients access this service using this virtual server name and the requests are forwarded to the LDAP instances.

• oam.example.com:5575 — This is an additional load balancer virtual host used in multi datacenter deployments only. This virtual host routes requests to the Oracle Access Management (OAM) proxy port on the OAM Managed servers. For example, 5575.

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 3-1. These clusters function as active-active high availability configurations.

Table 3-1 Domain Clusters and Managed Servers

Domain	Cluster	Managed Servers
IAMAccessDomain	Oracle Access Manager	WLS_OAM1, WLS_OAM2
NA	Oracle Policy Manager	WLS_AMA1, WLS_AMA2
IAMGovernanceDomain	Oracle Identity Governance	WLS_OIM1, WLS_OIM2
NA	Oracle SOA Suite	WLS_SOA1, WLS_SOA2
NA	Oracle Web Services Manager	WLS_WSM1, WLS_WSM2

About the Forgotten Password Functionality

When a user is created in the system, a mechanism has to exist which allows their password to be reset. In Oracle 11g, this was provided by Oracle Identity Governance. In Oracle 12c, you have two possibilities:

• Oracle Access Management (OAM) and Oracle Identity Governance (OIG) integration:

  In this scenario, when the users first log on, they are allowed to set a number of challenge questions stored in OIG. If the user forgets their password, if they are able to successfully answer their challenge questions, they will be given the facility to reset their password via OIG.

• Oracle Access Management:

  In this scenario, OAM is wired to the Oracle User Messaging service. Each user has associated with them either a telephone number and or an email address. When the user requests a forgotten password link, they are sent a one time PIN which they can enter into the application that allows the password to be reset.

This guide describes how to set up both the scenarios.

Integrating OIG, OAM and LDAP

In previous releases of Oracle Identity Manager integration with LDAP directories occurred using a process called LDAPSync, this was enabled during configuration of Oracle Identity Manager. Oracle Identity Manager 12c onwards LDAP sync has been deprecated in favour of the LDAP connector.

The LDAP connector is enhanced in Oracle 12c to provide integration with LDAP directories and with Oracle Access Manager. The functionality which was previously enabled as part of OAM/OIM integration has been incorporated into the LDAP connector.

Ability to terminate user sessions upon disablement or termination of a User.

In order to obtain this functionality, download the following version of the LDAP connector (12.2.1.3),

This section describes how to obtain, install and configure the Oracle Connector for LDAP.

About the Oracle Connector

The LDAP connector is implemented by using the Identity Connector Framework (ICF). The ICF is a component that provides basic reconciliation and provisioning operations that are common to all Oracle Identity Manager connectors. The ICF is shipped along with Oracle Identity Manager. Therefore, you need not configure or modify the ICF.

The LDAP connector uses JNDI to access the target system. This connector can be configured to run in one of the following modes:

• Identity reconciliation: Identity reconciliation is also known as authoritative or trusted source reconciliation. In this form of reconciliation, OIM Users are created or updated corresponding to the creation of and updates to users on the target system. Note that the identity reconciliation mode supports reconciliation of user objects only.

• Account Management: Account management is also known as target resource management. This mode of the connector enables provisioning and Target resource reconciliation.

Provisioning

Provisioning involves creating, updating, or deleting users, groups, roles, and organizational units (OUs) on the target system through Oracle Identity Manager.

When you allocate (or provision) a target system resource to an OIM user, the operation results in the creation of an account on the target system for that user. In the Oracle Identity Manager context, the term provisioning is also used to mean updates (for example enabling or disabling) made to the target system account through Oracle Identity Manager.

Users and organizations are organized in a hierarchical format on the target system. Before you can provision users to (that is, create users in) the required organizational units (OUs) on the target system, you must fetch into Oracle Identity Manager the list of OUs used on the target system. This is achieved by using the LDAP Connector OU Lookup Reconciliation scheduled job for lookup synchronization.

Similarly, before you can provision users to the required groups or roles on the target system, you must fetch into Oracle Identity Manager the list of all groups and roles used on the target system. This is achieved by using the LDAP Connector Group Lookup Reconciliation and LDAP Connector Role Lookup Recon scheduled jobs for lookup synchronization.

Target resource reconciliation

To perform target resource reconciliation, the LDAP Connector User Search Reconciliation or LDAP Connector User Sync Reconciliation scheduled jobs is used. The connector applies filters to locate users to be reconciled from the target system and then fetches the attribute values of these users.

Depending on the data that you want to reconcile, you use different scheduled jobs. For example, you use the LDAP Connector User Search Reconciliation scheduled job to reconcile user data in the target resource mode.

You can deploy the Oracle LDAP connector either locally in Oracle Identity Manager or remotely in the Connector Server. A Connector Server enables remote execution of an Identity Connector. The Enterprise Deployment Guide shows the steps to install and configure the connector locally in Oracle Identity Manager.

Roadmap for Implementing the Primary IAM Suite Topologies

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

Table 3-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.	Enterprise Deployment Overview About a Typical Enterprise Deployment About the IAM Enterprise Deployment About the IAM Exalogic Enterprise Deployment About a Multi-Data Center Deployment
	Review the hardware and software requirements and procure the resources for the enterprise deployment.	Procuring Resources for an Enterprise Deployment
	Prepare the load balancers and firewalls.	Preparing the Load Balancer and Firewalls for an Enterprise Deployment
	Prepare the storage and understand the directory structure.	Preparing the File System for an Enterprise Deployment
	Configure the host computers.	Preparing the Host Computers for an Enterprise Deployment
	Prepare the database.	Preparing the Database for an Enterprise Deployment
	Configure Oracle LDAP.	Configuring Oracle LDAP for an Enterprise Deployment
	Create the Oracle Fusion Middleware Infrastructure for Oracle Access Management.	Creating Infrastructure for Oracle Access Management
	Create the Oracle Fusion Middleware Infrastructure for Oracle Identity Governance.	Creating Infrastructure for Oracle Identity Governance
	Configure Oracle HTTP Server or Configure Oracle Traffic Director.	Configuring Oracle HTTP Server for an Enterprise Deployment Configuring Oracle Traffic Director for an Enterprise Deployment
	Configure Oracle Access Management (OAM).	Configuring Oracle Access Management
	Configure Oracle Identity Governance (OIG) or (OIM).	Configuring Oracle Identity Governance
	Configure server migration settings.	Using Whole Server Migration and Service Migration in an Enterprise Deployment
	Configure Single Sign-On (SSO).	Configuring Single Sign-On for an Enterprise Deployment

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, which are described in Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies.

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 Identity and Access Management 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:

• OAM Only with an Existing Directory

• OIM Only with an Existing Directory

• OAM/OIM Integrated in a Modular Deployment

• OAM/OIM Integrated with an Existing Directory

Note:

The deployment can be extended with Oracle Adaptive Access Manager or Oracle Privileged Account Manager. See the MAA Web site for details.

Note:

if you decide to deploy a custom environment that varies from the ones provided in this guide, then you typically deploy Oracle Identity and Access Management manually. The Life Cycle Management (LCM) Tools provided to automate the installation and deployment do not support all the alternative topologies.

About Using Service or Server Migration to Enable High Availability of the Enterprise Topology

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

For static clusters, you can configure Automatic Service Migration by using the Configuration Wizard HA Options screen. If you select the Enable Automatic Service Migration option, it configures migratable target definitions that are required for automatic service migration. In the same screen, you can use JTA Transaction Log Persistence and JMS Server Persistence options to configure them with JDBC stores automatically. Oracle recommends that you enable these options when you configure static clusters in the OIM enterprise deployment.

For dynamic clusters, migratable targets are not required because some functionalities of the automatic service migration are provided inherently by the dynamic cluster. The Configuration Wizard High Availability Options screen is not used for dynamic clusters but some additional steps are required to configure the leasing and the persistent stores migration policies. Oracle recommends that you perform these post-steps when you configure dynamic clusters in the OIM enterprise deployment.

For more information, see Using Whole Server Migration and Service Migration in an Enterprise Deployment.