4 Networking Overview

This chapter describes the prerequisites for the Oracle Identity and Access Management Infrastructure enterprise deployment topology.

This chapter includes the following topics:

4.1 Overview of Preparing the Network for an Enterprise Deployment

You must configure several virtual servers and associated ports on the load balancer for different types of network traffic and monitoring. These virtual servers should be configured to the appropriate real hosts and ports for the services running. Also, the load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This ensures that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.

4.2 Planning Your Network

As shown in the deployment topology figures in Section 3.2, "Understanding the Oracle Identity Management Deployment Topology on Exalogic," each deployment can be spread across multiple zones. A zone is a means of restricting access to components of your infrastructure to those that actually need it. In the examples in this guide, two zones are shown.

  • The public zone–This is where the outside world gains access to your systems. You place into this zone only those components that the outside world must access, such as the Load Balancers and Web Tiers. If users from the outside world attempts to access any servers or services below this zone, they are prevented from doing so by firewalls.

    The public zone is configured so that the servers in this zone can interact with the application servers in the private zone.

  • The intranet zone–This is where you place servers that contain core services, such as databases. These services are very tightly controlled by the organization as they contain the most sensitive data.

By using this approach, you restrict access to information to only those components that require it. This approach is useful where you have users coming in from outside of your organization.

In an Exalogic Deployment the use of Zones can be achieved by using different VLANs.

4.3 Virtual Server Names Used by the Topology

Virtual Server names are used to hide the identities of the real host names used by the organization, and are used as the entry points into the applications.

One benefit of using virtual server names is that the backend server names can change without the application having to be reconfigured with new host names.

Another advantage of using virtual server names is that these server names can be attached to a load balancer, allowing the load balancer to use a single name to distribute requests amongst a number of back end servers which serve the same function. This ensures availability and simplified scalability.

When attached to a load balancer the load balancer can also terminate SSL allowing the applications to maintain encrypted traffic between the application and the client but at the same time to allow the application to perform more efficiently without having to encrypt traffic between each component.

Virtual Server names are included in the organizations DNS servers. External application entries are configured in external DNS servers.

This ensures that public access points are resolvable in the internet and private access points available only inside the organization.

Some of the virtual servers, such as IDSTORE.mycompany.com and IDMINTERNAL.mycompany.com, you may wish to exclude from DNS altogether and to resolve only those servers you are using.

Both:

Virtual Server Names resolve to a single IP address. This IP address can be associated with a virtual host on a load balancer.

Exalogic:

With Exalogic, these IP Addresses may be associated with Oracle Traffic director.

Ensure that the virtual server names are associated with IP addresses and are part of your DNS. The computers on which Oracle Fusion Middleware is running must be able to resolve these virtual server names.

You define the virtual server names on the load balancer using the procedure in Section 4.4, "Configuring the Hardware Load Balancers"

The rest of this guide assumes that the deployment is one of those shown in Chapter 3, "Introduction and Planning."

4.3.1 IDSTORE.mycompany.com

  • Because your Identity Store in Oracle Unified Directory is accessed directly, you must monitor the heartbeat of the Oracle Unified Directory processes. If an Oracle Unified Directory process stops, the load balancer must continue to route the LDAP traffic to a surviving Oracle Unified Directory instance.

  • This virtual server directs traffic received on port 1489 (LDAP_LBR_PORT) to each of the Oracle Unified Directory instances on port 1389 (LDAP_DIR_PORT).

  • This virtual server directs traffic received on port 1636 (LDAP_LBR_SSL_PORT) to each of the Oracle Unified Directory instances on port 1636 (LDAP_DIR_SSL_PORT).

  • This virtual server is resolvable only locally (in Exalogic).

  • In an Exalogic Deployment, IDSTORE load-balancing is undertaken by Oracle Traffic Director.

