1 Overview

1.2.1 Built-in Security

The Enterprise Deployment architectures are secure because every functional group of software components is isolated in its own DMZ, and all traffic is restricted by protocol and port. The following characteristics ensure security at all needed levels, as well as a high level of compliance with standards:

• All external communication received on port 80 is redirected to port 443.

• Communication from external clients does not go beyond the Load Balancing Router level.

• No direct communication from the Load Balancing Router to the Data tier DMZ is allowed.

• Components are separated between DMZs on the Web Tier, Application Tier, and the Data Tier.

• Direct communication between two firewalls at any one time is prohibited.

• If a communication begins in one firewall zone, it must end in the next firewall zone.

• Oracle Internet Directory is isolated in the Data tier DMZ.

• Identity Management components such as Oracle HTTP Server, OracleAS Single Sign-On, and Oracle Delegated Administration Services are in the DMZ.

• All communication between components across DMZs is restricted by port and protocol, according to firewall rules.

1.2.2 High Availability

The Enterprise Deployment architectures are highly available, because each component or functional group of software components is replicated on a different computer, and configured for component-level high availability.

In the Web Server and Application Tiers, communication between components proceeds as follows:

1. The external Load Balancing Router does the following:

   • Receives end user requests on port 443, at the URL portal.mycompany.com, and balances the requests to one of the OracleAS Web Cache listeners on port 7777.

   • Receives invalidation messages from the Application Metadata Repository on port 9401, and balances the requests to one of the OracleAS Web Cache listeners on port 9401. In these cases, the Load Balancing Router functions as a proxy to receive internal requests on port 9401, but this port is not visible to external traffic.

   • Receives web provider design time messages (and the init_session call, for session based providers) on port 7777 from the Application Metadata Repository, and balances the requests to one of the OracleAS Web Cache listeners on port 7777. In these cases, the Load Balancing Router functions as a proxy to receive internal requests on port 7777, but this port is not visible to external traffic.

     
     

     Note: Although OracleAS Web Cache is clustered, invalidation and web provider messages cannot be sent directly to a OracleAS Web Cache server, because if that particular OracleAS Web Cache is not functioning, then there is no way for the Metadata Repository to communicate with the other OracleAS Web Cache instance. The Load Balancing Router's management of the invalidation and web provider messages provides component level high availability.

     
     

2. The Load Balancing Router balances the requests to one of the two OracleAS Web Cache servers on port 7777.

3. Each OracleAS Web Cache server receives the requests from the Load Balancing Router and passes them to one of the two OracleAS Portal Oracle HTTP Servers on port 7778.

   
   

   Note: Since all of the OracleAS Portal sessions are stateless, these requests can be routed from any OracleAS Web Cache server to any OracleAS Portal Oracle HTTP Server, and vice versa. However, if you are using Web Clipping functionality in OracleAS Portal, then you will need to enable stateful binding (as described in Section 7.3.8, "Enabling Session Binding on OracleAS Web Cache Clusters".)

   
   

4. The OracleAS Portal Parallel Page Engine also loops back to the Load Balancing Router (through the internal Network Address Translation port) to reach Portal Services to get the metadata information to construct the page. The Load Balancing Router is configured to handle Parallel Page Engine loop back calls, and load balances them to one of the Webcache listeners on port 7777.

   
   

   Note: The Parallel Page Engine constructs OracleAS Portal pages based on metadata in the Metadata Repository. To read the metadata, it loops back to Portal Services through the local OracleAS Web Cache instance. However, if that OracleAS Web Cache instance is down, there is no way for the Parallel Page Engine to reach Portal Services or the other OracleAS Web Cache instance. If Parallel Page Engine loops back to the Load Balancing Router, the Load Balancing Router can balance requests to Portal Services through the surviving OracleAS Web Cache instance, which can still balance the requests to the Oracle HTTP Server on the first middle tier. This exemplifies component level high availability and intelligent routing for efficient resource utilization.

   
   

5. When the request goes to portal.mycompany.com, OracleAS Portal determines whether the request is authenticated with OracleAS Single Sign-On; if not, it will redirect the request to the OracleAS Single Sign-On URL, login.mycompany.com.

In the Identity Management Tier, communication proceeds as follows:

1. OracleAS Single Sign-On receives a user request at login.mycompany.com.

2. OracleAS Single Sign-On authenticates the credentials with one of two Oracle Internet Directory instances, through the internal Load Balancing Router that is configured to manage Oracle Internet Directory traffic.

   
   

   Note: Two Oracle Internet Directory instances on different computers are using the same Metadata Repository. If the Identity Management components (OracleAS Single Sign-On, Oracle Delegated Administration Services) directly communicate with an Oracle Internet Directory instance, and that instance stops working, then there would be no way for the Identity Management components to redirect the traffic to the surviving Oracle Internet Directory instance. Thus the Load Balancing Router ensures high availability in re-routing traffic from a failed Oracle Internet Directory instance to a surviving instance.