3 Introduction and Planning

This chapter describes and illustrates the enterprise deployment reference topology described in this guide and helps you plan your deployment.

This chapter contains the following topics:

• Section 3.1, "Planning Your Deployment"

• Section 3.2, "Understanding the Oracle Identity Management Deployment Topology on Exalogic"

• Section 3.3, "Understanding the Topology Components"

• Section 3.4, "About Oracle Directory Services Manager"

• Section 3.5, "Benefits of Using the Split Domain Topology"

• Section 3.6, "Hardware Requirements for the Identity Management on Exalogic"

• Section 3.7, "Software Components for an Enterprise Deployment"

• Section 3.8, "Road Map for the Reference Topology Installation and Configuration"

3.1 Planning Your Deployment

This section provides information to help you plan the deployment of Oracle Identity Management on Exalogic:

• Section 3.1.1, "Why the Deployment Topology in This Guide?"

• Section 3.1.2, "Using a Worksheet to Plan for the Deployment Topology"

3.1.1 Why the Deployment Topology in This Guide?

When planning your deployment, you should be aware that this guide provides detailed instructions for implementing the specific reference topology described in this chapter.

This topology takes advantage of key features of the Exalogic platform, including:

• The high bandwidth and performance of the Exalogic internal Infiniband (IPoIB) network fabric

• The software load balancing capabilities of Oracle Traffic Director.

In this specific topology, Oracle Traffic Director is used as both a Web Listener and as a client-side load balancer for internal communication.

By using this configuration, you can take advantage of the Exalogic default IPoIB network for all internal communications between the Traffic Director instances and the Identity and Access Management compute nodes.

Only external traffic between the Traffic Director instances and external users is on the Exalogic Ethernet over IB (EoIB) network.

3.1.2 Using a Worksheet to Plan for the Deployment Topology

The key to a successful Enterprise Deployment is planning and preparation. The road map for installation and configuration in this chapter directs you to the appropriate chapters for the tasks you need to perform.

Use this chapter to help you plan your Oracle Identity and Access Management enterprise deployment on an Exalogic platform.

You can also use the worksheets in Section 11.1, "Assembling Information for Identity and Access Management Deployment" to help you keep track of information, such as host names, IP addresses, and other important information as you procure and identify the machines and resources required for this deployment.

3.2 Understanding the Oracle Identity Management Deployment Topology on Exalogic

A topology is a deployment map of components. There are several different ways that Oracle Identity and Access Management components can be installed to provide a working Identity and Access management solution. A topology can also be described as an architectural blueprint. This guide shows common deployment topologies for Oracle Identity and Access Management.

The following information applies to all the topologies described in this guide.

• Users submit requests to Oracle Identity Management from their client browsers. Each request originates as an SSL request, ensuring that the request is encrypted. The request is routed to a load balancer in the corporate DMZ.

• Upon receiving the request the Load Balancer decrypts the encrypted request and then passes this on to WEBHOST1 or WEBHOST2 using a non encrypted transaction.

• Traffic leaving the organization to go back to the client is encrypted into SSL by the load balancer.

• Terminating SSL at the load balancer ensures that optimum performance is achieved due to the fact that SSL traffic is processed entirely by the load balancer.

• A firewall exists between the DMZ and the Exalogic host to ensure that only valid traffic can enter and leave the Application Zone. Additionally a second firewall exists partitioning the network from the Application Tier to the Data Tier to ensure that only valid traffic is allowed to pass from the application tier to the database tier.

• Each of the deployment topologies is divided into 3 Zones.

  • The Demilitarized Zone (DMZ) which is accessible from the public internet. This is the entry point to the organization for client requests.

  • The Application Tier which is only accessible via the DMZ. Client traffic does not have direct access to the Application Tier.

  • The Data Tier which is only accessible via the application tier. Client traffic does not have direct access to the data tier.

  By compartmentalizing the topology in this way, you prevent unauthorized traffic from gaining access to a zone to which it is not entitled.

• The load balancer is used in conjunction with DNS to ensure that applications are only available to those that need it. The entry point sso.mycompany.com is available in the public dns and as such everyone has access to it as this is where authentication takes place.

• The urls IADADMIN.mycompany.com and IGDADMIN.mycompany.com are used to direct traffic to the administrative consoles within the application. These names are only resolvable in the corporate DNS. This ensures that external clients trying to access administrative resources cannot do so because the URLs are non resolvable. Only traffic originating inside the corporate network will be able to access these administrative functions thereby adding another layer of security to the system.

This section contains the following topics:

• Section 3.2.1, "Primary Topologies"

• Section 3.2.2, "Alternative Deployment Topologies"

3.2.1 Primary Topologies

This guide shows two main deployment models. The first uses a physical Exalogic deployment, which is an Exalogic Rack which is used in its native form. In a physical Exalogic deployment, the compute nodes are so powerful that the entire Identity and Access Management suite can be deployed onto a single compute node, with a second compute node being used to provide high availability.