4.3.2 IADADMIN.mycompany.com

  • This virtual server acts as the access point for all internal HTTP traffic that gets directed to the administration services in the Access Domain. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address IADADMIN.mycompany.com:80 and in turn forward these to port 7777 (WEB_HTTP_PORT) on WEBHOST1 and WEBHOST2, or OHSHOST1 and OHSHOST2 on the Exalogic OHS Topology. The services accessed on this virtual host include the WebLogic Administration Server Console and Oracle Enterprise Manager Fusion Middleware Control.

  • This virtual server is resolvable in the corporate DNS only.

  • Create rules in the firewall to block outside traffic from accessing the /console, /oamconsole, /oaam_admin, and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the IADADMINVHN.mycompany.com virtual host.

4.3.3 IGDADMIN.mycompany.com

  • This virtual server acts as the access point for all internal HTTP traffic that gets directed to the administration services in the Governance Domain. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address IGDADMIN.mycompany.com:80 (HTTP_PORT) and in turn forward these to ports 7777 (WEB_HTTP_PORT) on WEBHOST1 and WEBHOST2 or OHSHOST1 and OHSHOST2 in the Exalogic OHS Topology. The services accessed on this virtual host include the WebLogic Administration Server Console, and Oracle Enterprise Manager Fusion Middleware Control,and Oracle Authorization Policy Manager.

  • Create rules in the firewall to block outside traffic from accessing the /sysadmin, /apm, /console and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the IGDADMINVHN.mycompany.com virtual host.

  • This virtual server should be resolvable only in the corporate DNS.

4.3.4 IDMINTERNAL.mycompany.com

  • This virtual server acts as the access point for all internal HTTP traffic that gets directed to OIM and SOA. The incoming traffic from clients is not SSL enabled. The the clients access this service using the address idminternal.mycompany.com:80 and Oracle Traffic Director in turn forwards these to the appropriate WebLogic managed servers.

  • Create rules in the firewall to block outside traffic from accessing this virtual host. Only traffic inside the DMZ should be able to access these URLs on the IDMINTERNAL.mycompany.com virtual host.

  • This virtual server should be resolvable either locally or in the corporate DNS

  • Because IDMINTERNAL is designed for interprocess communication, you might want to NOT include this in DNS, but have it resolvable only in internal host files.

  • In an Exalogic Deployment, IDMINTERNAL load-balancing is undertaken by Oracle Traffic Director.

4.3.5 SSO.mycompany.com

  • This is the virtual name which fronts all Identity and Access Management components, including Access Manager and Oracle Identity Manager.

  • This virtual server acts as the access point for all HTTP traffic that gets directed to the single sign on services. The incoming traffic from clients is SSL enabled. Thus, the clients access this service using the address SSO.mycompany.com:443 and in turn forward these to port 7777 (WEB_HTTP_PORT) on WEBHOST1 and WEBHOST2 or OHSHOST1 and OHSHOST2 in the Exalogic OHS Topology. All the single sign on enabled protected resources are accessed on this virtual host.

  • Configure this virtual server in the load balancer with both port 80 (HTTP_PORT) and port 443 (HTTP_SSL_PORT).

  • This virtual server should be resolvable either locally or in the corporate DNS

  • This virtual host must be configured to preserve the client IP address for a request. In some load balancers, you configure this by enabling the load balancer to insert the original client IP address of a request in an X-Forwarded-For HTTP header.

4.4 Configuring the Hardware Load Balancers

A hardware load balancer directs requests to the application in this case Oracle Identity and Access Management to the individual hosts which make up the application components.

A load balancer is configured with virtual hosts. Each virtual host is associated with a different IP address, which is serviced by the load balancer. The Load balancer virtual host is then associated with a pool of origin servers consisting of the web servers in the deployment.

When configuring a load balancer, you must set up a virtual host for each of the virtual servers, as described in Section 4.4.3, "Load Balancer Configuration for Exalogic."

