4 About the IAM Exalogic Enterprise Deployment
This book assumes you have an understanding of Exalogic, if you wish to gain further information on how Exalogic works, refer to the Enterprise Deployment Guide for Exalogic for the release of Exalogic you are using.
Topics:
- Why Install Oracle IAM on Exalogic
- Understanding the Primary and Build your Own Enterprise Deployment Topologies on Exalogic
- Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies
- Oracle Identity and Access Management and Exalogic Networking
- Summary of the Managed Servers and Clusters on the Application Tier Hosts
- Understanding Oracle Traffic Director
- About Exalogic Optimizations for WebLogic
- Roadmap for Implementing the Primary Oracle Identity and Access Management Topologies
- Building your Own Oracle Identity and Access Management Topology
- About Installing and Configuring a Custom Enterprise Topology
- About Using Service or Server Migration to Enable High Availability of the Enterprise Topology
Parent topic: Understanding an Enterprise Deployment
Why Install Oracle IAM on Exalogic
Oracle Exalogic is a highly available, high performance integrated hardware appliance from Oracle. Oracle Fusion Middleware components, when deployed onto Oracle Exalogic, get the benefit of its superior networking, resulting in improved application throughput. In addition, WebLogic server has had a number of optimizations that enable it to run faster on Oracle Exalogic. These optimizations further increase the throughput of the applications deployed.
Deploying Oracle IAM on Exalogic ensures that you have a highly available infrastructure that provides you with the maximum availability and performance available.
Parent topic: About the IAM Exalogic Enterprise Deployment
Understanding the Primary and Build your Own Enterprise Deployment Topologies on Exalogic
This guide focusses on the primary deployment topology of deploying Oracle Identity and Access Management on virtual Exalogic or Oracle Cloud Machine.
The following secondary topologies are illustrated and explained in this document:
-
Oracle Identity Management on Physical Exalogic
-
Oracle Identity Management on Exalogic with an external web tier
Virtual Exalogic vs Physical Exalogic:
A physical Exalogic deployment uses the raw processing power of an Exalogic rack. Products are deployed directly onto the compute nodes. Oracle Virtual Exalogic uses the same underlying hardware, but the Oracle Elastic Cloud or Oracle Cloud Machine infrastructure is used to provide a virtualization layer allowing smaller virtual servers to be created.
Virtual servers are used to provide a similar set of hosts to the platform deployment. Physical Exalogic deployments have access to greater computing power but some of that power can be wasted if the compute nodes are not used to the maximum. A virtualized deployment provides greater separation and manageability, but provides extra design complexity to ensure that no two virtual servers of the same type run on the same underlying compute node.
Parent topic: About the IAM Exalogic Enterprise Deployment
Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies
This diagrams in this section illustrate the Oracle Identity and Access Management Exalogic topologies.
Topics:
- Diagram of Oracle Identity and Access Management on Physical Exalogic
- Diagram of Oracle Identity and Access Management on Virtual Exalogic
- Diagram of Oracle Identity and Access Management with an External Web Tier
- About the Primary Oracle Identity and Access Management Topology Diagrams
- Differences Between an Exalogic Deployment and a Platform Deployment
Parent topic: About the IAM Exalogic Enterprise Deployment
Diagram of Oracle Identity and Access Management on Physical Exalogic
Figure nameillustrates the Oracle Identity and Access Management consolidated topology.
Figure 4-1 Exalogic Physical Deployment Topology

Diagram of Oracle Identity and Access Management on Virtual Exalogic
Figure name illustrates the Oracle Identity and Access Management distributed topology.
Figure 4-2 Exalogic Virtual Deployment Topology Diagram

