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
  The sample topology diagram in this section shows an eight-node distributed 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.
• About the Forgotten Password Functionality
  This section provides information about the forgotten password functionality.
• Integrating Oracle LDAP, Oracle Access Manager, and Oracle Identity Governance
  Integration of Oracle Identity Governance and Oracle Access Manager with LDAP directories is done by using LDAP Connector.
• Roadmap for Implementing the Primary IAM Suite Topologies
  This section provides a roadmap for implementing the primary IAM suite topologies on commodity hardware.
• 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 SSL Certificates in the Oracle Identity Management Enterprise Topology
  The Oracle Identity Management Enterprise Deployment Topology can use SSL all the way from the external clients to the backend WebLogic Servers.
• About Using JDBC Persistent Stores
  Oracle recommends that you use JDBC stores. This leverages the consistency, data protection, and high availability features of an Oracle database that makes stores available for all the servers in the cluster.
• 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.

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 diagram in this section shows an 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 illustrations shows the Oracle Identity and Access Management topologies for End to End SSL, and for SSL Termination. The diagrams are 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 End to End SSL Topology

Figure 3-2 Oracle Identity and Access Management SSL Terminated 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
  
• About the igdinternal Virtual Server Name
  
• 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. 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 an 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 load balancer is required. This load balancer should exist and be in a redundant configuration to ensure maximum availability. The load balancer must be configured to recognize a set of virtual server names.

The 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

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

  oig.example.com:443

  In previous releases of the Enterprise Deployment Guide, login.example.com and oig.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 for administrators who need to access the Oracle Enterprise Manager Fusion Middleware Control, Oracle WebLogic Remote Console, and Oracle Access Manager Console.

  As a result, clients access this service by using the following secure address:

  iadadmin.example.com:443

  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.

  Note:

  In certain circumstances you may wish to expose the administration URLs to certain users on the internet to provide remote access. Whilst this is highly discouraged, if you need to do this you should have a different listen port for each administration address, for example iadadmin.example.com:444. This must have very strict security policies in place to ensure that it is available only to the users required.

• igdadmin.example.com - This virtual server name is for administrators who need to access the Oracle Enterprise Manager Fusion Middleware Control, Oracle WebLogic Remote Console, and Oracle Identity Governance System Administration Console.

  As a result, clients access this service by using the following secure address:

  igdadmin.example.com:443

  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.

  Note:

  In certain circumstances you may wish to expose the administration URLs to certain users on the internet to provide remote access. Whilst this is highly discouraged, if you need to do this you should have a different listen port for each administration address, for example iadadmin.example.com:445. This must have very strict security policies in place to ensure that it is available only to the users required.

• 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 Identity Governance Suite and Oracle SOA Suite internal communications.

  For SSL terminated installations the traffic from clients to this virtual servers is not SSL-enabled.

  igdinternal.example.com:7777

  For End to end SSL installations the following:

  igdinternal.example.com:443

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

To provide an easier mapping between frontend hostnames and backend OHS listeners, this guide presents different listeners (443,444,445 and 446) in the frontend load balancer that map to the 4443, 4444, 4445 and 4446 listeners in OHS. This allows easier segregation of traffic rules and SLAs for each type of access (LBR listener on 443 for apps, 444 for internal access, and 445 for WLS domain administration). Alternatively, the same port (443) can be used in the frontend load balancer for all the different frontend hostnames. However, that OHS cannot host more than one SSL virtual host on the same IP address and port so it will still require separate listeners for each virtual host. For more information about the OHS configuration for the different products, see the following chapters.

This guide provides instructions that explain how to perform the following tasks:

• Configuring the load balancer to recognize and route requests to the virtual host names.

• Configuring the Oracle HTTP Server instances on the web tier to recognize and properly route requests to the virtual host names and the correct host computers.

About the igdinternal Virtual Server Name

The igdinternal.example.com virtual server name functions the same as the oig.example.com, except that it is invoked by intranet clients and callbacks only. This topic provides additional details.

The igdinternal.example.com virtual server name is not used explicitly during the installation and configuration of the enterprise deployment, but custom systems often expose services that should be consumed by internal-only clients. In such cases, for efficiency and security reasons you must avoid using an external URL such as oig.example.com. Instead, you should use an address that cannot be invoked by Internet clients. SOA composite applications can use this internal URL in their end points either directly or through deployment plans.

When you use the igdinternal.example.com address, there are implications for the front end address specified for the system. Web services optimizations (for example, direct RMI invocation instead of invocations that involve a full loopback to the load balancer endpoint) are triggered when the front end address for the cluster matches the invocation endpoint. For this reason, depending on the number and relevance of the expected internal invocations, consider setting the front end URL for the cluster and the ServerURL and HTTPServerURL properties to either the external or internal.

You can set the front end URL for a cluster when you create the cluster in the Configuration Wizard. You can also modify it later, by using the WebLogic Remote Console. See Configure HTTP in Oracle WebLogic Remote Console Online Help.

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

