3 About the IAM Enterprise Deployment

Learn about deploying Oracle Identity and Access Management topologies on commodity hardware. These topologies represent specific reference implementations of the concepts described in About a Typical Enterprise Deployment.

This chapter includes the following topics:

• About the Primary and Build-Your-Own Enterprise Deployment Topologies
  There are two primary reference topologies for Oracle Identity and Access Management. While the components installed into each topology are the same, the exact Oracle Identity and Access Management topology you install and configure for your organization may vary.
• Diagram of Oracle Identity and Access Management on Distributed Hardware
  
• About the Primary Oracle Identity and Access Management Topology Diagrams
  The primary enterprise deployment topology is the main Oracle reference topology for Oracle Identity and Access Management. It provides a solution which is both highly available and scalable.
• About the Forgotten Password Functionality
  In Oracle 11g, the mechanism to reset passwords was provided by Oracle Identity Governance. In Oracle 12c, you have two possibilities - by integrating Oracle Access Management (OAM) and Oracle Identity Governance (OIG) or by using Oracle Access Management.
• Integrating Oracle LDAP, Oracle Access Manager, and Oracle Identity Governance
  Integration of Oracle Identity Manager and Oracle Access Manager with LDAP directories is done by using LDAP Connector.
• Roadmap for Implementing the Primary IAM Suite Topologies
  
• Building Your Own Oracle Identity and Access Management Topology
  These step-by-step instructions help you configure 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.
• About Using Service or Server Migration to Enable High Availability of the Enterprise Topology
  

About the Primary and Build-Your-Own Enterprise Deployment Topologies

There are two primary reference topologies for Oracle Identity and Access Management. While the components installed into each topology are the same, the exact Oracle Identity and Access Management topology you install and configure for your organization may vary.

This guide provides step-by-step instructions for installing and configuring these topologies.

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.

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.

After you have created your deployment, this guide will show you how to extend it to include additional IAM products, which you may want 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 want 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

The primary enterprise deployment topology is the main Oracle reference topology for Oracle Identity and Access Management. It provides a solution which is both highly available and scalable.

• Product Separation
  
• Understanding the Directory Tier
  
• About 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.
• OHSDomain used to host the Oracle HTTP Servers.
• OUDSMDomain used when OUDSM is deployed.

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 shut down the Governance instance without impacting the access components. From Oracle Identity and Access Management 12c, it is not supported to have Oracle Access Manager and Oracle Identity Governance in the same domain.

In addtion to the domains above, note that Oracle Unified Directory is deployed without a domain.

A further benefit of this separation is that you can build a topology in a modular fashion. You can start 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.

About 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	oam_server1, oam_server2
	Oracle Policy Manager	oam_policy_mgr1, oam_policy_mgr2
IAMGovernanceDomain	Oracle Identity Governance	oim_server1, oim_server2
	Oracle SOA Suite	soa_server1, soa_server2
	Oracle Web Services Manager	WLS_WSM1, WLS_WSM2

About the Forgotten Password Functionality

In Oracle 11g, the mechanism to reset passwords was provided by Oracle Identity Governance. In Oracle 12c, you have two possibilities - by integrating Oracle Access Management (OAM) and Oracle Identity Governance (OIG) or by using Oracle Access Management.

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

  In this scenario, when the users first sign in, they can set a number of challenge questions stored in OIG. If users forget their password, they can answer the challenge questions. If they answer their challenge questions successfully, they will be given the option to reset their password by using OIG.

• Oracle Access Management:

  In this scenario, OAM is wired to the Oracle User Messaging Service. Each user is associated with either a telephone number and or an email address. When users request for a forgotten password link, they are sent a one time PIN which they can enter into the application to reset the password.

This guide describes how to set up both the scenarios.

Integrating Oracle LDAP, Oracle Access Manager, and Oracle Identity Governance

Integration of Oracle Identity Manager and Oracle Access Manager with LDAP directories is done by using LDAP Connector.

To enable termination of user sessions upon disablement or termination of a user, download the 12.2.1.3 version of the LDAP Connector.

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:

  The identity reconciliation mode supports the 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. This guide explains 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 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	Configuring Oracle HTTP Server 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

These step-by-step instructions help you configure 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.

For information on the primary enterprise topologies for Oracle Identity and Access Management, see Figure 3-1.

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.

A few alternatives to the reference Oracle Identity and Access Management topologies you can implement by using the steps provided in this guide are:

• 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

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.