The second topology described in the guide describes where the Exalogic Rack has been virtualized using the Exalogic Elastic Cloud software. In this environment, instead of using the physical compute nodes directly, virtual servers are created and run on a number of compute nodes within the rack. For this type of deployment, the Identity and Access Management components are distributed across a number of virtual servers (vServers).

3.2.1.1 Physical Exalogic Deployment Topology

Figure 3-1 Exalogic Physical Deployment Topology

This figure is a graphical representation of the Physical Exalogic Deployment topology. It includes icons and symbols that represent the hardware load balancer, compute nodes, firewalls, and other elements of the topology.

At a high level, it shows the main components of the topology, including the following:

• The Web Tier, which contains a hardware load balancer which receives requests on SSO.mycompany.com, IADADMIN.mycompany.com and IGDADMIN.com and forwards them on to the Oracle Traffic Director instances on IAMHOST1 and IAMHOST2. In the case of SSO.mycompany.com, requests are SSL encrypted. SSO.mycompany.com handles requests using the HTTP protocol.

• The Application Tier, where the application servers reside, including Oracle WebLogic Server and the upper stack products, such as Oracle SOA Suite. In this specific topology, the compute nodes are referred to as IAMHOST1 and IAMHOST2.

  • Oracle Traffic Director. This topology uses Oracle Traffic director as both a web server and an internal load balancer.

  • Oracle Unified Directory. Each host has an instance of Oracle Unified Directory which is used as the LDAP directory for identity information. Each Oracle Unified Directory instance is kept up to date through Oracle Unified Directory replication.

  • WebLogic Domain: IAMAccessDomain, which consists of:

    • Oracle Access Management, which hosts Access Server/Federation Server and corresponding JRF/OPSS processes.

    • Optional Oracle Adaptive Access Manager

    • WebLogic Administration Server, which hosts the WebLogic Console for IAMAccessDomain, Oracle Enterprise Manager Fusion Middleware Control, and Access Management Console. In the event of the failure of IAMHOST1, the WebLogic Administration Server can be started on IAMHOST2.

  • WebLogic Domain: IAMGovernanceDomain, which consists of:

    • Oracle Identity Manager, which hosts an OIM Server and corresponding JRF/OPSS processes

    • SOA, which hosts a SOA Server and corresponding JRF/OPSS processes

    • WebLogic Administration Server, which hosts the Oracle WebLogic Console for IAMGovernanceDomain, Oracle Enterprise Manager Fusion Middleware Control, and Authorization Policy Manager (APM). In the event of the failure of IAMHOST1, the WebLogic Administration Server can be started on IAMHOST2.

• The Data Tier is where the databases reside. The database tier can either be on external database servers or an attached Exadata Appliance.The databases contain customer data and the schemas required by the application tier products.

• Firewalls are used to separate the Web, Application, and Directory tiers into different zones.

Note:

If an ExaLogic machine is hard wired to an Exadata machine then there is no need for a firewall restricting traffic between the Application and data tiers. All traffic is kept to the internal IPoIB network.

For more information, refer to the descriptions of the topology tiers in the sections that follow the diagrams. The instructions in this guide describe how to install and configure the software for this topology.

3.2.1.2 Virtual Exalogic Deployment Topology

Figure 3-2 Exalogic Virtual Deployment Topology

This figure is a graphical representation of the Virtual Exalogic Deployment topology. It includes icons and symbols that represent the hardware load balancer, vServers, firewalls, and other elements of the topology. At a high level, it shows the main components of the topology, including the following:

• The Web Tier, which contains a hardware load balancer which receives requests on SSO.mycompany.com, IADADMIN.mycompany.com and IGDADMIN.com and forwards them on to the Oracle Traffic Director instances on WEBHOST1 and WEBHOST2.

  Inside the demilitarized zone (DMZ) is a load balancer which directs requests received on SSO.mycompany.com and directs requests to Oracle Traffic Director. In the case of SSO.mycompany.com, requests are SSL encrypted. This is terminated at the load balancer. SSO.mycompany.com handles requests using the HTTP protocol.

