2 Selecting a Deployment Architecture

2.4.1.1 Using Multimaster Replication with Oracle Internet Directory

Multimaster replication is an Oracle Internet Directory software solution that ensures read and write access to Oracle Internet Directory at all times, if at least one of the computers in the system remains available. When a computer resumes functioning after unavailability, replication from the surviving computer resumes automatically and synchronizes the contents between the computers. In addition, changes made on one directory server instance are reflected on the second directory server instance.

Multimaster replication of Oracle Internet Directory differs from the standard configuration in that the Oracle Internet Directory server and the database are on the same computer, whereas in the standard configuration the first Oracle Internet Directory instance and a database instance occupy IDMHOST1 and INFRADBHOST1, while the second Oracle Internet Directory instance and a database instance occupy IDMHOST2 and INFRADBHOST2. Thus, the replicated Oracle Internet Directory operates two fewer servers than the RAC configuration.

To implement multimaster replication in Oracle Internet Directory, follow the instructions in the Oracle Internet Directory Administrator's Guide, Oracle Internet Directory Replication Administration chapter, section titled "Installing and Configuring Multimaster Replication".

2.4.1.2 Using the Oracle Application Server Cold Failover Cluster (Identity Management) Solution

The OracleAS Cold Failover Cluster (Identity Management) solution is a hardware cluster comprising two computers. The computer that is actively executing an Infrastructure installation at any given time is called the primary (hot) node. If this node fails, the hardware cluster automatically diverts Infrastructure operations to the secondary (cold) node.

Each hardware cluster node is a standalone server that runs its own set of processes, but accesses a shared storage subsystem. The cluster can access the same storage, usually disks, from both nodes, but only the primary node has active access to the storage at any given time. If the primary node fails, the hardware cluster's software grants the secondary node access to the storage.

The OracleAS Cold Failover Cluster (Identity Management) solution differs from the standard configuration in the following ways:

• The Oracle Internet Directory server and the database are on the same computer, whereas in the standard configuration the first Oracle Internet Directory instance and a database instance occupy IDMHOST1 and INFRADBHOST1, while the second Oracle Internet Directory instance and a database instance occupy IDMHOST2 and INFRADBHOST2. Thus, the OracleAS Cold Failover Cluster (Identity Management) solution operates two fewer servers than the RAC configuration.

• In the event of node failure, clients will experience a brief interruption of service while the workload is diverted to the cold node.

2.4.2.1 Oracle Internet Directory: Data Tier or Identity Management Tier?

Oracle Internet Directory can be installed on the Identity Management Tier, along with OracleAS Single Sign-On and Oracle Delegated Administration Services. This is typical of configurations that provide a complete, local identity management system (Oracle Internet Directory and Oracle Application Server Single Sign-On) on one computer to applications located near that computer. See the Oracle Identity Management Concepts and Deployment Planning Guide, Chapter 3, "Oracle Identity Management Deployment Planning", section titled "Planning the Physical Network Topologies".

In the standard configuration, in which Oracle Internet Directory is installed on the Data Tier, Oracle Internet Directory and its metadata repository are behind a firewall, and is isolated from Internet traffic.

2.4.2.2 Oracle Internet Directory: AD/iPlanet Integration

Oracle Identity Management provides a set of components for integrating with other identity management environments, including various services and APIs, preconfigured directory connectivity solutions and standards support. For example, Oracle Identity Management allows for integration with various 3rd party directories, including Microsoft Active Directory and SunONE Directory Server.

By default, Oracle Directory Integration and Provisioning is installed as a component of Oracle Internet Directory. However, you can also install Oracle Directory Integration and Provisioning in a standalone installation. You should install a standalone instance of Oracle Directory Integration and Provisioning under the following circumstances:

• When you need Oracle Internet Directory to run on a separate host for performance reasons

• When the applications that you need to provision and synchronize required intensive processing

• You need to run multiple instances of Oracle Directory Integration and Provisioning for high availability

See the Oracle Identity Management Integration Guide for detailed information on configuration options.

2.4.2.3 Oracle Application Server Single Sign-On: Using Netegrity

Several third-party access management vendors provide authentication adapters for the OracleAS Single Sign-On server. These products enable you to integrate a third-party system with the Oracle system without having to write your own code.The link that follows provides information about these vendors' products. All of the vendors listed certify that their products work with OracleAS Single Sign-On. See the section Single Sign-On under the heading Documentation, which appears near the bottom of the page.

http://www.oracle.com/technology/products/id_mgmt/partners/index.html

For example, Netegrity provides Siteminder Agent for Oracle Application Server. The agent delivers a mechanism to enable integration between heterogeneous, enterprise wide SiteMinder implementation with the OracleAS Single Sign-On environment. The agent provides enhanced security to protect Oracle Web-based resources, including session synchronization and revalidation of the user's SiteMinder session behind the DMZ in a trusted zone or corporate internal network prior to initiating the Oracle session. For the current information on version, platform support and configuration guide, visit:

http://www.netegrity.com

2.4.2.4 Oracle Application Server Single Sign-On: Windows Authentication