In an Exalogic implementation some of these virtual servers will be enabled on Oracle Traffic Director rather than on the Load balancer.

Virtual servers and associated ports must be configured on the load balancer for different types of network traffic and monitoring. These should be configured to route request to the appropriate real hosts and ports running the services. The load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This ensures that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.

There are two load balancer devices in the recommended topology. One load balancer is set up for external HTTP traffic and the other load balancer is set up for internal LDAP traffic. A deployment may choose to have a single load balancer device due to a variety of reasons. While this is supported, the deployment should consider the security implications of doing this and if found appropriate, open up the relevant firewall ports to allow traffic across the various zones. It is worth noting that in either case, it is highly recommended to deploy a given load balancer device in fault tolerant mode.

This section contains the following topics:

4.4.1 Load Balancer Requirements

The enterprise topology uses an external load balancer. This external load balancer must have the following features:

  • Ability to load-balance traffic to a pool of real servers through a virtual server name: Clients access services using the virtual server name (instead of using actual server names). The load balancer can then load balance requests to the servers in the pool.

  • Port translation configuration.

  • Monitoring of ports (HTTP and HTTPS).

  • Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:

    • The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for Oracle WebLogic Clusters, the load balancer must be configured with a virtual server and ports for HTTP and HTTPS traffic.

    • The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through the virtual server names.

  • Ability to detect node failures and immediately stop routing traffic to the failed node.

  • Resource monitoring / port monitoring / process failure detection: The load balancer must be able to detect service and node failures (through notification or some other means) and to stop directing non-Oracle Net traffic to the failed node. If your external load balancer has the ability to automatically detect failures, you should use it.

  • Fault tolerant mode: It is highly recommended that you configure the load balancer to be in fault-tolerant mode.

  • Sticky routing capability: Ability to maintain sticky connections to components based on cookies or URL.

  • Other: It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the back-end services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.

  • SSL acceleration, which refers to off loading the public-key encryption algorithms involved in SSL transactions to a hardware accelerator. This feature is recommended, but not required.

  • Ability to terminate SSL requests at the load balancer and forward traffic to the backend real servers using the equivalent non-SSL protocol. For example, the load balancer must be able to forward HTTPS requests as HTTP. This feature is sometimes called "SSL termination." It is required for this Enterprise Deployment.

  • Ability to Preserve the Client IP Addresses: The Load Balancer must have the capability to insert the original client IP address of a request in an X-Forwarded-For HTTP header to preserve the Client IP Address.

  • Ability to add WL-Proxy-SSL: true to the HTTP Request Header. Some load balancers do this automatically.

4.4.2 Load Balancer Configuration Procedures

The procedures for configuring a load balancer differ, depending on the specific type of load balancer. Refer to the vendor supplied documentation for actual steps. The following steps outline the general configuration flow:

  1. Create a pool of servers. This pool contains a list of servers and the ports that are included in the load balancing definition. For example, for load balancing between the web hosts you create a pool of servers which would direct requests to the web servers in the topology which accept requests using port 7777 (WEB_HTTP_PORT).

  2. Create rules to determine whether or not a given host and service is available and assign it to the pool of servers described in Step 1.

  3. Create a Virtual Server on the load balancer. This is the address and port that receives requests used by the application. For example, to load balance Web Tier requests you would create a virtual server for SSO.mycompany.com:80.

  4. If your load balancer supports it, specify whether or not the virtual server is available internally, externally or both. Ensure that internal addresses are only resolvable from inside the network.

  5. Configure SSL Termination, if applicable, for the virtual server.

  6. Assign the Pool of servers created in Step 1 to the virtual server.

  7. Tune the time out settings as listed in Table 4-3, "Ports Used in the Exalogic Reference Topology". This includes time to detect whether a service is down.

4.4.3 Load Balancer Configuration for Exalogic

For an Identity Management deployment, configure your load balancer as shown in Table 4-1.

Table 4-1 Load Balancer Configuration Details