• The Application Tier, where the application servers reside, including Oracle WebLogic Server and the upper stack products, such as Oracle SOA Suite. In this specific topology, there are six vServers, referred to as WEBHOST1, WEBHOST2, OAMHOST1, OAMHOST2, OIMHOST1, and OIMHOST2.

  • Oracle Traffic Director. This topology uses Oracle Traffic Director as both a web server and an internal load balancer. The Oracle Traffic Director instances reside on WEBHOST1 and WEBHOST2.

  • Oracle Unified Directory. Each host has an instance of Oracle Unified Directory which is used as the LDAP directory for identity information. Each Oracle Unified Directory instance is kept up to date through Oracle Unified Directory replication. the Oracle Unified Directory instances reside on OAMHOST1 and OAMHOST2.

  • WebLogic Domain: IAMAccessDomain, which consists of:

    • Oracle Access Management, which hosts Access Server/Federation Server and corresponding JRF/OPSS processes.

    • Optional Oracle Adaptive Access Manager

    • WebLogic Administration Server, which hosts the WebLogic Console for IAMAccessDomain, OAM Console, and Oracle Enterprise Manager Fusion Middleware Control.

    The IAMAccessDomain servers reside on OAMHOST1 and OAMHOST2. In the event of the failure of OAMHOST1, the WebLogic Administration Server can be started on OAMHOST2.

  • WebLogic Domain: IAMGovernanceDomain, which consists of:

    • Oracle Identity Manager, which hosts an OIM Server and corresponding JRF/OPSS processes

    • SOA, which hosts a SOA Server and corresponding JRF/OPSS processes

    • WebLogic Administration Server, which hosts the WebLogic Console for IAMGovernanceDomain, Oracle Enterprise Manager Fusion Middleware Control, and Authorization Policy Manager (APM).

    The IAMGovernanceDomain servers reside on OIMHOST1 and OIMHOST2. In the event of the failure of OIMHOST1, the WebLogic Administration Server can be started on OIMHOST2.

• The Data Tier is where the databases reside. The database tier can either be on external database servers or an attached Exadata Appliance.The databases contain customer data and the schemas required by the application tier products.

• Firewalls are used to separate the Web, Application, and Directory tiers into different zones.

Note:

If an ExaLogic machine is hard wired to an Exadata machine then there is no need for a firewall restricting traffic between the Application and data tiers. All traffic is kept to the internal IPoIB network.

For more information, refer to the descriptions of the topology tiers in the sections that follow the diagrams. The instructions in this guide describe how to install and configure the software for this topology.

3.2.2 Alternative Deployment Topologies

Besides the topologies discussed in this guide, you can consider alternative Oracle Identity Manager topologies on Exalogic.

This guide does not provide specific instructions for implementing these alternative topologies, but consider the following when you are preparing your environment for an Oracle Identity Manager deployment on Exalogic:

• Using an External Oracle HTTP Server Web Tier Instead of Oracle Traffic Director

• Using Oracle Exadata Instead of an Oracle RAC Database

3.2.2.1 Using an External Oracle HTTP Server Web Tier Instead of Oracle Traffic Director

The other topologies described in this guide use Oracle Traffic Director as both a Web server and an internal load balancer. You may want to, as shown in Figure 3-3, "Exalogic OHS Topology" move the external Web requests outside of the Exalogic rack into a dedicated Demilitarized Zone (DMZ). The benefit of this approach is that the new Web Hosts can be separated from the Exalogic rack using a firewall.

If you cannot dedicate two compute nodes for Oracle Traffic Director, or if you would rather use a dedicated Oracle HTTP Server Web Tier, then it is possible to deploy Oracle HTTP Server on an external Web tier, which is located outside the Exalogic machine.

Figure 3-3 Exalogic OHS Topology

This figure is a graphical representation of the Exalogic OHS Deployment topology. It includes icons and symbols that represent the hardware load balancer, compute nodes, firewalls, and other elements of the topology. At a high level, it shows the main components of the topology, including the following:

• There are two servers, Webhost1 and Webhost2, each of which hosts an Oracle HTTP Server and Oracle WebGate.

  Inside the demilitarized zone (DMZ) is a load balancer which directs requests received on SSO.mycompany.com and directs requests to the Oracle HTTP servers. In the case of SSO.mycompany.com, requests are SSL encrypted. This is terminated at the load balancer. SSO.mycompany.com handles requests using the HTTP protocol.

• The Application Tier, where the application servers reside, including Oracle WebLogic Server and the upper stack products, such as Oracle SOA Suite. In this specific topology, the compute nodes are referred to as IAMHOST1 and IAMHOST2.

  • Oracle Traffic Director. This topology uses Oracle Traffic director only as an internal load balancer.

  • Oracle Unified Directory. Each host has an instance of Oracle Unified Directory which is used as the LDAP directory for identity information. Each Oracle Unified Directory instance is kept up to date through Oracle Unified Directory replication.

  • WebLogic Domain: IAMAccessDomain, which consists of:

    • Oracle Access Management, which hosts Access Server/Federation Server and corresponding JRF/OPSS processes.

    • Optional Oracle Adaptive Access Manager

    • WebLogic Administration Server, which hosts the WebLogic Console for IAMAccessDomain, OAM Console, and Oracle Enterprise Manager Fusion Middleware Control. In the event of the failure of IAMHOST1, the WebLogic Administration Server can be started on IAMHOST2.

  • WebLogic Domain: IAMGovernanceDomain, which consists of:

    • Oracle Identity Manager, which hosts an OIM Server and corresponding JRF/OPSS processes

    • SOA, which hosts a SOA Server and corresponding JRF/OPSS processes

    • WebLogic Administration Server, which hosts the WebLogic Console for IAMGovernanceDomain, Oracle Enterprise Manager Fusion Middleware Control, and Authorization Policy Manager (APM). In the event of the failure of IAMHOST1, the WebLogic Administration Server can be started on IAMHOST2.