Diagram of Oracle Identity and Access Management with an External Web Tier
Figure name illustrates the Oracle Identity and Access Management consolidated topology with an external Web tier.
Figure 4-3 Exalogic Topology with External OHS

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:
About Product Separation
An Oracle Identity and Access Management deployment is made up of a number of components. These components include:
-
Web Servers
-
WebLogic Application Servers
-
LDAP - Manage a Virtual IP Address that internal servers can access for the purposes of making LDAP calls.
Receive requests on the LDAP Virtual IP address and pass them on to the running LDAP instances using the IPoIB Network.
-
Database
About Access and Governance Domains
Figure 4-1, Figure 4-2, and Figure 4-3 depict a separation between each component. In addition, the WebLogic components are further split into two different WebLogic domains: IAMAccessDomain, and IAMGovernanceDomain. Products are distributed as follows:
-
IAMAccessDomain contains Oracle Access Manager, Oracle Mobile Security Suite.
-
IAMGovernanceDomain contains Oracle Identity Manager, Oracle Business Intelligence.
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, 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 with a directory and extend it to Access Components, and 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 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 these directories for the first time, or you may be using existing directories from within the organization. The directories supported are Oracle Unified Directory (OUD).
The directory you choose will be organization dependent.
Understanding the Web Tier
In Oracle 12c, Oracle Traffic Director (OTD) can be used in either collocated or standalone mode.
Standalone mode does not support the use of failover groups, and its management via graphical interface is limited. Therefore, it is recommended that you deploy OTD using the collocated mode. When using the collocated mode, the OTD management components are placed into a WebLogic administration server. These components can be placed into an existing webLogic domain.
When your OTD instance is routing requests to multiple domains as it is, in Oracle Identity and Access Management, it is recommended that you use a dedicated domain for Oracle Traffic Director. This allows Oracle Traffic director to be managed independently of the domains to which it is routing requests.
In a platform deployment where each zone is separated by firewalls, it is recommended that the administration server be placed into the application zone. In an Oracle Exalogic deployment, where there is no zone separation, the administration server can co—exist with the OTD instances.
If you are using an external web tier, and if your external webtier is running OTD, then it is recommended that the OTD administration server be placed outside of the Web Tier DMZ.
Differences Between an Exalogic Deployment and a Platform Deployment
When you deploy Oracle Identity and Access Management on Exalogic, most, if not all of the components are installed inside the Exalogic appliance. As described in About a Typical Enterprise Deployment, a typical enterprise deployment is distributed amongst various tiers. Because the hardware components are incorporated into the Exalogic Appliance, the number of tiers available is reduced.
There is no need for an application or directory tier and if your Exalogic Appliance is linked to an Exadata appliance. Database tier is moved to Exadata if Exalogic is linked to it.
The second major difference between a platform and an Exalogic deployment is that the Exalogic deployment use Oracle Traffic Director instead of Oracle HTTP server. In an Exalogic deployment, Oracle Traffic Director performs a number of roles. It can act as both a load balancer for internal traffic ensuring that it is not exposed outside the Exalogic Appliance, and as a Web Server.
If you use an external Web tier, you do not need to use the Web serving characteristics of Oracle Traffic Director.
When you deploy Oracle Fusion Middleware on Oracle Exalogic, you gain access to a number of in-built WebLogic optimizations which ensure that the Fusion Middleware deployment uses some of the in-built Exalogic technologies to provide better performance.
Oracle Identity and Access Management and Exalogic Networking
One of the core advantages of Exalogic is its fast and flexible network. When deploying Oracle IAM on Exalogic, you have to consider how you wish to use the Oracle Exalogic Networking.
There are three types of networks within an Exalogic appliance:
-
IPoIB - This is the internal Infiniband Network that connects the internal components of the Exalogic appliance. This network is fast, but cannot be connected to the outside world. The benefit of this network is that it can be used to ensure that network traffic is kept private from the outside world. The downside to using this network is where external components need to access application components inside the Exalogic Appliance.
-
EoIB - This network also uses the Exalogic Infiniband Network but it is possible to connect this network to the standard corporate network. This allows external component to communicate directly to components inside Exalogic. This network is always used for communication between your hardware load balancer and Oracle Traffic Director.
-
eth0 - This is the management network it is used for connecting to the Exalogic components through the built-in ethernet network. This network is only used for management operations and should not be used for production deployments. Its this network that is used to log in to the Exalogic components to configure them.
This section includes the following topics:
- Considerations for Choosing your Exalogic Network
- Typical IAM Network Usage
- Summary of Oracle Identity and Access Management Load Balancing Virtual Server Names
Parent topic: About the IAM Exalogic Enterprise Deployment
Considerations for Choosing your Exalogic Network
Some components within IAM, by default, only talk on a single network. For example, WebLogic Managed servers, other components such as Oracle Traffic Director communicate on both the internal networks. This is why Oracle Traffic Director is the preferred load balancer for traffic once it enters the Exalogic Appliance.
When choosing which Exalogic Network to use, consider the following:
-
If you are planning to create a multi-data center deployment, you should configure your components to use the EoIB network.
-
Are you planning to use an external Web tier? If so, by default, you can configure your components to work on the EoIB Network.
-
If all Traffic comes through Oracle Traffic Director, and once it reaches there, all traffic stays within the Exalogic appliance, configure components to use the IPoIB network.
-
If all LDAP traffic originates within the Exalogic Appliance, configure your LDAP server to use the IPoIB network.
-
If your database resides in an Exadata appliance, which is directly connected to the Exalogic appliance, use the IPoIB network. If not, then you should use the EoIB network.
Note:
You can configure Oracle Access Manager Managed Servers to communicate on both networks using the OAM Proxy port.
You can configure Standard WebLogic Managed Servers to listen on multiple networks using different channels.
Typical IAM Network Usage
This section describes a typical IAM network usage. It contains the following sections:
Virtual Exalogic
Figure 4-4 shows the typical network map for an Identity and Access Management deployment on a virtual Exalogic environment.
If you are not using an external Web tier, you can configure all components to use the Internal IPoIB network. Oracle traffic Director is configured to accept requests on the EoIB network, but pass them on to WebLogic and LDAP using the IPoIB network.
The elements of Figure 4-4 are defined in Table 4-1.
Table 4-1 Exalogic Virtual IP Addresses Worksheet
Hostname Example for This Guide | Interface | IP Address/Subnet | Customer Value | Type | Host | Bound By | Details |
---|---|---|---|---|---|---|---|
WEBHOST1 |
bond0 |
192.168.2.1/255.255.224.0 |
IPoIB/Fixed |
vServer1/WEBHOST1 |
NA |
Access to vServer11/WEBHOST1 via the internal IPoIB network. |
|
WEBHOST2 |
bond0 |
192.168.2.2/255.255.224.0 |
IPoIB/Fixed |
vServer2/WEBHOST2 |
NA |
Access to vServer2/WEBHOST2 via the internal IPoIB network. |
|
OAMHOST1 |
bond0 |
192.168.2.3/255.255.224.0 |
IPoIB/Fixed |
vServer3/OAMHOST1 |
NA |
Access to vServer3/OAMHOST1 via the internal IPoIB network |
|
OAMHOST2 |
bond0 |
192.168.2.4/255.255.224.0 |
IPoIB/Fixed |
vServer4/OAMHOST2 |
NA |
Access to vServer4/OAMHOST2 via the internal IPoIB network |
|
OIMHOST1 |
bond0 |
192.168.10.5/255.255.224.0 |
IPoIB/Fixed |
vServer5/OIMHOST1 |
NA |
Access to vServer5/OIMHOST1 via the internal IPoIB network |
|
OIMHOST2 |
bond0 |
192.168.10.6/255.255.224.0 |
IPoIB/Fixed |
vServer6/OIMHOST2 |
NA |
Access to vServer6/OIMHOST2 via the internal IPoIB network |
|
LDAPHOST1 |
bond0 |
192.168.10.7/255.255.224.0 |
IPoIB/Fixed |
vServer7/LDAPHOST1 |
NA |
Access to vServer7/LDAPHOST1 via the internal IPoIB network |
|
LDAPHOST2 |
bond0 |
192.168.10.8/255.255.224.0 |
IPoIB/Fixed |
vServer8/LDAPHOST2 |
NA |
Access to vServer8/LDAPHOST2 via the internal IPoIB network |
|
OTDADMINVHN |
bond1:1 |
10.10.30.1/255.255.224.0 |
EoIB/Floating |
vServer1/WEBHOST1 |
OTD Administration Server |
A floating IP address for the Administration Server is recommended, if you want to manually migrate the OTD Administration Server from WEBHOST1 to WEBHOST2. |
|
IADADMINVHN |
bond1:1 |
10.10.30.2/255.255.224.0 |
EoIB /Floating |
vServer3/OAMHOST1 |
IAMAccessDomain Administration Server |
A floating IP address for the IAMAccessDomain Administration Server is recommended, if you want to manually migrate the Administration Server from OAMHOST1 to OAMHOST2. |
|
IGDADMINVHN |
bond1:1 |
10.10.30.3/255.255.224.0 |
EoIB /Floating |
vServer5/OIMHOST1 |
IAMGovernanceDomain Administration Server |
A floating IP address for the IAMGovernanceDomain Administration Server is recommended, if you want to manually migrate the Administration Server from OIMHOST2 to OIMHOST1 |
|
WEBHOST1VHN1 |
OTD |
10.10.50.1/255.255.224.0 |
EoIB /Floating |
vServer1/WEBHOST1 |
OTD - WEBHOST1 |
A floating IP Address managed by OTD. This is the IP Address to which load balancers will connect. This is optional |
|
WEBHOST2VHN1 |
OTD |
10.10.50.2/255.255.224.0 |
EoIB /Floating |
vServer2/WEBHOST2 |
OTD - WEBHOST2 |
A floating IP Address managed by OTD. This is the IP Address to which load balancers will connect. This is optional. |
|
OIMHOST1VHN1 |
bond0:1 |
192.168.30.1/255.255.240.0 |
IPoIB/Floating |
vServer5/OIMHOST1 |
WLS_OIM1 Default Channel |
Initially enabled in OIMHOST1 and can be failed over by server migration to OIMHOST2 Used for Whole server migration only. |
|
OIMHOST2VHN1 |
bond0:1 |
192.168.30.2/255.255.240.0 |
IPoIB/Floating |
vServer6/OIMHOST2 |
WLS_OIM2 Default Channel |
Initially enabled in OIMHOST2 and can be failed over by server migration to OIMHOST1 Used for Whole server migration only. |
|
OIMHOST1VHN2 |
bond0:2 |
192.168.30.3/255.255.240.0 |
IPoIB/Floating |
vServer5/OIMHOST1 |
WLS_SOA1 Default Channel |
Initially enabled in OIMHOST1 and can be failed over by server migration to OIMHOST2 Used for Whole server migration only. |
|
OIMHOST2VHN2 |
bond0:2 |
192.168.30.4/255.255.240.0 |
IPoIB/Floating |
vServer6/OIMHOST2 |
WLS_SOA2 Default Channel |
Initially enabled in OIMHOST2 and can be failed over by server migration to OIMHOST1. Used for Whole server migration only. |
|
OIMHOST1VHN3 |
bond0:3 |
192.168.30.5/255.255.224.0 |
IPoIB/Floating |
vServer5/OIMHOST1 |
WLS_BI1 Default Channel |
Initially enabled in OIMHOST1 and can be failed over by server migration to OIMHOST2. Used for Whole server migration only. |
|
OIMHOST2VHN3 |
bond 0:3 |
192.168.30.6/255.255.224.0 |
IPoIB/Floating |
vServer6/OIMHOST2 |
WLS_BI2 Default Channel |
Initially enabled in OIMHOST2 and can be failed over by server migration to OIMHOST1. Used for Whole server migration only. |
|
WEBHOST1-EXT |
bond1 |
10.10.10.1/255.255.240.0 |
EoIB/Fixed |
vServer1/WEBHOST1 |
NA |
A fixed IP allowing the vServer to be accessed by an External Load balancer |
|
WEBHOST2-EXT |
bond1 |
10.10.10.2/255.255.240.0 |
EoIB/Fixed |
vServer2/WEBHOST2 |
NA |
A fixed IP allowing the vServer to be accessed by an External Load balancer |
|
WEBHOST1-STOR |
bond3 |
192.168.32.1/255.255.240.0 |
IPoIB/Fixed |
vServer1/WEBHOST1 |
NA |
A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network. |
|
WEBHOST2-STOR |
bond3 |
192.168.32.2/255.255.240.0 |
IPoIB/Fixed |
vServer2/WEBHOST2 |
NA |
A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network. |
|
OAMHOST1-STOR |
bond3 |
192.168.32.3/255.255.240.0 |
IPoIB/Fixed |
vServer3/OAMHOST1 |
NA |
A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network. |
|
OAMHOST2-STOR |
bond3 |
192.168.32.4/255.255.240.0 |
IPoIB/Fixed |
vServer4/OAMHOST2 |
NA |
A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network. |
|
OIMHOST1-STOR |
bond3 |
192.168.32.5/255.255.240.0 |
IPoIB/Fixed |
vServer5/OIMHOST1 |
NA |
A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network. |
|
OIMHOST2-STOR |
bond3 |
192.168.32.6/255.255.240.0 |
IPoIB/Fixed |
vServer6/OIMHOST2 |
NA |
A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network. |
|
LDAPHOST1-STOR |
bond3 |
192.168.32.7/255.255.240.0 |
IPoIB/Fixed |
vServer7/LDAPHOST1 |
NA |
A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network. |
|
LDAPHOST2-STOR |
bond3 |
192.168.32.8/255.255.240.0 |
IPoIB/Fixed |
vServer8/LDAPHOST2 |
NA |
A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network. |
|
OAMHOST1-DATA |
bond4 |
192.168.10.3/255.255.240.0 |
IPoIB/Fixed |
vServer3/OAMHOST1 |
NA |
A fixed IP address allowing the vServer to connect to the Exadata appliance using the default internal network. |
|
OAMHOST2-DATA |
bond4 |
192.168.10.4/255.255.240.0 |
IPoIB/Fixed |
vServer4/OAMHOST2 |
NA |
A fixed IP address allowing the vServer to connect to the Exadata appliance using the default internal network. |
|
OIMHOST1-DATA |
bond4 |
192.168.10.5/255.255.240.0 |
IPoIB/Fixed |
vServer5/OIMHOST1 |
NA |
A fixed IP address allowing the vServer to connect to the Exadata appliance using the default internal network. |
|
OIMHOST2-DATA |
bond4 |
192.168.10.6/255.255.240.0 |
IPoIB/Fixed |
vServer6/OIMHOST2 |
NA |
A fixed IP address allowing the vServer to connect to the Exadata appliance using the default internal network. |
|
LDAPHOST1-DATA |
bond4 |
192.168.10.7/255.255.240.0 |
IPoIB/Fixed |
vServer7/LDAPHOST1 |
NA |
A fixed IP address allowing the vServer to connect to the Exadata appliance using the default internal network. |
|
LDAPHOST2-DATA |
bond4 |
192.168.10.8/255.255.240.0 |
IPoIB/Fixed |
vServer8/LDAPHOST2 |
NA |
A fixed IP address allowing the vServer to connect to the Exadata appliance using the default internal network. |
|
IGDINTERNAL |
OTD |
192.168.50.1/255.255.224.0 |
IPoIB/ Floating |
vServer1/WEBHOST1 |
NA |
Oracle Traffic Director failover group for SOA |
|
IDSTORE |
OTD |
192.168.50.3/255.255.224.0 |
IPoIB/ Floating |
vServer2/WEBHOST2 |
NA |
Oracle Traffic Director failover group for LDAP. |
Note:
The IP addresses listed in Table 4-1 are for example only. Because of the way that IP addresses are allocated in virtual Exalogic, it is highly unlikely that you will be able to use the exact values in this table.
Parent topic: Typical IAM Network Usage
Physical Exalogic
Figure 4-5 shows the typical network map for an Identity and Access Management deployment on a physical Exalogic environment.
If you are not using an external Web tier, you can configure all components to use the Internal IPoIB network. Oracle traffic Director is configured to accept requests on the EoIB network, but pass them on to WebLogic and LDAP using the IPoIB network.
The elements of Figure 4-5 are defined in Table 4-2.
Table 4-2 Exalogic Physical IP Addresses Worksheet
Hostname Example for This Guide | Interface | IP Address/Subnet | Customer Value | Type | Host | Bound By | Details |
---|---|---|---|---|---|---|---|
IAMHOST1 |
bond0 |
192.168.10.1/255.255.224.0 |
IPoIB/ Fixed |
ComputNode1/IAMHOST1 |
NA |
Access to IAMHOST1 using the internal IPoIB network. |
|
IAMHOST2 |
bond0 |
192.168.10.2/255.255.224.0 |
IPoIB/ Fixed |
ComputNode2/IAMHOST2 |
NA |
Access to IAMHOST2 using the internal IPoIB network. |
|
OTDADMINVHN |
bond1:1 |
10.10.30.1/255.255.224.0 |
EoIB /Floating |
ComputNode1/IAMHOST1 |
OTD Administration Server |
A floating IP address for the Administration Server is recommended, if you want to manually migrate the OTD Administration Server from IAMHOST1 to IAMHOST2. |
|
IADADMINVHN |
bond1:2 |
10.10.30.2/255.255.224.0 |
EoIB /Floating |
ComputNode2/IAMHOST1 |
IAMAccessDomain Administration Server |
A floating IP address for the IAMAccessDomain Administration Server is recommended, if you want to manually migrate the Administration Server from IAMHOST1 to IAMHOST2. |
|
IGDADMINVHN |
bond1:3 |
10.10.30.3/255.255.224.0 |
EoIB /Floating |
ComputNode1/IAMHOST1 |
IAMGovernanceDomain Administration Server |
A floating IP address for the IAMGovernanceDomain Administration Server is recommended, if you want to manually migrate the Administration Server from IAMHOST1 to IAMHOST2. |
|
WEBHOST1VHN |
OTD |
10.10.50.1/255.255.224.0 |
EoIB /Floating |
ComputNode1/IAMHOST1 |
OTD - IAMHOST1 |
A floating IP Address managed by OTD. This is the IP Address to which load balancers will connect. This is recommended but optional. |
|
WEBHOST2VHN |
OTD |
10.10.50.2/255.255.224.0 |
EoIB /Floating |
ComputNode2/IAMHOST2 |
OTD - IAMHOST2 |
A floating IP Address managed by OTD. This is the IP Address to which load balancers will connect. This is recommended but optional |
|
OIMHOST1VHN1 |
bond0:1 |
192.168.30.1/255.255.240.0 |
IPoIB/ Floating |
ComputNode1/IAMHOST1 |
WLS_OIM1 Default Channel |
Initially enabled in IAMHOST1 can be failed over by server migration to IAMHOST2. Used for Whole server migration only. |
|
OIMHOST2VHN1 |
bond0:1 |
192.168.30.2/255.255.240.0 |
|
IPoIB/ Floating |
ComputNode2/IAMHOST2 |
WLS_OIM2 Default Channel |
Initially enabled in IAMHOST2 can be failed over by server migration to IAMHOST1. Used for Whole server migration only. |
OIMHOST1VHN2 |
bond0:2 |
192.168.30.3/255.255.240.0 |
IPoIB/ Floating |
ComputNode1/IAMHOST1 |
WLS_SOA1 default channel |
Initially enabled in IAMHOST1 can be failed over by server migration to IAMHOST2. Used for Whole server migration only. |
|
OIMHOST2VHN2 |
bond0:2 |
192.168.30.4/255.255.240.0 |
IPoIB/ Floating |
ComputNode2/IAMHOST2 |
WLS_SOA2 default channel |
Initially enabled in IAMHOST2 can be failed over by server migration to IAMHOST1. Used for Whole server migration only. |
|
OIMHOST1VHN3 |
bond 0:3 |
192.168.30.5/255.255.240.0 |
IPoIB/Floating |
ComputeNode1/IAMHOST1 |
WLS_BI1 default channel |
Initially enabled in IAMHOST2 can be failed over by server migration to IAMHOST1 Used for Whole server migration only. |
|
OIMHOST2VHN3 |
bond 0:3 |
192.168.30.6/255.255.240.0 |
IPoIB/Floating |
ComputeNode2/IAMHOST2 |
WLS_BI1 default channel |
Initially enabled in IAMHOST1 can be failed over by server migration to IAMHOST2 Used for Whole server migration only. |
|
IAMHOST1EXT |
bond1 |
10.10.10.1/255.255.240.0 |
EoIB/Fixed |
ComputNode1/IAMHOST1 |
NA |
A fixed IP allowing the compute node to be accessed by an External Corporate Network (EoIB) |
|
IAMHOST2EXT |
bond1 |
10.10.10.2/255.255.240.0 |
EoIB/Fixed |
ComputNode2/IAMHOST2 |
NA |
A fixed IP allowing the compute node to be accessed by an External Corporate Network (EoIB) |
|
IGDINTERNAL |
OTD |
192.168.50.1/255.255.224.0 |
IPoIB/ Floating |
ComputNode1/IAMHOST1 |
NA |
Oracle Traffic Director failover group for SOA |
|
IDSTORE |
OTD |
192.168.50.3/255.255.224.0 |
IPoIB/ Floating |
ComputNode2/IAMHOST2 |
NA |
Oracle Traffic Director failover group for LDAP |
Parent topic: Typical IAM Network Usage
Physical Exalogic with External Web Tier
Figure 4-6 shows the typical network map for an Identity and Access Management deployment on a physical Exalogic environment with external Web Tier.
If you are not using an external Web tier, you can configure all components to use the Internal IPoIB network. Oracle traffic Director is configured to accept requests on the EoIB network, but pass them on to WebLogic and LDAP using the IPoIB network.
The elements of Figure 4-6 are defined in Table 4-3.
Table 4-3 Exalogic Physical IP Addresses Worksheet
Hostname Example for This Guide | Interface | IP Address/Subnet | Customer Value | Type | Host | Bound By | Details |
---|---|---|---|---|---|---|---|
IAMHOST1 |
bond0 |
192.168.10.1/255.255.224.0 |
IPoIB/Fixed |
ComputNode1/IAMHOST1 |
NA |
Access to IAMHOST1 using the internal IPoIB network. |
|
IAMHOST2 |
bond0 |
192.168.10.2/255.255.224.0 |
IPoIB/Fixed |
ComputNode2/IAMHOST2 |
NA |
Access to IAMHOST2 using the internal IPoIB network. |
|
OTDADMINVHN |
bond1:1 |
10.10.30.1/255.255.224.0 |
EoIB/Floating |
ComputNode1/IAMHOST1 |
OTD Administration Server |
A floating IP address for the Administration Server is recommended, if you want to manually migrate the OTD Administration Server from IAMHOST1 to IAMHOST2. |
|
IADADMINVHN |
bond1:2 |
10.10.30.2/255.255.224.0 |
EoIB/Floating |
ComputNode2/IAMHOST1 |
IAMAccessDomain Administration Server |
A floating IP address for the IAMAccessDomain Administration Server is recommended, if you want to manually migrate the Administration Server from IAMHOST1 to IAMHOST2. |
|
IGDADMINVHN |
bond1:1 |
10.10.30.3/255.255.224.0 |
EoIB/Floating |
ComputNode1/IAMHOST1 |
IAMGovernanceDomain Administration Server |
A floating IP address for the IAMGovernanceDomain Administration Server is recommended, if you want to manually migrate the Administration Server from IAMHOST1 to IAMHOST2. |
|
OIMHOST1VHN1 |
bond1:3 |
10.10.30.4/255.255.240.0 |
EoIB/Floating |
ComputNode1/IAMHOST1 |
WLS_OIM1 Default Channel |
Initially enabled in IAMHOST1 can be failed over by server migration to IAMHOST2. Used for Whole Server Migration only. |
|
OIMHOST2VHN1 |
bond1:2 |
10.10.30.7/255.255.240.0 |
|
EoIB/Floating |
ComputNode2/IAMHOST2 |
WLS_OIM2 Default Channel |
Initially enabled in IAMHOST2 can be failed over by server migration to IAMHOST1. Used for Whole Server Migration only. |
OIMHOST1VHN2 |
bond1:4 |
10.10.30.5/255.255.240.0 |
EoIB/Floating |
ComputNode1/IAMHOST1 |
WLS_SOA1 default channel |
Initially enabled in IAMHOST1 can be failed over by server migration to IAMHOST2. Used for Whole Server Migration only. |
|
OIMHOST2VHN2 |
bond0:3 |
10.10.30.8/255.255.240.0 |
EoIB/Floating |
ComputNode2/IAMHOST2 |
WLS_SOA2 default channel |
Initially enabled in ComputeNode3 can be failed over by server migration to IAMHOST1. Used for Whole Server Migration only. |
|
OIMHOST1VHN3 |
bond1:5 |
10.10.30.6/255.255.224.0 |
EoIB/Floating |
ComputNode1/IAMHOST1 |
WLS_BI1 Default Channel |
Initially enabled in IAMHOST1 can be failed over by server migration to IAMHOST2. Used for Whole Server Migration only. |
|
OIMHOST2VHN3 |
bond1:4 |
10.10.30.9/255.255.224.0 |
EoIB/Floating |
ComputNode2/IAMHOST2 |
WLS_BI1 Default Channel |
Initially enabled in IAMHOST2 can be failed over by server migration to IAMHOST1. Used for Whole Server Migration only. |
|
IAMHOST1-EXT |
bond1 |
10.10.10.1/255.255.240.0 |
EoIB/Fixed |
ComputNode1/IAMHOST1 |
NA |
A fixed IP allowing the compute node to be accessed by an External Load balancer |
|
IAMHOST2-EXT |
bond1 |
10.10.10.2/255.255.240.0 |
EoIB/Fixed |
ComputNode2/IAMHOST2 |
NA |
A fixed IP allowing the compute node to be accessed by an External Load balancer |
|
IDSTORE |
OTD |
192.168.50.3/255.255.224.0 |
IPoIB/Floating |
ComputNode2/IAMHOST2 |
NA |
Oracle Traffic Director failover group for Oracle Unified Directory |
Parent topic: Typical IAM Network Usage
Summary of Oracle Identity and Access Management Load Balancing Virtual Server Names
In order to distribute requests equally between servers, and to provide high availability, a hardware load balancer is required. The hardware load balancer should exist on redundant hardware to ensure maximum availability. The hardware load balancer is configured to recognize a set of virtual server names.
If you have configured your Exalogic appliance so that all traffic is using the EoIB network, your load balancer can be configured the same way as platform deployments. However, a better approach on Exalogic is to use Oracle Traffic Director for load balancing between internal components.
For information about the purpose of these server names, see Summary of the Typical Load Balancer Virtual Server Names.
The hardware load balancer in Oracle Identity and Access Management deployments recognizes 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
If you are using an external Web tier, this virtual host distributes requests among the external Web servers. Otherwise, it distributes requests between the internal Oracle Traffic Director servers.
-
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 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:
prov.example.com:443
If you are using an external Web tier, this virtual host distributes requests between the external Web servers. Otherwise, it distributes requests between the internal Oracle Traffic Director servers.
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 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 URL is not SSL-enabled. Clients access this service using the following address and the requests are forwarded to port 7777 on WEBHOST1 and WEBHOST2:
iadadmin.example.com:80
If you are not using external Web Servers, then this virtual host can be configured on Oracle Traffic Director rather than the hardware load balancer.
-
igdadmin.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. The services accessed on this virtual host include the WebLogic Administration Server Console, Oracle Enterprise Manager Fusion Middleware Control, and Identity Manager System Administration console.
The traffic from clients to this URL is not SSL-enabled. Clients access this service using the following address and the requests are forwarded to port 7777 on WEBHOST1 and WEBHOST2:
igdadmin.example.com:80
If you are not using external Web Servers, this virtual host can be configured on Oracle Traffic Director rather than the hardware load balancer.
-
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. Specifically, for the Oracle Identity and Access Management enterprise topology, this URL is used for both Oracle OIM Suite and Oracle SOA Suite internal communications.
The traffic from clients to this URL 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
If you are not using external Web Servers, then this virtual host can be configured on Oracle Traffic Director rather than the hardware load balancer.
-
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 URL is may or may not be SSL-enabled, depending on the type of LDAP directory in use, typically this is non-SSL enabled for Oracle Unified Directory. Clients access this service using the following address and the requests are forwarded to the LDAP instances.
This virtual host is configured on Oracle Traffic Director rather than the hardware load balancer.
-
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 4-4. These clusters function as active-active high availability configurations.
Table 4-4 Summary of Managed Servers and Clusters
Domain | Cluster | Managed Servers |
---|---|---|
IAMAccessDomain |
Oracle Access Manager |
WLS_OAM1, WLS_OAM2 |
NA |
Oracle Policy Manager |
WLS_AMA1, WLS_AMA2 |
IAMGovernanceDomain |
Oracle Identity Manager |
WLS_OIM1, WLS_OIM2 |
NA |
Oracle SOA Suite |
WLS_SOA1, WLS_SOA2 |
NA |
Oracle Web Service Manager |
WLS_WSM1, WLS_WSM2 |
Depending upon the components you select, the Oracle WebLogic Server domain for the Oracle Identity and Access Management consists of the clusters shown in …. These clusters function as active-active high availability configurations.
Parent topic: About the IAM Exalogic Enterprise Deployment
Understanding Oracle Traffic Director
Oracle Traffic Director (OTD) serves as a load balancer and a Web router. OTD is not a fully functional Web server, but can perform many tasks that a Web server performs. It is made up of an administration server, instances, and Failover Groups.
For information about installing and configuring Oracle Traffic Director, see Configuring Oracle Traffic Director for an Enterprise Deployment.
Topics:
- About Oracle Traffic Director in a Standard Exalogic Deployment
- About Oracle Traffic Director in a Deployment with Oracle HTTP Server
- About Oracle Traffic Director Failover Groups
- About Oracle Traffic Director and the Load Balancer
- About Oracle Traffic Director and Identity and Access Management
Parent topic: About the IAM Exalogic Enterprise Deployment
About Oracle Traffic Director in a Standard Exalogic Deployment
Oracle Traffic Directory is used to load balance requests to:
-
LDAP - Manage a Virtual IP Address that internal servers can access for the purposes of making LDAP calls.
Receive requests on the LDAP Virtual IP address and pass them on to the running LDAP instances using the IPoIB Network
-
Internal call backs - Manage a Virtual IP Address that internal servers can access for the purposes of making Inter application call backs
Receive requests on the Callback Virtual IP address and pass them on to the appropriate Weblogic Managed Servers using the IPoIB Network
The hardware load balancer sends requests to Oracle Traffic Director.
Oracle Traffic Director receives requests from the Load balancer and from internal applications requiring access to other internal applications or LDAP. Upon receipt of these requests, Oracle Traffic Director forwards them on to WebLogic Managed Servers or LDAP.
For more information about the standard Exalogic topology described in this guide, see Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies.
Parent topic: Understanding Oracle Traffic Director
About Oracle Traffic Director in a Deployment with Oracle HTTP Server
Oracle Traffic Directory is used to load balance requests to:
-
LDAP - Receive HTTP requests from the hardware load balancer on the EoIB network and forward them on to the WebLogic Managed Servers on the IPoIB network.
Manage a Virtual IP Address that internal servers can access for the purposes of making LDAP calls.
Receive requests on the LDAP Virtual IP address and pass them on to the running LDAP instances using the IPoIB Network.
-
Internal call backs - Manage a Virtual IP Address that internal servers can access for the purposes of making Inter application call backs.
Receive requests on the Callback Virtual IP address and pass them on to the appropriate Weblogic Managed Servers using the IPoIB Network.
A hardware load balancer sends requests to Oracle HTTP Server (OHS), which resides on commodity servers on the corporate ethernet network. The OHS then passes these requests onto WebLogic servers using the EoIB network.
Parent topic: Understanding Oracle Traffic Director
About Oracle Traffic Director Failover Groups
Oracle Traffic Director manages floating IP addresses for LDAP and internal callbacks on the IPoIB network. When a failover group is created, you specify the IP address netmasks you wish to use for a primary node and a failover node. It uses a heartbeat between instances to detect a failure.
For information about creating and configuring failover groups, see Creating a Failover Group for Virtual Hosts.
Parent topic: Understanding Oracle Traffic Director
About Oracle Traffic Director and the Load Balancer
You can configure the load balancer to point to Oracle Traffic Director instances. However, the load balancer failure detection is slower than using OTD failover groups. Therefore, Oracle recommends creating an external failover group for each Oracle Traffic Director instance and pointing the load balancer to the failover groups.
Parent topic: Understanding Oracle Traffic Director
About Oracle Traffic Director and Identity and Access Management
Oracle Traffic Director has its own WebGate, which is used for authentication. After WebGate is installed and configured, Oracle Traffic Director intercepts requests for the consoles and forwards them to Access Manager for validation.
Internal callbacks go back to failover groups to make efficient use of the Infiniband network.
Parent topic: Understanding Oracle Traffic Director
About Exalogic Optimizations for WebLogic
Exalogic offers the following optimizations for WebLogic:
Domain Level:
-
Check box in WebLogic Domain
-
Increased Network IO
-
Increased efficiency in session replication
-
Self-tuning thread pool
Cluster Level:
Creates a custom network replication channel for improved network throughput.
For more information about, and procedures for Exalogic Optimization see "WebLogic Server Domain Optimizations for Exalogic Elastic Cloud Software" in Administering WebLogic Server for Oracle Exalogic Elastic Cloud.
Parent topic: About the IAM Exalogic Enterprise Deployment
Roadmap for Implementing the Primary Oracle Identity and Access Management Topologies
Table 4-5 provides a roadmap for implementing the primary IAM suite topologies on Exalogic.
Table 4-5 Roadmap for Implementing Primary IAM Suite Topologies on Exalogic
Tasks | For More Information, See |
---|---|
Review the primary Exalogic enterprise topologies. |
|
Review the hardware and software requirements and procure the resources for the 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. |
|
Prepare the Exalogic machine. |
Preparing Exalogic for an Oracle Identity and Access Management Deployment |
Configure the host computers. |
|
Prepare the database. |
|
Configure Oracle LDAP. |
|
Create the Infrastructure domain for Oracle Access Management. |
|
Create the Infrastructure domain for Oracle Identity Governnance. |
|
Configure the Oracle Traffic Director. |
Configuring Oracle Traffic Director for an Enterprise Deployment |
Configure the Oracle Access Management. |
|
Configure the Oracle Identity Governance (OIG). |
|
Configure multi-data center setup. |
|
Configure server migration settings. |
Using Whole Server Migration and Service Migration in an Enterprise Deployment |
Configure Single Sign-On (SSO). |
Parent topic: About the IAM Exalogic 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 one provided in this guide, then 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.
Parent topic: About the IAM Exalogic Enterprise Deployment
About Installing and Configuring a Custom Enterprise Topology
If you choose to implement a topology that is not described in this guide, be sure to review the certification information, system requirements, and interoperability requirements for the products you want to include in the topology.
After you verify that the topology is supported, you can either use these instructions as a guide to installing and configuring the components you need, or you can install and configure a standard installation topology using the Oracle Fusion Middleware 11g installation guides and use the "Start Small and Scale Out" approach to configuring your environment.
Parent topic: About the IAM Exalogic Enterprise Deployment
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.
Parent topic: About the IAM Exalogic Enterprise Deployment