Virtual Servers Server PoolFoot 1  Server Pool (External OHS) Protocol SSL Termination External Other Required Configuration/Comments

SSO.mycompany.com:80 (HTTP_SSL_PORT)

WEBHOST1VHN1.mycompany.com:7777 WEBHOST2VHN1.mycompany.com:7777

OHSHOST1.mycompany.com:7777 OHSHOST2.mycompany.com:7777

HTTP

No

Yes

  

SSO.mycompany.com:443 (HTTP_SSL_PORT)

WEBHOST1VHN1.mycompany.com:7777 WEBHOST2VHN1.mycompany.com:7777

OHSHOST1.mycompany.com:7777 OHSHOST2.mycompany.com:7777

HTTP

Yes

Yes

Identity Management requires that the following be added to the HTTP header:

Header Name: IS_SSLFoot 2 

Header Value: ssl

Header Name: WL-Proxy-SSL

Header Value: true

IADADMIN.mycompany.com:80 HTTP_PORT

WEBHOST1VHN1.mycompany.com:7777 WEBHOST2VHN1.mycompany.com:7777

OHSHOST1.mycompany.com:7777 OHSHOST2.mycompany.com:7777

HTTP

No

No

  

IGDADMIN.mycompany.com:80 HTTP_PORT

WEBHOST1VHN1.mycompany.com:7777 WEBHOST2VHN1.mycompany.com:7777

OHSHOST1.mycompany.com:7777 OHSHOST2.mycompany.com:7777

HTTP

No

No

  

Footnote 1 If you do not want to use an OTD failover group for faster failover detection, substitute WEBHOST1-VHN and WEBHOST2-VHN with the host names corresponding to the client access network. For example: IAMHOST1EXT and IAMHOST2EXT.

Footnote 2 For information about configuring IS_SSL, see "About User Defined WebGate Parameters" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

4.5 About IP Addresses and Virtual IP Addresses

A virtual IP address is an unused IP Address which belongs to the same subnet as the host's primary IP address. It is assigned to a host manually and Oracle WebLogic Managed servers are configured to listen on this IP Address. In the event of the failure of the node where the IP address is assigned, the IP address is assigned to another node in the same subnet, so that the new node can take responsibility for running the managed servers assigned to it. In other words, these virtual IP addresses are associated with a virtual host name. That way, should it be required, the underlying IP address can be changed.

The examples below show the virtual host names required by this document. These are associated with a virtual IP address as described above.

The following is a list of the virtual servers required by Oracle Identity and Access Management:

  • IADADMINVHN.mycompany.com

    In Enterprise deployments the WebLogic Administration Server must be able to continue processing requests after the host it is residing on fails. A virtual IP address should be provisioned in the application tier so that it can be bound to a network interface on any host in the application tier. The WebLogic Administration Server is configured later to listen on this virtual IP address, as discussed later in this manual. The virtual IP address fails over along with the Administration Server from OAMHOST1 to OAMHOST2, or vice versa.

  • IGDADMINVHN.mycompany.com

    In Enterprise deployments the WebLogic Administration Server must be able to continue processing requests after the host it is residing on fails. A virtual IP address should be provisioned in the application tier so that it can be bound to a network interface on any host in the application tier. The WebLogic Administration Server is configured later to listen on this virtual IP address, as discussed later in this manual. This virtual IP address fails over along with the Administration Server from OIMHOST1 to OIMHOST2, or vice versa.

  • SOAHOSTxVHN.mycompany.com

    One virtual IP address is required for each SOA managed server. This enables the servers to participate in Server migration.

    Provision a virtual IP address in the application tier so that it can be bound to a network interface on any host in the application tier.

  • OIMHOSTxVHN.mycompany.com

    One virtual IP Address is required for each Oracle Identity Manager managed server. This enables the servers to participate in Server migration.

    Provision a virtual IP address in the application tier so that it can be bound to a network interface on any host in the application tier.