• The Data Tier is where the databases reside. The database tier can either be on external database servers or an attached Exadata Appliance.The databases contain customer data and the schemas required by the application tier products.

• Firewalls are used to separate the Web, Application, and Directory tiers into different zones.

Note:

If an ExaLogic machine is hard wired to an Exadata machine then there is no need for a firewall restricting traffic between the Application and data tiers. All traffic is kept to the internal IPoIB network.

For more information, refer to the descriptions of the topology tiers in the sections that follow the diagrams. The instructions in this guide describe how to install and configure the software for this topology.

The Web Tier: There are two servers, each of which hosts an Oracle HTTP Server and Oracle WebGate.

3.2.2.2 Using Oracle Exadata Instead of an Oracle RAC Database

The reference topology in this guide provides information on using an external Real Application Clusters (RAC) database as the repository for product schemas and security stores.

The topology assumes that the RAC database is hosted on dedicated servers. These servers can either be independent or as part of an Oracle Exadata database machine.

If an Oracle Exadata machine is used then this should be connected to the Exalogic machine via the InfiniBand fabric. For more information, see "Connecting Exalogic and Exadata Machines" in the Oracle Exalogic Elastic Cloud Multi-Rack Cabling Guide.

3.3 Understanding the Topology Components

The topologies consist of three tiers, which are described in the following sections:

• Section 3.3.1, "About Exalogic Physical and Virtual Deployment Topologies"

• Section 3.3.2, "About EoIB and IPoIB Communication"

• Section 3.3.3, "About the Hardware Load Balancer"

• Section 3.3.4, "About the DMZ"

• Section 3.3.5, "About the Web Tier"

• Section 3.3.6, "About the Application Tier"

• Section 3.3.7, "About the Identity Stores"

3.3.1 About Exalogic Physical and Virtual Deployment Topologies

There are two types of Exalogic deployments. The first is a physical Exalogic deployment where each compute node in the Exalogic machine is used in its entirety. For more information see: Oracle Exalogic Elastic Cloud Machine Owner's Guide.

The second type is a virtual Exalogic deployment, where virtual servers are run on the Oracle Exalogic machine controlled by Oracle Enterprise Manager Ops Center. For more information, see: Oracle Exalogic Elastic Cloud Machine Owner's Guide, Oracle Exalogic Elastic Cloud Administrator's Guide.

This guide covers both deployment scenarios.

Physical Exalogic Deployment

A physical Exalogic Deployment uses the compute nodes directly. A dedicated compute node is a powerful entity and can fit the entire Oracle Traffic Director (OTD)/Identity and Access Management (IAM) software stack onto a single compute node. This is why the Exalogic Physical topology is shown with all the products divided between a pair of compute nodes.

This design makes optimum use of the hardware. It does not, however, provide the most secure implementation.

If more security is required, the OTD servers can be placed onto a separate dedicated set of compute nodes which can be hidden behind a dedicated VLAN partition, creating a buffer between the outside world and the internal web applications.

Using two dedicated compute nodes for OTD is, however, expensive. Such a configuration makes more sense if the Exalogic machine is being used to host multiple applications, such as Identity and Access Management and WebCenter or SOA. In such a case, a single OTD configuration could be used as a front end for each of the different applications.

Virtual Exalogic Deployment

In a virtual Exalogic deployment, the Exalogic machine is configured to host virtual servers, whose load is distributed among the underlying compute nodes by means of the Exalogic Cloud Infrastructure, which is installed onto the Exalogic machine.

In a virtual Exalogic deployment, you do not need to use the full capabilities of the compute nodes, as it makes more sense to spread the topology over smaller, manageable virtual servers (vServers). The virtual server distribution has been chosen such that:

• OTD sits on dedicated servers, as they are responsible for routing requests to all components in the deployment

• There is a pair of vServers for each domain. This is consistent with the Split Domain ideal. That is, the access domain can be patched independently of the governance domain. When each domain is placed onto a dedicated server, it is possible to scale out just one domain, or to patch the OS on just one domain, without impacting another.

3.3.2 About EoIB and IPoIB Communication

When you initially set up your Exalogic machine, the default network is running IP over Infiniband (IPoIB). For the different purposes of the topology described in this guide, you must configure Ethernet over Infiniband (EoIB) network access in addition to the IPoIB network. For more information, see "Configuring Ethernet Over InfiniBand" in the Oracle Exalogic Elastic Cloud Machine Owner's Guide.

