| Oracle® Application Server Enterprise Deployment Guide 10g Release 3 (10.1.3.2.0) Part Number B32125-02 |
|
|
View PDF |
| Oracle® Application Server Enterprise Deployment Guide 10g Release 3 (10.1.3.2.0) Part Number B32125-02 |
|
|
View PDF |
An enterprise deployment of Oracle WebCenter Suite is a reference configuration that is designed to support large-scale, mission-critical business software applications using the Oracle WebCenter Framework (the runtime development framework for portlets, content integration and security) and Oracle WebCenter Services (of which Oracle Content DB is a part). The hardware and software in an Enterprise Deployment configuration delivers:
High quality service
The system workload is managed and balanced effectively
Applications continue to operate when resources are added or removed
System maintenance and unexpected failures cause minimal downtime
All incoming network traffic is received by the Load Balancing Router on a single, secure port and directed to internal IP addresses within the firewall; inside the firewall, functional components are grouped within DMZs
Security systems are integrated
Administrative access is isolated
Efficient software provisioning and management
Application distribution is simple
Systems are managed and monitored as one logical unit in a central console
Death detection and restart mechanisms ensure availability
The Oracle Application Server configurations discussed in this guide are designed to ensure security of all transactions, maximize hardware resources, and provide a reliable, standards-compliant system for enterprise computing with a variety of applications. The security and high availability benefits of the Oracle Application Server configurations are realized through isolation in firewall zones and replication of software components.
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 standards compliance:
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.
Identity Management components are in the DMZ.
All communication between components across DMZs is restricted by port and protocol, according to firewall rules.
Enterprise Deployments with the Oracle WebCenter Suite provide highly available, scalable and secure deployments of WebCenter Framework components.
This guide provides configuration instructions for these Enterprise Deployments of Oracle WebCenter Suite, with different security options:
myWebCenter with JSSO and Oracle Internet Directory (shown in Figure 1-1)
myWebCenter with Oracle COREid Access and Identity (shown in Figure 1-2)
myWebCenter with Oracle Application Server Single Sign-On (shown in Figure 1-3).
Table 1-1 lists the security configurations and the identity and policy stores used with them.
The policy store is the repository for OracleAS JAAS Provider authorization permissions and grants. Oracle Internet Directory and XML (the ORACLE_HOME/j2ee/home/system-jazn-data.xml file) are supported as policy store repositories.
User accounts and roles are always seeded in an enterprise identity store (typically an LDAP server), and are not replicated in the policy store. The policy store only has grants and references to groups and roles in the enterprise identity store. The same repository (Oracle Internet Directory or an XML file) can be used as both the identity and policy store.
Table 1-1 Supported Security Configurations
| Deployment Configuration | Policy Store | Identity Store |
|---|---|---|
|
myWebCenterFoot 1 with Java SSO |
OracleAS JAAS Provider and Oracle Internet Directory |
OracleAS JAAS Provider and Oracle Internet Directory |
|
myWebCenter1 with Oracle Application Server Single Sign-On |
OracleAS JAAS Provider and Oracle Internet Directory |
OracleAS JAAS Provider-Oracle Internet Directory |
|
myWebCenter1 with Oracle COREid Access and IdentityFoot 2 |
OracleAS JAAS Provider and XML |
OracleAS JAAS Provider and Oracle Internet DirectoryFoot 3 |
Footnote 1 Oracle Content DB and WebCenter Suite must use jazn.xml or Oracle Internet Directory. Any authentication mechanism that WebCenter Suite supports (JAZN-XML, Java SSO or OracleAS Single Sign-On), the adapter will also support. The Oracle Content DB server has a different support model (it doesn't support Java SSO, for example).
Footnote 2 See Chapter 11 of the Oracle Containers for J2EE Security Guide for information on adding permissions in Oracle COREid Access and Identity environments.
Footnote 3 When Oracle COREid Access and Identity is used with OracleAS JAAS Provider and XML as the policy store and Oracle Internet Directory as the identity store, you must ensure that all user accounts and roles are in the identity store (Oracle Internet Directory), and that the policy grants are in the policy store (the system-jazn-data.xml file). Grants in this file must refer to users in the identity store (Oracle Internet Directory) See Chapter4, "Configuring Oracle WebCenter Services User Roles for Oracle COREid Access and Identity" for instructions.
The servers in the myWebCenter system are grouped into tiers as follows:
Web Tier — WEBHOST1 and WEBHOST2, with Oracle HTTP Server installed.
Application Tier — APPHOST1 and APPHOST2, with Oracle Containers for J2EE installed, and multiple OC4J instances with applications deployed.
In myWebCenter with Oracle COREid Access and Identity, this tier also includes WebGate, WebPass, and Oracle COREid Access and Identity Identity Server, Access Server, Access Manager, and ADMINHOST, for administrator use.
In myWebCenter with Oracle Application Server Single Sign-On, this tier includes IDMHOST1 and IDMHOST2, with Oracle Application Server Single Sign-On and Oracle Delegated Administration Services.
Data Tier — OIDHOST1 and OIDHOST2, with 10g Release 3 (10.1.4.0.1) Oracle Internet Directory installed, and INFRADBHOST1 and INFRADBHOST2, the two-node Real Application Clusters database.
Figure 1-1 Enterprise Deployment Architecture for myWebCenter.com with JSSO and Oracle Internet Directory
Figure 1-2 Enterprise Deployment Architecture for myWebCenter.com with Oracle COREid Access and Identity
Figure 1-3 Enterprise Deployment Architecture for myWebCenter.com with Oracle Application Server Single Sign-On
Table 1-2 summarizes the process for configuring myWebCenter with each of the user authentication methods. Follow the procedures indicated in the first column, in the order shown, for the chosen configuration.
Table 1-2 Enterprise Deployment Configuration Procedures
| Perform the steps in... | To configure myWebCenter with JSSO and Oracle Internet Directory | To configure myWebCenter with Oracle Access Manager | To configure myWebCenter with Oracle Application Server Single Sign-On |
|---|---|---|---|
|
Chapter 2, "Configuring the Data Tier" |
Yes |
Yes |
Yes |
|
Chapter3, "Installing and Configuring the Web and Application Tiers" |
Yes |
Yes |
Yes |
|
Chapter3, "Configuring Session State Replication for the OC4J_Apps and OC4J_WebCenter Instance" |
Yes |
Yes |
Yes |
|
Chapter3, "Configuring APPHOST1 and APPHOST2 for the RAC Database" |
Yes |
Yes |
Yes |
|
Chapter3, "Configuring Network Communication" |
Yes |
Yes |
Yes |
|
Chapter3, "Configuring Application Authentication and Authorization" |
Yes |
No |
Yes |
|
Chapter 4, "Installing and Configuring Oracle COREid Access and Identity" |
No |
Yes |
No |
|
|
No |
No |
Yes |
Table 1-3 and Table 1-4 list minimum hardware requirements for the Enterprise Deployment on Windows and Linux operating systems, respectively. The memory figures represent the memory required to install and run Oracle Application Server; however, for most production sites, you should configure at least 1 GB of physical memory.
For detailed requirements, or for requirements for a platform other than these, see the Oracle Application Server Installation Guide for the platform in use.
Table 1-3 myWebCenter Hardware Requirements (Windows)
| Server | Processor | Disk | Memory | TMP Directory | Swap |
|---|---|---|---|---|---|
|
WEBHOST |
300 MHz or higher Intel Pentium processor recommended |
400 MB |
512 MB |
55 MB to run the installer; 256 MB needed for some installation types |
512 MB |
|
APPHOST |
300 MHz or higher Intel Pentium processor recommended |
2 GB |
1 GB |
400 |
1 GB |
|
OIDHOST and INFRADBHOST |
300 MHz or higher Intel Pentium processor recommended |
2.5 GB |
1 GB |
55 MB to run the installer; 256 MB needed for some installation types |
1 GB |
|
ADMINHOST |
300 MHz or higher Intel Pentium processor recommended |
400 MB |
512 MB |
n/a |
512 MB |
Table 1-4 myWebCenter Hardware Requirements (Linux)
| Server | Processor | Disk | Memory | TMP Directory | Swap |
|---|---|---|---|---|---|
|
WEBHOST |
Pentium (32-bit), 450 MHz or greater |
520 MB |
512 MB |
400 MB |
1.5 GB |
|
APPHOST |
Pentium (32-bit), 450 MHz or greater |
2 GB |
1 GB |
400 |
1.5 GB |
|
OIDHOST and INFRADBHOST |
Pentium (32-bit), 450 MHz or greater |
2.5 GB |
1 GB |
400 MB |
1.5 GB |
|
ADMINHOST |
Pentium (32-bit), 450 MHz or greater |
520 MB |
512 MB |
400 MB |
1.5 GB |
Production requirements vary depending on applications and the number of users. All Enterprise Deployment configurations described in this guide use two servers for each tier to provide failover capability; however, this does not presume adequate computing resources for any application or user population. If the system workload increases such that performance is degraded, you can add servers to the configuration by repeating the instructions for the installation and configuration of the second server on the tier (WEBHOST2, APPHOST2, INFRADBHOST2) to add a third server where it is needed.
The variants described in this section enable you to achieve deployment goals using fewer servers, different software, or alternative configurations.
Multi master 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 directory servers in the system remains available. When an Oracle Directory server resumes functioning after being unavailable, replication from the surviving directory server resumes automatically and synchronizes the contents between the directory servers forming the directory replication group. In addition, any changes made on one directory server instance are reflected on the second directory server instance.
To implement multi master 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 Multi master Replication".
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.
Note:
For a detailed discussion of the OracleAS Cold Failover Cluster (Identity Management) solution, see the Oracle Application Server High Availability Guide.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 OIDHOST1 and INFRADBHOST1, while the second Oracle Internet Directory instance and a database instance occupy OIDHOST2 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.
To implement the OracleAS Cold Failover Cluster (Identity Management) solution:
Obtain and configure a hardware cluster.
Install and configure the Oracle Application Server instances on the cluster computers to use the OracleAS Cold Failover Cluster (Identity Management) solution. Follow the instructions in the Oracle Application Server Installation Guide, "Installing an OracleAS Cold Failover Cluster (Identity Management) Configuration".
Manage the OracleAS Cold Failover Cluster (Identity Management) solution, following the instructions from the Oracle Application Server High Availability Guide, "Managing Oracle Application Server Cold Failover Cluster (Identity Management)".
Proxies change the way the Oracle HTTP Server processes client requests.
A forward proxy is an intermediary server between a client and the origin server containing the content. Forward proxies are usually used to provide Internet access to internal clients that are otherwise restricted by a firewall. To get content from the origin server, the client sends a request to the proxy, naming the origin server as the target. The proxy requests the content from the origin server and returns it to the client. The client must be configured to use the forward proxy to access other sites.
A reverse proxy is a server that appears to outside clients to be the content server. It relays requests from outside the firewall to servers behind the firewall, and delivers retrieved content back to the client. A firewall rule allows access only to the proxy server, so that the content servers are protected. The proxy server changes URLs listed in the headers of any messages generated by the content servers, so that external clients are given no information about the servers behind the firewall. No configuration of clients is necessary with a reverse proxy (the client makes requests for content in the name-space of the reverse proxy). The reverse proxy decides where to send the requests, and returns the content as if it was the origin server.