Configure the Administration Server and the managed servers to listen on different virtual IPs and physical IPs as illustrated in Figure 4-1.

Figure 4-1 Exalogic Physical IP Addresses and VIP Addresses

Surrounding text describes Figure 4-1 .

Figure 4-2 IP Addresses and VIP Addresses–Exalogic Virtual

Surrounding text describes Figure 4-2 .

The following table provides descriptions of the various virtual hosts.

Table 4-2 Exalogic VIP Addresses and Virtual Hosts

Virtual IP VIP Maps to... Description (Consolidated) Default Host (Physical) Default Host (Virtual)

VIP1

IADADMINVHN

IADADMINVHN is the virtual host name that is the listen address for the Administration Server and fails over with manual failover of the Administration Server. It is enabled on the node where the Administration Server process is running.

IAMHOST1

OAMHOST1

VIP2

IGDADMINVHN

IGDADMINVHN is the virtual host name that is the listen address for the Oracle Identity Manager Administration Server. It fails over with manual failover of the Administration Server. It is enabled on the node where the Oracle Identity Manager Administration Server process is running.

IAMHOST1

OIMHOST1

VIP3

SOAHOST1VHN

SOAHOST1VHN is the virtual host name that maps to the listen address for WLS_SOA1 and fails over with server migration of this managed server. It is enabled on the node where WLS_SOA1 process is running.

IAMHOST1

OIMHOST1

VIP4

OIMHOST1VHN

OIMHOST1VHN is the virtual host name that maps to the listen address for the WLS_OIM1 server and fails over with server migration of this server. It is enabled in the node where the WLS_OIM1 process us running.

IAMHOST1

OIMHOST1

VIP5

SOAHOST2VHN

SOAHOST2VHN is the virtual host name that maps to the listen address for WLS_SOA2 and fails over with server migration of this managed server. It is enabled on the node where WLS_SOA2 process is running.

IAMHOST2

OIMHOST2

VIP6

OIMHOST2VHN

OIMHOST2VHN is the virtual host name that maps to the listen address for the WLS_OIM2 server and fails over with server migration of this server. It is enabled in the node where the WLS_OIM2 process us running.

IAMHOST2

OIMHOST2

4.6 Configuring Firewall Ports

Many Oracle Fusion Middleware components and services use ports. As an administrator, you must know the port numbers used by these services, and to ensure that the same port number is not used by two services on a host.

Most port numbers are assigned during installation.

Table 4-3, "Ports Used in the Exalogic Reference Topology" lists the ports used in the Oracle Exalogic deployment reference topology, including the ports that you must open on the firewalls in the topology.

Firewall notation:

  • FW0 refers to the outermost firewall.

  • FW1 refers to the firewall between the web tier and the application tier.

  • FW2 refers to the firewall between the application tier and the data tier.

Table 4-3 Ports Used in the Exalogic Reference Topology

Type Firewall Port and Port Range Protocol / Application Inbound / Outbound Other Considerations and Timeout Guidelines

Browser request

FW0

80

HTTP / Load Balancer

Inbound

Timeout depends on all HTML content and the process models used for the Oracle Fusion Middleware products you are using in the Exalogic environment.

Browser request

FW0

443

HTTPS / Load Balancer

Inbound

Timeout depends on all HTML content and the process models used for the Oracle Fusion Middleware products you are using in the Exalogic environment.

Load balancer to Oracle Traffic Director

n/a

7777

HTTP

n/a

Timeout depends on all HTML content and the process models used for the Oracle Fusion Middleware products you are using in the Exalogic environment.

IAMAccess Domain Administration Console access

FW1

7001

HTTP / Administration Server and Enterprise Manager

Both

You should tune this timeout based on the type of access to the Administration console (whether it is planned to use the Oracle WebLogic Server Administration Console from application tier clients or clients external to the application tier).