In an Exalogic deployment the two different types of network are used as follows:

• IPoIB is used for internal communications for components within the Exalogic machine rack. This network is not visible outside of the Exalogic machine rack itself.

• EoIB is used for components inside the Exalogic machine rack to communicate with components external to the Exalogic machine rack.

The following types of communication must be configured for the Oracle Identity and Access Management enterprise deployment on Exalogic:

• For the Oracle Traffic Director hosts, the IP addresses must be EoIB addresses accessible from the load balancer. The Oracle Traffic Director IP addresses are the only addresses accessible from the DMZ network.

• IAM Servers use IPoIB addresses as the main listen address for internal invocations and for RMI interactions inside the Exalogic rack.

• If the Database Server is accessible over EoiB, the application machines must be able to access external hosts on EoIB

• Communication and routing between Oracle Traffic Director hosts and the application tier must be only over IPoIB.

• For communication between the application tier components, for example, internal JMS destinations routing must be on IPoIB. Any front end address that is exposed ONLY for internal consumption, uses and IPoIB virtual IP on Oracle Traffic Director hosts.

• IAM Servers can also be accessed externally for RMI/JMS/T3 invocations and HTTP invocations. These take place for remote deployments, for external JMS producers and consumers and for other operations that use a listen address of the IAM servers that is available outside the Exalogic rack (EoIB).

For more information about IPoIB and EoIB network configuration, see Section 4, "Networking Overview."

3.3.3 About the Hardware Load Balancer

In an Exalogic deployment, a hardware load balancer sits outside the Exalogic machine rack. Its function is to receive external requests for the IAM deployment and pass them on to each of the Web hosts. These Web hosts can either be Oracle HTTP servers or Oracle Traffic Director servers.

The load balancers are configured to receive HTTP and HTTPS requests. If an HTTPS request is received at the load balancer, the SSL is decrypted at the load balancer and passed on to the Web Servers using the HTTP protocol. This is known as SSL Termination at the load balancer.

The communication from the hardware load balancer to the Web tier is entirely over EoIB.

The load balancer is used to route both application and administrative requests to the Web servers. Administrative requests originate inside the organization's intranet. Application requests may be received through the intranet or the internet.

3.3.4 About the DMZ

A DMZ is a means of restricting access to components of your infrastructure to those that actually need it. In the examples in this guide, there is a public DMZ. 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 Oracle HTTP Servers (if used in the topology). 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 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 Oracle HTTP Servers (if used in the topology). 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. If, instead of an extranet, you are setting up an intranet, where all communication is from trusted sources, then you might reasonably decide to do away with the public DMZ.

3.3.5 About the Web Tier

Oracle Traffic Director can be used as the primary HTTP Server or in conjunction with Oracle HTTP Server. When used in conjunction with Oracle HTTP Server, Oracle Traffic Director only handles internal requests within the Exalogic machine.

The architecture of Oracle Traffic Director enables it to handle large volumes of application traffic with low latency. It is optimized for use in Oracle Exalogic Elastic Cloud. It communicates with WebLogic Servers in the back end over Exalogic's InfiniBand fabric (IPoIB).

3.3.5.1 Oracle Traffic Director Only

In this topology, the Oracle Traffic Director instances serve two purposes:

• The Oracle Traffic Director instances receive HTTP requests coming in from the hardware load balancer (over the EoIB network) and then route those requests (over the IPoIB network) to the compute nodes in the application tier.

• They route requests from the application tier components (over the IPoIB network) to other application tier components, such as requests from Oracle Access Manager to the Oracle Unified Directory directory service.

3.3.5.2 Oracle HTTP Server and Oracle Traffic Director

• The Oracle HTTP Servers receive requests coming in from the hardware load balancer and then route those requests (over the EoIB network) to the compute nodes in the application tier.

• The internal application to application requests, which are routed only over the internal IPoIB network, are routed through the Oracle Traffic Director via a virtual IP address that is depicted as VIP1 in the topology diagram (Figure 2–1).

3.3.5.3 More about Oracle Traffic Director

The Oracle Traffic Director instances are configured as part of a failover group. In this configuration, Oracle Traffic Director uses an implementation of the Virtual Routing Redundancy Protocol (VRRP) to provide failover capabilities. If an Oracle Traffic Director instance fails, IP addresses enabled on it are migrated to surviving instances, via VRRP. WebGate uses Oracle Access Protocol (OAP) to communicate with Oracle Access Manager to perform operations such as user authentication.

Oracle Traffic Director performs the following actions.

• Distributes the requests that it receives from clients to servers in the application tier based on the specific load-balancing method

• Routes the requests based on specified rules

• Caches frequently accessed data

• Prioritizes traffic and controls the quality of service

• Oracle Traffic Director can be used to route HTTP or LDAP requests