Windows native authentication is an authentication scheme for those who use Internet Explorer on Windows platforms. When this feature is enabled in OracleAS Single Sign-On, users log in to single sign-on partner applications automatically using Kerberos credentials obtained when the user logs in to a Windows computer. Using the Simple Protected GSS-API Negotiation Protocol (SPNEGO), browsers that are Internet Explorer 5.0 and greater can automatically pass the user's Kerberos credentials to a Kerberos-enabled Web server when the server requests these credentials. The Web server can then decrypt the credentials and authenticate the user.Before setting up Windows native authentication, you must first set up Active Directory (AD) Synchronization to Oracle Internet Directory. See the Oracle Internet Directory Administrator's Guide for instructions on how to do this.

2.4.3.1 J2EE Applications: File Based or Database Repository?

An Oracle Application Server Farm is a collection of instances that share the same configuration management metadata repository. A farm can be either a Oracle Application Server File-Based Farm or Oracle Application Server Database-Based Farm. Within these farm types, there are three types of metadata repository configuration: File-based (with standalone instance), File-based (with repository host instance) and Database:

• File-based repository (standalone instance) — Every instance includes a local file- based repository. In a standalone instance, this repository stores the configuration metadata for the instance. When an instance is part of an OracleAS Database-Based Farm or an OracleAS File-Based Farm, and the instance is not the repository host, the local file-based repository contains the Bill of Materials (BOM) that Distributed Configuration Management uses to validate that the instance is synchronized with the configuration metadata in the repository.

• File-based repository (with repository host instance) — When an instance is defined as the repository host for an OracleAS File-Based Farm, the repository for the instance contains the configuration metadata for all instances in the farm.

• Database repository - comprised of DCM schema. Storing the metadata repository in a database may be useful as part of a site's high availability and backup strategy. Using a database repository, the database serves as the repository host.

In all three metadata repository scenarios (database repository, file-based repository with a standalone instance, or file-based repository host instance), an instance always has a local file based repository. If the instance is not included in a farm, this is the sole storage for the configuration metadata for the instance.The choice of database repository or file-based repository has a low impact on a system's availability. In case of repository failure or downtime, the J2EE cluster continues to operate. Only the distributed management features are unavailable during the repository downtime. Table 2-14 compares repository types in light of operational considerations.

2.4.4.1 Oracle Application Server Web Cache Placement, Clustering and Deployment Considerations

OracleAS Web Cache is a content-aware server accelerator, or reverse proxy server, that improves the performance, scalability, and availability of Web sites that run on Oracle Application Server. Oracle recommends configuring multiple instances of OracleAS Web Cache to run as members of a cache cluster. A cache cluster is a loosely coupled collection of cooperating OracleAS Web Cache cache instances that provide a single logical cache.When deploying topologies described in this document, one variant is to place OracleAS Web Cache on a separate host. This is particularly useful in environments with large amounts of cacheable content. This architecture modification provides flexibility in choosing the number of computers to operate OracleAS Web Cache, as well as defining separate hardware profile for OracleAS Web Cache servers and J2EE or OracleAS Portal servers. Typically, a large amount of RAM and fast access to file storage are the most critical components in the performance of the OracleAS Web Cache server. Another possibility is to place a firewall between OracleAS Web Cache and the Oracle HTTP Server; this would provide an additional layer of security.

For additional information on configuration variants with OracleAS Web Cache, see the Oracle Application Server Web Cache Administrator's Guide.

2.4.4.2 Oracle HTTP Server: Forward and Reverse Proxies

The architectures described in this guide can be deployed in environments with additional forward or reverse proxy servers.Proxy scenarios change the way the clients' IP addresses are seen by the Oracle HTTP Server. This can be adjusted to better match Web applications' expectations by transferring the clients' IP addresses through proxies in additional HTTP headers and making the HTTP Server use the header values, either with explicit configuration or implicitly, by overall replacing the "physical" request connection information with the header values.The Oracle HTTP Server and applications in an Oracle HTTP Server handle information about clients. Because clients are often identified by their IP addresses, scenarios in which reverse ("transparent") or forward ("normal") proxies are part of the whole system may require adjustments in how the client's IP addresses are seen by the Oracle HTTP Server.For instructions on how to configure a reverse proxy using Oracle HTTP Server or the Internet Information Services (IIS) server, see Section 9.2, "Configuring a Reverse Proxy for OracleAS Portal and OracleAS Single Sign-On". For information on how to integrate OracleAS Web Cache with an additional proxy server, see the Oracle Application Server Web Cache Administrator's Guide.

2.4.4.3 Oracle HTTP Server as a Standalone Web Server

There are two ways to install Oracle HTTP Server on the Web Server Tier: as a standalone Web server, or as part of the J2EE and Web Cache installation type.

Some security plans discourage installation of any Java executables on the Web Server tier. For this reason, this guide presents the installation of the Oracle HTTP Server as a standalone Web server. The Oracle HTTP Server is managed by the opmnctl utility (invoked by the Start menu on Windows systems) instead of the Oracle Enterprise Manager 10g Application Server Control Console.

If it is acceptable or desirable to install all of the J2EE and Web Cache components on the Web Server tier, or you want to use the Oracle Enterprise Manager 10g Application Server Control Console to manage the Oracle HTTP Server, you may follow the instructions in Section 9.3, "Configuring J2EE and Web Cache on the Web Tier".