IAMAccess Domain Administration Console SSL access

FW1

7002

HTTP / Administration Server and Enterprise Manager

Both

You should tune this timeout based on the type of access to the Administration console (whether it is planned to use the Oracle WebLogic Server Administration Console from application tier clients or clients external to the application tier).

IAMGovernance Domain Administration Console access

FW1

7101

HTTP / Administration Server and Enterprise Manager

Both

You should tune this timeout based on the type of access to the Administration console (whether it is planned to use the Oracle WebLogic Server Administration Console from application tier clients or clients external to the application tier).

IAMGovernance Domain Administration Console SSL access

FW1

7102

HTTP / Administration Server and Enterprise Manager

Both

You should tune this timeout based on the type of access to the Administration console (whether it is planned to use the Oracle WebLogic Server Administration Console from application tier clients or clients external to the application tier).

Coherence

n/a

8088

Range: 8080 - 8090

  

n/a

n/a

Application tier to data tier (Oracle database or RAC outside of Oracle Exalogic machine via Ethernet)

FW2

1521

  

n/a

n/a

Managed Server Access (WLS_OAM1, WLS_OAM2, WLS_OIM1. WLS_OIM2, WLS_SOA1, WLS_SOA2)

FW1

WLS_OAMn: 14100

WLS_OIMn: 14000

WLS_SOAn: 8001

HTTP

Inbound

Managed Servers, which use bond1 floating IP addresses, are accessed via Oracle HTTP Server. Only required if the topology has external Oracle HTTP Servers.

4.7 Managing Access Manager Communication Protocol

This section discusses Oracle Access Protocol (OAP) and provides an overview of a user request.

This section contains the following topics:

4.7.1 Access Manager Protocols

Oracle Access Protocol (OAP) enables communication between Access System components (for example, Access Manager Server, WebGate) during user authentication and authorization. This protocol was formerly known as NetPoint Access Protocol (NAP) or COREid Access Protocol.

4.7.2 Overview of Integration Requests

Oracle Access Management Access Manager is responsible for creating sessions for users. When Access Manager is integrated with another Identity and Access Management component, such as Oracle Identity Manager, authentication is delegated to that component.

A typical request flow is as follows:

  1. The user tries to access a resource for the first time.

  2. WebGate intercepts the request and detects that the user is not authenticated.

  3. Access Manager credential collector is invoked and the user enters a user name and password in response to a prompt. Access Manager knows that password policy requires the password to be changed at first login, so the user's browser is redirected to Oracle Identity Manager.

  4. The user is prompted to change password and set up challenge questions.

  5. At this point, Oracle Identity Manager has authenticated the user using the newly entered password. Oracle Identity Manager creates a TAP request to say that Access Manager can create a session for the user. That is, the user will not be expected to log in again. This is achieved by adding a token to the user's browser that Access Manager can read.

    The TAP request to Access Manager will include such things as:

    • Where the Access Manager servers are located.

    • What web gate profile to use.

    • WebGate profile password.

    • Certificates, if Access Manager is working in simple or cert mode.

4.7.3 Overview of User Request

The request flow when a user requests access is as follows:

  1. The user requests access to a protected resource over HTTP or HTTPS.

  2. The WebGate intercepts the request.

  3. The WebGate forwards the request to the Access Manager Server over Oracle Access Protocol to determine if the resource is protected, how, and whether the user is authenticated (if not, there is a challenge).

  4. The Access Manager Server checks the directory server for credentials such as a user ID and password, sends the information back to WebGate over Oracle Access Protocol, and generates an encrypted cookie to authenticate the user.

  5. Following authentication, the WebGate prompts the Access Manager Server over Oracle Access Protocol and the Access Manager Server looks up the appropriate security policies, compares them to the user's identity, and determines the user's level of authorization.

    • If the access policy is valid, the user is allowed to access the desired content and/or applications.

    • If the policy is false, the user is denied access and redirected to another URL determined by the organization's administrator.