3.3.6 About the Application Tier

The application tier is the tier where Java EE applications are deployed. Products such as Oracle Identity Manager, Oracle Directory Services Manager, and Oracle Enterprise Manager Fusion Middleware Control are examples of the Java EE components that can be deployed in this tier. Applications in this tier benefit from the High Availability support of Oracle WebLogic Server and Oracle Fusion Middleware.

The application tier includes the following components, which are installed on Managed Servers in the Oracle WebLogic Server domains:

• Access Control services, which determine who has access to which resources. These services are provided by Oracle Access Manager.

• Fraud Detection services, which, when combined with Access Control ensure a higher level of security and fraud detection. This is provided by Oracle Adaptive Access Manager.

• Provisioning services, allowing users to request and manage accounts on the system. This is provided by Oracle Identity Manager and Oracle SOA.

• The Provisioning services are deployed into a separate domain to that of the Access Control services to facilitate independent management and patching.

IAMHOST1 hosts an Oracle WebLogic Administration Server. The Administration Server hosts the Oracle WebLogic Console, Oracle Enterprise Manager Fusion Middleware Control, Oracle Access Management Console, and Oracle Directory Services Manager (ODSM) for OUD.

Note that the Oracle WebLogic Server Administration Server is a singleton process. That is, only one Administration Server can be running at a time within a domain. In the event that the host running the Administration Server fails, the Administration Server can be manually started on a different host.

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

For more information, see "Assured Replication" in the Oracle Fusion Middleware Administrator's Guide for Oracle Unified Directory.

3.3.6.2 Architecture Notes

• An embedded version of Oracle Entitlement Server is used to control access to Oracle Fusion Middleware components.

• Oracle Entitlements Server uses a centralized policy store that is stored within a database.

• Access Manager uses the OPSS Policy Store to store policy information.

• The Oracle WebLogic Server console, Oracle Enterprise Manager Fusion Middleware Control, and Oracle Access Management console are always bound to the listen address of the Administration Server.

• Managed servers WLS_OAM1 and WLS_OAM2 are configured in a cluster.

• The managed servers WLS_OIM1 and WLS_OIM2 are configured in a cluster.

• The managed servers WLS_SOA1 and WLS_SOA2 are configured in a cluster.

3.3.6.3 High Availability Provisions

• Oracle Traffic Director can be configured for high availability in active-passive mode. Virtual Hosts/IP addresses are started on a single OTD instance. A heart beat exists between each OTD instance. Using this heart beat, a secondary OTD instance will enable the virtual host/IP address in the event of the failure of the primary OTD instance.

• OAM Server, Oracle Identity Manager, and SOA are active-active deployments; these servers communicate with the data tier at run time.

• Oracle Traffic Director directs HTTP and LDAP requests to all WebLogic managed servers or OUD Instances ensuring maximum availability.

• The WebLogic Administration Server and Oracle Enterprise Manager deployment is active-passive (where other components are active-active). There is one Administration Server per domain.

• The WebLogic Administration Server is a singleton component deployed in an active-passive configuration. If the primary fails or the Administration Server on IAMHOST1 does not start, the Administration Server on the secondary host can be started. If a WebLogic managed server fails, the node manager running on that host attempts to restart it.

For more information about Oracle Identity and Access Manager high availability, see "Configuring High Availability for Oracle Identity and Access Management Components" in the Oracle Fusion Middleware High Availability Guide for Oracle Identity and Access Management

3.3.6.4 Security Provisions

The administration tools for this deployment (for example, Oracle WebLogic Server Console, Oracle Enterprise Manager Fusion Middleware Control console, and Oracle Access Management Console) are accessible only through a virtual host, such as iadadmin.mycompany.com, which is a virtual host configured on the hardware load balancer. This is only available within the intranet.

3.3.7 About the Identity Stores

Identity information is stored in an LDAP compliant directory. In this topology, Oracle supports the Oracle Unified Directory natively.

3.4 About Oracle Directory Services Manager

Oracle Directory Services Manager provides direct access to the configuration and data installed inside the LDAP directory. This is considered a development tool and is therefore not included in the Enterprise Deployment topology.

3.5 Benefits of Using the Split Domain Topology

The split domain topology is suitable for large organizations requiring individual control over each component in the deployment.

The main advantages of the Split Domain topology are related to patching flexibility. Specifically:

• As each component (Oracle Identity Manager and Access Manager) reside in different domains, you can apply patches (even domain level ones) so that they update only the component they are targeted at.

• You can patch Administrative Components such as Oracle Identity Manager without the need for a controlled outage, which you would otherwise require when updating an Operational component such as Access Manager).

3.6 Hardware Requirements for the Identity Management on Exalogic

The following sections describe the hardware requirements for the Identity and Access Management enterprise topologies on Exalogic:

• Hardware Load Balancer Requirements