About the Forgotten Password Functionality

This section provides information about the forgotten password functionality.

There are two methods to manage forgotten passwords.

• 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 Governance 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 Governance connectors. The ICF is shipped along with Oracle Identity Governance. 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, OIG 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 Governance.

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 Governance context, the term provisioning is also used to mean updates (for example enabling or disabling) made to the target system account through Oracle Identity Governance.

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

Roadmap for Implementing the Primary IAM Suite Topologies

This section provides a roadmap for implementing the primary IAM suite topologies on commodity hardware.

Table 3-2 below outlines a roadmap for implementing deploying IAM in an Enterprise Deployment.

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
	Review the hardware and software requirements and procure the resources for the enterprise deployment.	Procuring Resources for an Enterprise Deployment or Procuring Resources for an Oracle Cloud Infrastructure Deployment
	Download and configure the WebLogic Remote Console.	Download and Configure the WebLogic Remote Console
	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 Oracle Cloud Infrastructure for an enterprise deployment (if using).	Preparing the Oracle Cloud Infrastructure for an Enterprise Deployment
	Prepare the database.	Preparing the Database for an Enterprise Deployment
	Install and configure Oracle LDAP.	Configuring Oracle LDAP for an Enterprise Deployment
	Install and configure Oracle Unified Directory Services Manager.	Configuring Oracle Unified Directory Service Manager
	Install and configure Oracle Access Management	Configuring Oracle Access Management
	Install and configure Oracle Identity Governance.	Configuring Oracle Identity Governance
	Install and Configure Oracle HTTP Server.	Configuring Oracle HTTP Server for an Enterprise Deployment
	Perform common configuration and management tasks.	Common Configuration and Management Tasks for an Enterprise Deployment
	Configure server migration settings.	Using Service Migration in an Enterprise Deployment
	Learn about scaling procedures.	Scaling Procedures for 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 iam-enterprise-deployment.html#GUID-6E3F9FD0-F706-4199-A144-6473AD320003__CHDFBIDE.

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

• OIG Only with an Existing Directory

• OAM/OIG Integrated in a Modular Deployment

• OAM/OIG Integrated with an Existing Directory

About Using SSL Certificates in the Oracle Identity Management Enterprise Topology

The Oracle Identity Management Enterprise Deployment Topology can use SSL all the way from the external clients to the backend WebLogic Servers.

The HTTPS protocol is used for the communication between the clients and the front-end load balancer, the front-end load balancer and Oracle HTTP Servers, and the Oracle HTTP Servers and the WebLogic Servers.

For these communications to take place, each access point (whether the frontend load balancer, Oracle HTTP Server or Oracle WebLogic Server) needs to certify its identity and provide a public key to encrypt traffic. This is done using the appropriate SSL certificate in each access point. These SSL certificates are typically provided by formal certificate authorities (CAs). It is expected that in a real enterprise deployment, certificates are issued by one of these commercial entities and are present in the pertaining end points. Since each Certificate Authority has its own mechanisms to issue a SSL certificate, it is out of the scope of this Enterprise Deployment Guide to use and describe such processes. However, to provide a working end to end configuration with a solid encryption in the different communications across tiers, this guide provides SSL configuration steps using a self issued Certificate Authority. This approach is considered secure and solid enough since the endpoints involved (OHS and WLS listeners) reside behind their corresponding firewalls and are not really exposed to the public. The frontend load balancer is considered a much more exposed endpoint and it is expected in all cases that users acquire the pertaining certificate for it from a formal Certificate Authority.

By default, the different chapters in this guide follow a flow based on the creation and usage of certificates using a self issued CA. Scripts are provided to simplify most of the complexity around creating these certificates and adding them to the corresponding stores and wallets.

About Using JDBC Persistent Stores

Oracle recommends that you use JDBC stores. This leverages the consistency, data protection, and high availability features of an Oracle database that makes stores available for all the servers in the cluster.

Refer to the technical details in the Using Persistent Stores for TLOGs and JMS in an Enterprise Deployment section in the Common Configuration and Management Tasks for an Enterprise Deployment chapter. These technical details provide some guidance on possible performance implications and tunning recommendations.

In the Configuration Wizard, select the following when creating and extending domains in the High Availability Options screen:

• Set JTA Transaction Log Persistence to JDBC TLog Store.

• Set JMS Server Persistence to JMS JDBC Store.

This ensures that the JDBC persistent stores are used for both JMS and TLOGS.

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.

Service Migration is configured using the Configuration Wizard HA Options screen. When you select the Enable Automatic Service Migration option in the Configuration Wizard HA Options screen, it configures migratable target definitions that are required for automatic service migration.

In the same screen, you 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 clusters in the SOA enterprise deployment.

For more information about service migration, see Using Service Migration in an Enterprise Deployment.