4.7.4 About the Multicast Requirement for Communication

Oracle recommends that the nodes in the topology communicate using unicast communication. Unlike multicast communication, unicast does not require cross-network configuration. Using unicast avoids network errors due to multicast address conflicts.

In unicast messaging mode, the default listening port of the server is used if no channel is configured. Cluster members communicate to the group leader when they need to send a broadcast message which is usually the heartbeat message. When the cluster members detect the failure of a group leader, the next oldest member becomes the group leader. The frequency of communication in unicast mode is similar to the frequency of sending messages on multicast port.

The following considerations apply when using unicast to handle cluster communications:

  • All members of a WebLogic cluster must use the same message type. Mixing multicast and unicast messaging is not allowed.

  • Individual cluster members cannot override the cluster messaging type.

  • The entire cluster must be shut down and restarted to change the message modes from unicast to multicast or from multicast to unicast.

  • JMS topics configured for multicasting can access WebLogic clusters configured for unicast because a JMS topic publishes messages on its own multicast address that is independent of the cluster address. However, the following considerations apply:

    • The router hardware configurations that allow unicast clusters may not allow JMS multicast subscribers to work.

    • JMS multicast subscribers need to be in a network hardware configuration that allows multicast accessibility. (That is, JMS subscribers must be in a multicast-enabled network to access multicast topics.

Note:

Although you can set up cluster communication using Unicast, Oracle Identity Manager depends upon Multicast when it is used for caching. For that reason, you must enable multicast between the machines.

4.8 Exalogic Networking

This section describes details of Exalogic Networking.

This section includes the following topics:

4.8.1 Map of the Network Interfaces Used by the Components of the IAM Topology on Exalogic

As described in Chapter 2, "Introduction to Oracle Identity and Access Management on Exalogic," the Exalogic Machine has a number of networks. In an Exalogic deployment, network traffic is confined to the internal network as much as is possible. This ensures that network traffic is not flooding the corporate network and adds an extra layer of security by ensuing host name resolution is only available where it is needed. For example idminternal is only resolvable inside the exalogic machine, this prevents direct corporate access using this communication channel.

Table 4-4 shows how the communication of Oracle Identity and Access components use these networks. Sample IP address ranges have been used to differentiate the different IP Address usages.

Where possible, different vnets are used to further compartmentalise network traffic.

Table 4-4 Internal and External IP Addresses

Purpose Network IP Addresses Netmask

External Compute Node Addresses

EoIB

10.10.10.x

255.255.224.0

External Floating Physical IP Addresses

EoIB

10.10.30.x

255.255.224.0

External Floating Oracle Traffic Director IP Addresses

EoIB

10.10.50.x

255.255.224.0

Internal Compute/vServer Node Addresses

IPoIB

192.168.10.x

255.255.224.0

Internal Storage Addresses

IPoIB

192.168.32.x

255.255.224.0

Exadata Network

IPoIB

192.168.10.x

255.255.224.0

Internal Floating Physical IP Addresses

IPoIB

192.168.30.x

255.255.240.0

Internal Oracle Traffic Director Addresses

IPoIB

192.168.50.x

255.255.224.0

Notes:

  • The external IP addresses in Table 4-4 are assumed to be on the client access network.

  • The subnets used here are examples only. It may be possible to use these subnets, the externally facing subnets. Follow the standards used in your organization. In virtual Exalogic, internal network IP addresses are determined by the Exalogic Elastic Cloud software when a private network is created. These are referred to as bondx (where x is a sequential number).

For more information about the network map diagram, see the following:

4.8.2 Preparing the Network for an Exalogic Enterprise Deployment

To continue preparing your network, refer to either Chapter 5, "Configuring Exalogic Networking for a Physical Environment" or Chapter 6, "Configuring Exalogic Networking for a Virtual Environment," depending on which type of environment you are configuring.