• Exalogic Machine Requirements

3.6.1 Hardware Load Balancer Requirements

The Oracle Fusion Middleware enterprise deployment requires a hardware load balancer to route requests to the Web tier. For information about the minimum set of features required for the load balancer in this topology, see Section 4.4.1, "Load Balancer Requirements."

3.6.2 Exalogic Machine Requirements

Exalogic machines consist of virtual or physical machines, a storage appliance, as well as required InfiniBand and Ethernet networking components. The number of these components in each machine varies based on the hardware configuration.

For complete information about the hardware options available for Exalogic machines, see "Exalogic Hardware Configurations" in the Oracle Exalogic Elastic Cloud Machine Owner's Guide.

For any of the topologies described in this guide, an Exalogic machine eighth rack can be used. For more information, see Section 3.2, "Understanding the Oracle Identity Management Deployment Topology on Exalogic".

Assign two machines to the Application Tier. These will be referred to as IAMHOST1 and IAMHOST2.

Note that you can also assign compute nodes for a standard Oracle RAC database, but this guide assumes your database will be hosted on a remote set of hosts.

3.7 Software Components for an Enterprise Deployment

This section describes the software required for an Oracle Identity and Access Management enterprise deployment.

This section contains the following topics:

• Section 3.7.1, "Software Required for the Oracle Identity Management Deployment Topology on Exalogic"

• Section 3.7.2, "About Obtaining Software"

• Section 3.7.3, "Mandatory Patches"

• Section 3.7.4, "Applying Patches and Work-arounds"

3.7.1 Software Required for the Oracle Identity Management Deployment Topology on Exalogic

Table 3-1 lists the Oracle software you need to obtain before starting the procedures in this guide.

Table 3-1 Software Versions Used

Short Name	Product	Version
OTD	Oracle Traffic Director	11.1.1.7.0
JRockit	Oracle JRockit	jrockit-jdk1.6.0_29-R28.2.0-4.0.1 or newer
WLS	Oracle WebLogic Server	10.3.6.0
IAM	Oracle Identity and Access Management	11.1.2.2.0
SOA	Oracle SOA Suite	11.1.1.7.0
WebGate	WebGate 11g	11.1.2.2.0
RCU	Repository Creation Assistant	11.1.2.2.0
OUD	Oracle Unified Directory	11.1.2.2.0
OHS	Oracle HTTP Server	11.1.1.7.0

3.7.2 About Obtaining Software

To perform an automated installation of Oracle Identity and Access Management 11g Release 2 (11.1.2.2), download the Oracle Identity and Access Management Deployment Repository 11.1.2.2.0 from:

• The Oracle Software Delivery Cloud: http://edelivery.oracle.com/

• The Oracle Identity and Access Management download page: http://www.oracle.com/technetwork/middleware/id-mgmt/downloads/oid-11gr2-2104316.html

Note:

• If you downloaded a version of the Oracle Identity and Access Management Deployment Repository prior to April 8, 2014, you must replace it with a newer version before proceeding.

• If you are running RCU on a 64-bit Linux machine which does not have 32-bit system libraries available, you must either install such libraries for compatibility, or separately download the 64-bit version of RCU 11.1.2.2.0 and use that instead of the one present in the Deployment Repository.

You must also download Oracle Traffic Director and Oracle WebGate for Oracle Traffic Director. Extract to otd and webgate_otd in: REPO_HOME/installers:

For complete information about downloading Oracle Fusion Middleware software, see the Oracle Fusion Middleware Download, Installation, and Configuration Readme for this release, at: http://docs.oracle.com/cd/E23104_01/download_readme.htm

3.7.3 Mandatory Patches

Table 3-2 lists the patches required by Oracle Identity and Access Management on Exalogic.

Table 3-2 Mandatory Patch

Platform	Patch Number and Description on My Oracle Support
Generic Platform (2000)	18221571 ORACLE IDENTITY MANAGER BUNDLE PATCH 11.1.2.2.5

3.7.4 Applying Patches and Work-arounds

See the Oracle Fusion Middleware Release Notes for your platform and operating system for a list of patches to apply. You must apply the patches to ensure that your software operates as expected.

Patches are available for download from http://support.oracle.com. You can find instructions for deploying each patch in the enclosed README.html file.

Before starting the deployment, download any patches that are listed in the Release Notes, plus any other patches that are appropriate for your environment. The deployment tool can apply these patches automatically at the time it runs.

Download the patches from http://support.oracle.com and expand each patch to the directory appropriate for the product, as listed in Table 3-3. If the directory does not exist, create it.

After expanding the patch make sure that the Patch Directory (as listed in Table 3-3) contains a directory which is a number. That directory contains directories and files similar to:

• etc

• files

• README.txt

This is the directory layout for most patches. In some cases, such as bundle patches, the layout might be similar to:

bundle_patch_no/product/product_patch_no

In this case make sure that it is product_patch_no which appears in the Patch Directory not bundle_patch_no.

If a bundle patch contains fixes for multiple products make sure that the individual patches appear in the correct Patch Directory as listed below.

Table 3-3 Product Patch Directories

Product	Patch Directory
Oracle Common	REPOS_HOME/installers/oracle_common/patch
Directory	REPOS_HOME/installers/oud/patch/oud REPOS_HOME/installers/oud/patch/odsm
Oracle Access Management Access Manager	REPOS_HOME/installers/iamsuite/patch/oam
OHS	REPOS_HOME/installers/webtier/patch
WebGate	REPOS_HOME/installers/webgate/patch
Oracle Identity Manager	REPOS_HOME/installers/iamsuite/patch/oim
SOA	REPOS_HOME/installers/soa/patch
WebLogic Server	REPOS_HOME/installers/weblogic/patch

3.8 Road Map for the Reference Topology Installation and Configuration

Before beginning your Oracle Identity and Access Management enterprise deployment, review the flow chart in Figure 3-4, "Flow Chart of the Oracle Identity and Access Management Enterprise Deployment Process". This flow chart illustrates the high-level process for completing the enterprise deployment documented in this guide. Table 3-4 describes the steps in the flow chart and directs you to the appropriate section or chapter for each step.

This section covers the following topics:

• Section 3.8.1, "Flow Chart of the Oracle Identity and Access Management Enterprise Deployment Process"

• Section 3.8.2, "Steps in the Oracle Identity and Access Management Enterprise Deployment Process"

3.8.1 Flow Chart of the Oracle Identity and Access Management Enterprise Deployment Process

Figure 3-4, "Flow Chart of the Oracle Identity and Access Management Enterprise Deployment Process" provides a flow chart of the Oracle Identity and Access Management enterprise deployment process. Review this chart to become familiar with the steps that you must follow, based on the existing environment.

Figure 3-4 Flow Chart of the Oracle Identity and Access Management Enterprise Deployment Process

3.8.2 Steps in the Oracle Identity and Access Management Enterprise Deployment Process

Table 3-4 describes each of the steps in the enterprise deployment process flow chart for Oracle Identity and Access Management, shown in Figure 3-4. The table also provides information on where to obtain more information about each step in the process.

Table 3-4 Steps in the Oracle Identity and Access Management Enterprise Deployment Process

Step	Description	More Information
Review the Enterprise Deployment Topology	Review the recommended topology and plan the topology best suited for organization and applications.	Section 3.1, "Planning Your Deployment"
Prepare the Network for an Enterprise Deployment	To prepare your network for an enterprise deployment, understand concepts, such as virtual server names and IPs and virtual IPs, and configure your load balancer by defining virtual host names.
Prepare your File Storage Appliance for an Enterprise Deployment	To prepare your file system for an enterprise deployment, review the terminology for directories and directory environment variables, and configure shared storage.
Prepare the Compute Nodes for an Enterprise Deployment	To prepare your servers for an enterprise deployment, ensure that your servers meet hardware and software requirements, enable Unicode support and Virtual IP Addresses, mount shared storage, configure users and groups, and, if necessary, install software onto multi-homed systems.
Prepare the Oracle RAC Database for an Enterprise Deployment	To prepare an Oracle RAC database for an enterprise deployment, review database requirements, create database services, load the metadata repository, in the Oracle RAC database, configure Identity and Access Management schemas for transactional recovery privileges, and back up the database.
Install and Configure Oracle Unified Directory	Install and configure Oracle Unified Directory, which is used as the Identity Store in the recommended topologies. Configure two instances of Oracle Unified Directory by using Oracle Unified Directory configuration assistant.
Create the Initial WebLogic Server Domain	Run the Configuration Wizard to create the initial WebLogic Server domain.
Install and Configure Oracle Traffic Director on Exalogic Compute Nodes	Install and configure Oracle Traffic Director.
Extend the Domain for Oracle Access Management?	Run the Configuration Wizard again and extend the domain to include Oracle Access Management.
Extend the Domain for Oracle Identity Manager?	Run the Configuration Wizard again and extend the domain to include Oracle Identity Manager.
Configure SSO for the Administration Console	Configure single sign-on (SSO) for administration consoles in an Identity and Access Management Enterprise deployment.
Configure Node Manager	Set up Node manager by enabling host name verification, starting Node Manager, and configuring WebLogic Servers to use custom keystores.
Configure Server Migration	Configure server migration for the WLS_OIM1, WLS_SOA1, WLS_OIM2, and WLS_SOA2 Managed Servers. The WLS_OIM1 and WLS_SOA1 Managed Server are configured to restart on IAMHOST2 should a failure occur. The WLS_OIM2 and WLS_SOA2 Managed Servers are configured to restart on IAMHOST1 should a failure occur.