9 Implementing Architecture Variants

This chapter explains how to implement common variants to the Enterprise Deployment configurations described in this guide. This chapter contains the following topics:

Section 9.1, "Configuring a Dedicated Intranet and Internet for OracleAS Portal"

Section 9.2, "Configuring a Reverse Proxy for OracleAS Portal and OracleAS Single Sign-On"

Section 9.3, "Configuring J2EE and Web Cache on the Web Tier"

9.1 Configuring a Dedicated Intranet and Internet for OracleAS Portal

You can configure OracleAS Portal to be accessible from within a company network as well as from external clients. This section describes some important characteristics of this configuration, and provides instructions on how to configure OracleAS Portal for this purpose.

The complete configuration for the dedicated intranet and internet is shown in Figure 9-1.

Figure 9-1 Dedicated Intranet and Internet for OracleAS Portal

Description of "Figure 9-1 Dedicated Intranet and Internet for OracleAS Portal"

The intranet/internet configuration for OracleAS Portal requires two logical middle tiers: portal.mycompany.com and internal.mycompany.com, each residing on its own computer. This separation of physical middle-tiers helps isolate the content cached for internet and intranet users. This enhances security, and also ensures that users who navigate to one logical middle tier do not access content served by the other logical middle tier. Each logical middle tier then provides access to the same OracleAS Portal schema in the Oracle Application Server Metadata Repository and the same OracleAS Portal data. In this configuration, the external logical middle tier is the primary middle tier used to install, configure, and expose web providers. The internal logical middle tier is designated as a partner application.

The intranet/internet configuration requires that all OracleAS Web Cache instances be configured as an invalidation-only cluster. Invalidation-only clustering ensures that OracleAS Web Cache maintains distinct caches for the two logical sites, while enabling the cluster members to share invalidation messages (thereby ensuring that content edits are visible across the two logical sites).

In this configuration, invalidation messages are sent from the OracleAS Portal schema in the OracleAS Metadata Repository to the internal OracleAS Web Cache instance, and the invalidation message is then sent out to all the cluster members. The invalidation message used in this configuration ensures that it invalidates content regardless of the host and port specified in the cached URL. This type of invalidation ensures that content cached with either logical middle-tier URL is invalidated. For more information on the OracleAS Web Cache invalidation-only cluster, refer to the Oracle Application Server Portal Configuration Guide.

To ensure that the internal and external user communities are distinct, two URLs are used to access the OracleAS Portal applications: from the intranet, http://internal.mycompany.com; from the Internet, https://portal.mycompany.com.

The process of configuring the dedicated intranet and extranet for OracleAS Portal consists of the following tasks:

Installing the Infrastructure and External Middle Tier Instances (Section 9.1.1)
Installing the First Internal Middle Tier on APPHOST3 (Section 9.1.2)
Installing the Second Internal Middle Tier on APPHOST4 (Section 9.1.3)
Configuring an OracleAS Web Cache Invalidation-only Cluster (Section 9.1.4)
Configuring the First Internal Middle Tier on APPHOST3 for Load Balancing Router Access (Section 9.1.5)
Configuring the Second Internal Middle Tier on APPHOST4 for Load Balancing Router Access (Section 9.1.6)
Registering the Internal Middle Tier as a Partner Application (Section 9.1.7)
Updating the Default JPDK Instance URL and Seeded Provider Group URLs (Section 9.1.8)
Configuring OracleAS Portal Invalidation Messages (Section 9.1.9)
Configuring the OracleAS Portal Schema in the OracleAS Metadata Repository (Section 9.1.10)
Modifying the Oracle Text Base Search URL (Section 9.1.11)
Configuring the Oracle Drive WebDAV Client (Section 9.1.13)
Validating the Completed Configuration (Section 9.1.14)

9.1.1 Installing the Infrastructure and External Middle Tier Instances

To install and configure the necessary Infrastructure and Oracle Application Server instances:

Perform all steps in Chapter 4, "Installing and Configuring the Security Infrastructure".
Perform all steps in Chapter 7, "Installing and Configuring the myPortalCompany Application Infrastructure" (Use the URL portal.mycompany.com for these instances).

9.1.2 Installing the First Internal Middle Tier on APPHOST3

Follow these steps to install the first internal middle tier.

Copy the staticport.ini file from the Disk1/stage/Response directory to a local directory, such as TMP.

Edit the staticport.ini file to assign the following custom ports:

Oracle HTTP Server port = 7777
Oracle HTTP Server Listen port = 7778
Web Cache HTTP Listen port = 7777
Web Cache Administration port = 9400
Web Cache Invalidation port = 9401
Web Cache Statistics port = 9402
Application Server Control port = 1810

Notes:

Ensure that these ports are not already in use by any other service on the computer. Using the Static Ports feature as described to install the Application Server Tier ensures that the port assignments will be consistent with the documentation in this section, if the ports are correctly specified in the file and the port is not already in use. Otherwise:

If a port is incorrectly specified, then the Oracle Universal Installer will assign the default port.
If a port is already in use, then the Oracle Universal Installer will assign the next available port.

See Section B.3, "Using the Static Ports Feature with Oracle Universal Installer" for more information.

Port 80 is open on the firewall only to accept and redirect requests using the HTTP (non-secure) protocol. Requests using the HTTP protocol (in the form http://www.mycompany.com) are redirected to port 443. Requests using the HTTPS, or secure, protocol (in the form https://www.mycompany.com) are managed by port 443.

Install a Portal and Wireless Oracle Application Server 10g middle tier on the first computer. During the installation:

Use the Infrastructure installed in Step 1 of Section 9.1.1.

Clear the selection for OracleAS Portal in the Select Configuration Options screen.

Note:

Selecting the Oracle Application Server 10g Portal option in this screen now will overwrite the previously created configuration entries. For more information, refer to the Oracle Application Server Portal Configuration Guide, section titled "Configuring OracleAS Portal During and After Installation".

In the Select OracleAS 10g Metadata Repository, select the connect string for the application Metadata Repository database (on APPDBHOST1 and APPDBHOST2) from the drop-down list.
Configure OracleAS Portal, accessing the Application Server Control Console. To configure OracleAS Portal, perform the following steps:
1. On the Oracle Application Server home page, click the Configure Component button.
2. Select Portal from the drop-down list on the Select Component page and click Continue.
  
  The Login page appears.
3. Enter the administration password for the Oracle Application Server instance in the Administration Password field.
4. Click Finish.
  
  The OracleAS Portal middle-tier components are deployed, but information in the OracleAS Metadata Repository is not overwritten.
5. When the configuration is complete, click OK. The Oracle Application Server home page is displayed.
6. Verify that the OC4J_Portal and Portal:portal instances appear in the System Components table.
7. Verify that the OC4J_Portal and Portal:portal instances are running:
  - Click OC4J_Portal and verify that the OC4J_Portal page appears.
  - Click Portal:portal and verify that the Portal page appears.
8. Restart Oracle HTTP Server and OC4J_Portal.
9. Verify that the installation is accessible at the following URL:
  
  http://apphost3.mycompany.com:7777

9.1.3 Installing the Second Internal Middle Tier on APPHOST4

Follow the steps in section Section 9.1.2, "Installing the First Internal Middle Tier on APPHOST3" to install the second internal middle tier, substituting apphost4 where applicable.

Note:

It is recommended that you use the same physical path for installing the second middle tier. This helps when you make configuration changes on one computer and want to transfer the changes to another computer. If the physical path is different on other computers, you must ensure that the path elements are corrected after copying the files.

9.1.4 Configuring an OracleAS Web Cache Invalidation-only Cluster

You must configure an OracleAS Web Cache invalidation-only cluster that includes the OracleAS Web Cache instances from both the internal and external computers. In this cluster configuration, invalidation requests are propagated across all cache cluster members. However, the OracleAS Web Cache invalidation-only cluster does not forward other requests between the cluster members, so while processing user requests, each cluster member acts as an individual cache and does not request objects from peer cluster members.

This configuration can be used to simplify the administration of many caches, especially in a cluster whose members are separated by a firewall. For example, a cluster can have two caches located on either side of a firewall that separates the intranet from the Internet.

9.1.4.1 Preparing the Network Environment for the OracleAS Web Cache Invalidation-only Cluster

Before configuring the OracleAS Web Cache invalidation-only cluster between the external and internal OracleAS Web Cache instances, perform the following checks:

Ensure that all external OracleAS Web Cache instances can resolve and contact all internal OracleAS Web Cache instances and vice versa. This can be done using the ping network command.
Ensure that the invalidation port (9401) is open in the firewall in one direction only from the internal OracleAS Web Cache instance to the external OracleAS Web Cache instance.
Ensure that the administration port (9400) is open in the firewall in both directions.

Note:
After the configuration is complete, the administration port (9400) should be closed to traffic from the external middle tiers to the internal middle tiers.
Ensure that you can use telnet to send network packets from the internal to the external OracleAS Web Cache ports.

9.1.4.2 Configuring the Caches

This section explains how to manage the caches as a cluster and segregate cache content, using the OracleAS Web Cache Manager on APPHOST1 to configure settings for a cache cluster.

In the navigator frame, select Properties > Clustering.

The Clustering page appears. The General Cluster Information section displays the default clusterwide values for failover and invalidation propagation. The Cluster Members table displays the external middle tier caches (APPHOST1 and APPHOST2).
In the General Cluster Information section of the Clustering page, click Edit.

The Edit General Cluster Information dialog box appears.
In the Propagate Invalidation field, select Yes to indicate that you want invalidation requests from cache cluster members to be propagated to other cache cluster members.
Click Submit.
In the Cluster Members table of the Clustering page, default values are displayed for the current cache. Select the APPHOST1 cluster member and click Edit Selected.

The Edit Cluster Member dialog box appears.

In the Capacity field, enter 0.

Note:

If you assign a capacity of 0 to all cluster members, no requests will be forwarded between cluster members. With this setup, you can propagate the configuration and invalidation across all cache cluster members, simplifying the administration of many caches.

Click Submit.
Return to the Cluster Members table of the Clustering page and select APPHOST2.
In the Capacity field, enter 0.
Click Submit.

Before you can add APPHOST3 and APPHOST4 to the cluster, the following conditions must be in effect:

The cache must be started.
The administrator password of the cache to be added must be the same as the administrator password of the cache on APPHOST1. If it is different, you must connect to the cache's admin server and modify the administration password. For more information, refer to "Task 2: Modify Security Settings" in Chapter 8, "Setup and Configuration" in Oracle Application Server Web Cache Administrator's Guide.

9.1.4.2.1 Adding Caches to the Invalidation-Only Cluster

You must now add the APPHOST3 and APPHOST4 caches to the cluster using OracleAS Web Cache Manager on APPHOST1.

To add a cache to the cluster in OracleAS Web Cache Manager:

In the navigator frame, select Properties > Clustering.

The Clustering page appears.
In the Cluster Members section of the Clustering page, click Add.

The Add Cache to Cluster dialog box appears.
In the Host Name field, enter apphost3.mycompany.com as the host name of the cache to be added to the cluster.
In the Admin Port field, enter 9400 for the administration port for the cache to be added to the cluster.
In the Protocol for Admin Port field, select either HTTP to accept HTTP browser requests.
In the Cache Name field, enter apphost3.mycompany.com-webcache.
Click Submit.

The cache is now part of the cluster and is listed in the Cluster Members table.
Repeat Steps 2 through 7, substituting apphost4 in the Host Name and Cache Name fields.
Click Apply Changes.

OracleAS Web Cache adds the cache-specific information from the new cache cluster members to the cluster configuration.
For each cluster member, set the Capacity to 0. To do this, select Properties, then Clustering. Select a cluster member and click Edit. In the Edit Cluster Member dialog box, set the Capacity to 0.
Propagate the configuration to all cluster members.

When you modify the cluster and apply changes, OracleAS Web Cache adds the cache-specific information from the new cache cluster members to the configuration. For those changes to take affect in all cluster members, you must propagate the configuration and restart the cache server process of the cluster members.

To propagate the configuration to new cluster members in OracleAS Web Cache Manager:
1. In the navigator frame, select Operations > Cache Operations.
  
  The Cache Operations page appears. The Operation Needed column indicates the caches to which the configuration should be propagated.
2. Propagate the configuration to all cache cluster members:
  - Select All caches in the Operate On field.
  - Select an Interval of Immediate. (No other interval is allowed for propagation.)
  - Click Propagate.
  When the operation completes, the Operation Needed column in the Cache Operations page indicates the cluster members that need to be restarted.
3. Stop and restart all cluster members:
  - Select All caches in the Operate On field.
  - Select an Interval to stagger the time that operation begins on the caches, and then click Restart.
    
    When the operation completes, the Operation Needed column in the Cache Operations page indicates that no operations are needed. The cache cluster is ready to use.
Ensure that the administration and invalidation ports are closed to traffic coming from outside the network.

9.1.4.3 Disabling External to Internal Communication Through the Firewall

To disable external to internal communication through the firewall, perform the following steps:

Disable the administration port from external middle tier to internal middle tier.
Ensure that the network packets cannot be sent from the external to the internal OracleAS Web Cache administration and invalidation ports, using telnet.
Ensure that network packets can be sent from the internal to the external OracleAS Web Cache for both the administration and invalidation ports.

The communication paths and ports should now be as listed in Table 9-1:

Table 9-1 Communication Path and Ports Used by Network Packets

Communication Path	Ports to be enabled
Internal WebCache 1 to External WebCache 1	Port 9400 and Port 9401
Internal WebCache 2 to External WebCache 1	Port 9400 and Port 9401
Internal WebCache 1 to External WebCache 2	Port 9400 and Port 9401
Internal WebCache 2 to External WebCache 2	Port 9400 and Port 9401

Note:

For network security reasons, you should perform any additional cluster configuration from a Web Cache instance on one of the internal middle tiers. Any Web Cache instance in the cluster can be used to administer the cluster, but if you want to use an external OracleAS Web Cache instance, you must temporarily open the administration port in the firewall to allow external to internal traffic.

9.1.5 Configuring the First Internal Middle Tier on APPHOST3 for Load Balancing Router Access

Configure the Load Balancing Router to accept requests on port 80 and forward them to the OracleAS Web Cache port (7777) running on APPHOST3. To do this:
1. Set up a group, or pool, on the Load Balancing Router, to which individual servers can be added. See the Load Balancing Router documentation for instructions on how to do this.
2. Add the desired servers' IP addresses and port numbers to the group.
3. Create a virtual server that listens on port 80, and balances requests among the members of the group. See the Load Balancing Router documentation for instructions on how to do this.
4. Ensure that the Load Balancing Router translates the port on which it is listening to forward requests to the port on which OracleAS Web Cache is listening.
Configure the OracleAS Portal middle tier on APPHOST3 to allow underlying components to construct URLs based on the Load Balancing Router host name (internal.mycompany.com) and Load Balancing Router port number (80), so that self-referential URLs rendered on OracleAS Portal pages are valid for the browser. To do this, define a virtual host as follows:
1. Access the Oracle Enterprise Manager 10g Application Server Control Console.
  
  Typically the Application Server Control Console is located at http://www.xyz.com:1810.
2. Click the link for the middle tier where OracleAS Portal is installed.
3. Ensure that the server name, internal.mycompany.com, is listed in the table.
4. Click the Administration link.
5. Click Advanced Server Properties.
6. Select the httpd.conf file.
7. Add a VirtualHost container, as shown in the following example:
```
NameVirtualHost *:7778

<VirtualHost *:7778>
     ServerName internal.mycompany.com
     Port 80
     ServerAdmin you@your.address
     RewriteEngine On
     RewriteOptions inherit
</VirtualHost>
```
8. Click Apply.
9. When prompted to restart Oracle HTTP Server, click No.
Define a second virtual host, using the same steps as for the first, with the following exceptions:
- Specify apphost3.mycompany.com as the Server Name.
- Specify 7777 for the Port directive in the VirtualHost container.
- When prompted to restart the Oracle HTTP Server, click Yes.
Define a site that matches the virtual host entry created in the previous step, using OracleAS Web Cache Manager on APPHOST3, as follows:
1. Access the OracleAS Web Cache Manager on APPHOST3, as described in the Oracle Application Server Web Cache Administrator's Guide.
2. From Properties, click Sites.
3. Click Create under Named Sites Definitions.
4. On the Create Named Site page, specify internal.mycompany.com for the Host and 80 for Port. Keep the default values for all other fields.
5. Click OK. internal.mycompany.com now appears in the Named Sites Definitions table.

Use OracleAS Web Cache Manager on APPHOST3 to add APPHOST3 as an origin server to the OracleAS Web Cache cluster created in Section 9.1.4.2, "Configuring the Caches". This will update the routing table. To add APPHOST3, follow these steps:

Click Origin Server under Origin Servers, Sites, and Load Balancing.
In the Origin Server page, click Add under the Application Web Servers table.

In the Add Application Web Server page, provide the following information:

Property	Value
Hostname	`apphost3.mycompany.com`
Port	`7778` (APPHOST3 Oracle HTTP Server listening port)
Routing	`ENABLED`
Capacity	`100`
Failover Threshold	`5`
Ping URL	`/`
Ping Interval	`10`
Protocol	`HTTP`

Click Submit.
To verify that the origin server has been added properly, locate apphost3.mycompany.com in the Origin Server table.

Note:
Refer to the section "Map Sites to Origin Servers" in Oracle Application Server Web Cache Administrator's Guide, for more information.

Use OracleAS Web Cache Manager on APPHOST3 to map the site internal.mycompany.com to the middle tier apphost3.mycompany.com.
1. In the navigation frame, select Site-to-Server Mapping under Origin Servers, Sites, and Load Balancing.
2. In the Site-to-Server Mapping page, select the first mapping in the table and click Insert Above.
3. In the Edit/Add Site-to-Server Mapping page, select the Select from Site definitions option and then select internal.mycompany.com.
4. In the Select Application Web Servers section, select the application server on APPHOST3 (apphost3.mycompany.com) specified in the Origin Servers page.
5. Click Submit.
6. Click Apply Changes on the top of the page.
7. In the Cache Operations page, click Restart to restart OracleAS Web Cache on APPHOST3.
To verify that the site has been mapped correctly, navigate to the Site-to-Server Mapping page, and ensure that APPHOST3 is mapped to the site internal.mycompany.com.
Configure the apphost3.mycompany.com computer so that it can resolve the Load Balancing Router hostname to have the correct IP address. You can use DNS resolution, or create an entry in the /etc/hosts file as follows:

xxx.xxx.240 internal.mycompany.com
Note:

Ensure that the /etc/hosts file does not have an entry that points the local hostname to 127.0.0.1. For example:

127.0.0.1 apphost3.mycompany.com

Configure the Load Balancing Router to perform Network Address Translation (NAT) bounce back for loopback requests coming from the Parallel Page Engine running on apphost3.mycompany.com. This ensures that when the Parallel Page Engine makes a loopback request to OracleAS Web Cache, there are no errors.

Notes:

NAT bounce back is set up differently on individual Load Balancing Routers. See the Load Balancing Router configuration guide on how to set this up.
The log files contain the NAT bounce back addresses for all loopback requests from the Parallel Page Engine, that get forwarded to OracleAS Web Cache or Oracle HTTP Server through the Load Balancing Router.

Configure the Load Balancing Router (internal.mycompany.com) to accept invalidation requests from the OracleAS Metadata Repository on a separate port (9401 in this example), so that it is forwarded to the OracleAS Web Cache running on computer apphost3.mycompany.com on port 9401.

Notes:

This procedure load balances invalidations sent from the OracleAS Metadata Repository to the internal Web Cache instances. If high availability is a concern, then the Load Balancing Router may be configured to load balance to both the internal and external Web Cache instances. However, the internal Web Cache instances should be given a member priority of 1 and the external Web Cache instances a member priority of 2. The Minimum Active Members should be set to 1. With this configuration, the Load Balancing Router will load balance across the internal Web Cache instances first, and only load balance to an external Web Cache instance if all internal Web Cache instances are unavailable.

The Load Balancing Router does not have to listen on the OracleAS Web Cache invalidation port. On Load Balancing Routers that do not have port mapping ability, the port number must match the OracleAS Web Cache invalidation port.

Set up a group, or pool on the Load Balancing Router to which individual servers can be added.
Add the desired servers' IP addresses and port numbers to the group.
Create a virtual server that listens on port 9401, and balances requests between the members of the group.

Notes:

If the Load Balancing Router's port that is listening for the invalidation requests and the OracleAS Web Cache invalidation port are different, you must ensure that the Load Balancing Router translates the port that it is listening on to forward requests to the port that OracleAS Web Cache is listening on.
Use the Load Balancing Router documentation to set up the groups, and virtual server.
If the Oracle Application Server Infrastructure is behind another firewall, you must ensure that it can send invalidation messages to the Load Balancing Router.
For security reasons, the invalidation port on the Load Balancing Router (port 9401) must not be accessible from outside the network.

Copy the configuration settings for OracleAS Portal from the middle tier APPHOST1, to the middle tier APPHOST3. It is a good idea to make backup copies of the files on APPHOST3 first. To do this, perform the following steps:
1. Copy ORACLE_HOME/Apache/modplsql/conf/dads.conf from APPHOST1 to APPHOST3.
2. Copy ORACLE_HOME/Apache/oradav/conf/oradav.conf from APPHOST1 to APPHOST3.
3. Copy ORACLE_HOME/Apache/modplsql/conf/cache.conf from APPHOST1 to APPHOST3.
4. Copy MID_TIER_ORACLE_HOME/j2ee/OC4J_Portal/applications/portal/portal/WEB-INF/web.xml from APPHOST1 to APPHOST3.
  
  Note:
  If APPHOST1 and APPHOST3 are installed using different physical paths, you must ensure that the path elements are corrected after copying the files.
5. Copy the ORACLE_HOME/portal/conf/iasconfig.xml file from APPHOST1 to APPHOST3.

Edit the ORACLE_HOME/portal/conf/iasconfig.xml file to specify the correct farmname, hostname, and port used to access OracleAS Portal, and to perform the OracleAS Web Cache invalidation, as shown in Example 9-1 (all changes are shown in bold):

Example 9-1 iasconfig.xml File Edited to Include Farm Element

<IASConfig XSDVersion="1.0">

   <IASFarm Name="Farm-1.internal.mycompany.com" Host="internal.mycompany.com">
      <WebCacheComponent ListenPort="80" InvalidationPort="9401" InvalidationUsername="invalidator" InvalidationPassword="welcome1" SSLEnabled="false"/> 
   </IASFarm>

   <IASInstance Name="iAS.login.mycompany.com" Host="login.mycompany.com">
      <OIDComponent AdminPassword="@BVs2KPJEWC5a0l4n8lbTxUY=" PortSSLEnabled="true" LDAPPort="3060" AdminDN="cn=orcladmin"/>
   </IASInstance>

   <IASInstance Name="iAS-1.apphost3.mycompany.com" Host="apphost3.mycompany.com"> 
      <EMComponent ConsoleHTTPPort="1810" SSLEnabled="false"/>
   </IASInstance>

   <PortalInstance DADLocation="/pls/portal" SchemaUsername="portal" SchemaPassword="@Beyh8p2bOWELQCsA5zRtuYc=" ConnectString="cn=iasdb,cn=oraclecontext">
      <WebCacheDependency ContainerType="IASFarm" Name="Farm-1.internal.mycompany.com"/> 
      <OIDDependency ContainerType="IASInstance" Name="iAS.login.mycompany.com"/> 
      <EMDependency ContainerType="IASInstance" Name="iAS-1.apphost3.mycompany.com"/> 
   </PortalInstance> 

</IASConfig>

Note:

If OracleAS Web Cache on iAS-1.apphost3.mycompany.com (shown in Example 9-1) is not referenced by any other OracleAS Portal instance, you can remove the entry from iasconfig.xml, as seen in Example 9-1.

To enable monitoring of the Load Balancing Router's front-end host and port settings for OracleAS Portal, you must edit ORACLE_HOME/sysman/emd/targets.xml on APPHOST3, as follows:
1. Open targets.xml, using a text editor.
2. Search for OracleAS Portal targets, that is, TYPE="oracle_portal".
3. Edit the PortalListeningHostPort property, to point to the Load Balancing Router. For example:
```
<Property NAME="PortalListeningHostPort" VALUE=http://internal.mycompany.com:80/>
```
4. Save the changes to targets.xml.
5. Reload the targets in the Application Server Control Console by issuing this command in ORACLE_HOME/bin/:
  
  emctl reload
Ensure that the ORACLE_HOME environment variable is set.
Encrypt any plain text passwords in the iasconfig.xml configuration file. To do this, navigate to MID_TIER_ORACLE_HOME/portal/conf, and issue this command:

ptlconfig -encrypt
Save the manual configuration changes in the Distributed Configuration Management repository by issuing the following command on APPHOST3 in ORACLE_HOME/dcm/bin:

dcmctl updateconfig -ct ohs
Use the Application Server Control Console to access the mod_plsql configuration pages.
Select the portal DAD and click Edit.
Click Apply.

The required mod_rewrite and mod_oc4j directives are added.
Restart Oracle HTTP Server on APPHOST3 by issuing this command in ORACLE_HOME/opmn/bin:

opmnctl restartproc type=ohs

9.1.6 Configuring the Second Internal Middle Tier on APPHOST4 for Load Balancing Router Access

Configure the OracleAS Portal middle tier to allow underlying components to construct URLs based on the Load Balancing Router hostname (internal.mycompany.com) and Load Balancing Router port number (80). To do this, define a virtual host by performing the following steps:
1. Access the Oracle Enterprise Manager 10g Application Server Control Console.
  
  Typically the Application Server Control Console is located at http://www.xyz.com:1810. Refer to Chapter 7, "Monitoring and Administering OracleAS Portal" in Oracle Application Server Portal Configuration Guide for more information about using the Application Server Control Console.
2. Click the link for the middle tier where OracleAS Portal is installed.
3. Ensure that the server name internal.mycompany.com, is listed in the table.
4. Click the Administration link.
5. Click Advanced Server Properties.
6. Select the httpd.conf file.
7. Create a VirtualHost container as shown in the following example:
```
NameVirtualHost *:7778

<VirtualHost *:7778>
     ServerName internal.mycompany.com
     Port 80
     ServerAdmin you@your.address
     RewriteEngine On
     RewriteOptions inherit
</VirtualHost>
```
8. Click Apply.
9. When prompted to restart Oracle HTTP Server, click Yes.
Define a second virtual host, using the same steps as for the first, with the following exceptions:
- Specify apphost4.mycompany.com for the Server Name.
- Specify 7777 for the Port directive.
- When prompted to restart the Oracle HTTP Server, click Yes.
Copy the configuration settings for OracleAS Portal from the middle tier APPHOST3, to the middle tier APPHOST4. It is a good idea to make backup copies of the files first. To do this, perform the following steps:
1. Copy ORACLE_HOME/Apache/modplsql/conf/dads.conf from APPHOST3 to APPHOST4.
2. Copy ORACLE_HOME/Apache/oradav/conf/oradav.conf from APPHOST3 to APPHOST4.
3. Copy ORACLE_HOME/Apache/modplsql/conf/cache.conf from APPHOST3 to APPHOST4.
4. Copy MID_TIER_ORACLE_HOME/j2ee/OC4J_Portal/applications/portal/portal/WEB-INF/web.xml from APPHOST3 to APPHOST4.
  
  Note:
  If APPHOST3 and APPHOST4 are installed using different physical paths, you must ensure that the path elements are corrected after copying the files.
5. Copy the ORACLE_HOME/portal/conf/iasconfig.xml file from APPHOST3 to APPHOST4.
Synchronize the manual configuration changes performed on APPHOST4 with the DCM repository by issuing this command in ORACLE_HOME/dcm/bin/:

dcmctl updateconfig
Use the Application Server Control Console to access the mod_plsql configuration pages.
Select the portal DAD and click Edit.
Click Apply.

The required mod_rewrite and mod_oc4j directives are added.
Restart Oracle HTTP Server on APPHOST4 by issuing this command in ORACLE_HOME/opmn/bin:

opmnctl restartproc type=ohs
Configure the computer apphost4.mycompany.com to resolve the Load Balancing Router hostname to have the correct IP address. You can use DNS resolution for this, or create an entry in the /etc/hosts file as follows:

L1.L1.L1.L1 internal.mycompany.com
Note:
Ensure that the /etc/hosts file does not have an entry that points the local hostname to 127.0.0.1. For example:
127.0.0.1 apphost4.mycompany.com

Use OracleAS Web Cache Manager on APPHOST4 to add APPHOST4 to the OracleAS Web Cache cluster created in Section 9.1.4.2, "Configuring the Caches". This will update the routing table. To add APPHOST4, follow these steps:

Click Origin Server under Origin Servers, Sites, and Load Balancing.
In the Origin Server page, click Add under the Application Web Servers table.

In the Add Application Web Server page, provide the following information:

Property	Value
Hostname	`apphost4.mycompany.com`
Port	`7778` (APPHOST4 Oracle HTTP Server listening port)
Routing	`ENABLED`
Capacity	`100`
Failover Threshold	`5`
Ping URL	`/`
Ping Interval	`10`
Protocol	`HTTP`

Click Submit.
To verify that the origin server has been added properly, locate apphost4.mycompany.com in the Origin Server table.

Note:
Refer to the section "Map Sites to Origin Servers" in Oracle Application Server Web Cache Administrator's Guide, for more information.

Use OracleAS Web Cache Manager on APPHOST4 to map the Load Balancing Router site internal.mycompany.com to the two origin servers apphost3.mycompany.com and apphost4.mycompany.com, by performing the following steps:
1. In the navigation frame, select Site-to-Server Mapping under Origin Servers, Sites, and Load Balancing.
2. On the Site-to-Server Mapping page, Select the mapping for the Load Balancing Router site in the table and click Edit Selected.
3. In the Select Application Web Servers section, select an application Web server specified in the Origin Servers page for APPHOST4 (apphost4.mycompany.com).
4. Click Submit.
5. To verify that the site has been mapped correctly, ensure that both APPHOST3 and APPHOST4 are mapped to the site internal.mycompany.com in the Site to Server Mappings table.
  
  Note:
  Refer to the section "Map Sites to Origin Servers" in the Oracle Application Server Web Cache Administrator's Guide, for more information.
Refer to the section "Map Sites to Origin Servers" in Oracle Application Server Web Cache Administrator's Guide, for more information.
Click Apply Changes on the top of the page. Perform the following steps in the Cache Operations page:
1. Click Propagate to propagate changes to APPHOST4.
2. Click Restart to restart Web Caches on APPHOST3 and APPHOST4.

Configure the Load Balancing Router (internal.mycompany.com) to forward requests on the invalidation port to OracleAS Web Cache on the second middle tier apphost4.mycompany.com on port 9401 (similar to the previous configuration on the first middle tier apphost3.mycompany.com).

Notes:

Configure the Load Balancing Router (internal.mycompany.com) to forward requests on port 80 to OracleAS Web Cache on apphost2.mycompany.com on port 7777 (similar to the previous configuration on the first middle tier apphost3.mycompany.com).

Note:
Use the Load Balancing Router documentation to complete this step.

Configure the Load Balancing Router to perform Network Address Translation (NAT) bounce back for loopback requests coming from Oracle HTTP Server on apphost4.mycompany.com. Refer to Step 6 in "Configuring the First Internal Middle Tier on APPHOST3 for Load Balancing Router Access" for more information.

Note:

You can add more middle tiers by repeating the procedures in "Installing the Second Internal Middle Tier on APPHOST4" and "Configuring the Second Internal Middle Tier on APPHOST4 for Load Balancing Router Access", for each additional middle tier.

To enable monitoring of the Load Balancing Router's front-end host and port settings for OracleAS Portal, you must edit the ORACLE_HOME/sysman/emd/targets.xml file on APPHOST4, as follows:

Open the targets.xml file, using a text editor.
Locate the OracleAS Portal targets (that is, TYPE="oracle_portal").
Edit the PortalListeningHostPort property, to point to the Load Balancing Router. For example:
```
<Property NAME="PortalListeningHostPort" VALUE=http://internal.mycompany.com:80/>
```
Save the changes to targets.xml.

Reload the targets in the Application Server Control Console by issuing this command in ORACLE_HOME/bin/:

emctl reload

Note:

To verify if the internal middle tiers have been configured to work with the internal Load Balancing Router, you must perform the following steps:
1. Ensure that you can telnet to the listen and invalidation ports on the internal Load Balancing Router. To do this, leave APPHOST3 running and stop APPHOST4. Verify that you are able to contact port 80 on internal.mycompany.com from the intranet and specifically, from the infrastructure database computer(s), APPDBHOST*.mycompany.com. The command to check this is:
  
  telnet internal.mycompany.com 80
  
  Ensure that no connection failure message is returned. Verify that the invalidation port can be reached in the same manner from the APPDB computer(s). The command used to check this is:
  
  telnet internal.mycompany.com 9401
  
  Perform the following tests:
  - Access OracleAS Web Cache and Oracle HTTP Server through the LBR using the following URL:
```
http://internal.mycompany.com
```
  - Test the connection to the OracleAS Metadata Repository through the LBR, by accessing the following URL:
```
http://internal.mycompany.com/pls/portal/htp.p?cbuf=test
```
    The response should be test. If this succeeds, then the Oracle Application Server middle tier can connect to the OracleAS Metadata Repository. If this test fails, then examine the Oracle HTTP Server ORACLE_HOME/Apache/Apache/logs/error_log file to determine the cause.
2. Repeat the preceding steps with APPHOST3 stopped and APPHOST4 running.

9.1.7 Registering the Internal Middle Tier as a Partner Application

For the single sign-on component to work properly, it must always be referenced by a partner application with the same host name in the URL. This is because cookies are sent back only to the host that generated them. For example the Oracle Application Server Single Sign-On components must always be referenced as http://login.mycompany.com.

You must register internal.mycompany.com as a partner application. To do this, perform the following steps from an external middle tier, APPHOST1:

Add a partner application entry for internal.mycompany.com by executing the script OH/portal/conf/ptlconfig, as follows:

ptlconfig -dad portal -sso -host internal.mycompany.com -port 80
Edit the SSO registration script ORACLE_HOME/sso/bin/ssoreg as shown in Example 9-2, and then execute it. Example 9-2 shows the usage of ssoreg.sh on UNIX; on Windows, the script name is ssoreg.bat.

Note:
The script shown in Example 9-2 has multiple lines for readability only. When you execute the script, all parameters are on a single continuous line.
Example 9-2 ssoreg Usage on UNIX
```
ORACLE_HOME/sso/bin/ssoreg.sh
-site_name internal.mycompany.com
-mod_osso_url https://internal.mycompany.com
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME 
-config_file ORACLE_HOME/Apache/Apache/conf/osso/osso.conf
-admin_info cn=orcladmin
```

To verify whether the internal middle tier has been registered as a partner application, ensure that you can log in to the Portal at http://internal.mycompany.com.

9.1.8 Updating the Default JPDK Instance URL and Seeded Provider Group URLs

The Default JPDK Instance URL determines the middle tier on which a web provider is created. In this configuration, web providers must be created in the external middle tier.

Follow these steps to set the URL:

Log in to OracleAS Portal as the administrator (for example, PORTAL).
Click the Administer tab.
Click the Portal tab.
Click Global Settings in the Services portlet.
Click the Configuration tab.
For the Default JPDK Instance setting, change the URL to the external URL:

https://portal.mycompany.com/jpdk/servlet/soaprouter/
Click OK.
Click the Administer tab.
Click the Portlets tab.
In the Remote Provider Group portlet, enter oracle.ias.providers in the Name field.
Click Edit.
Click the Connection tab.
Change the URL to:

http://portal.mycompany.com/jpdk/soaprouter/
Click OK.
Repeat Steps 8 through 14, substituting oracle.sample.providers for the Remote Provider Group portlet name.

9.1.9 Configuring OracleAS Portal Invalidation Messages

You must configure OracleAS Web Cache invalidation messages to be sent from the OracleAS Portal schema in the OracleAS Metadata Repository to the internal middle tier. To do this, perform the following steps from an external middle tier, APPHOST1:

Update the iasconfig.xml file. Add the InvalidationHost property to the WebCacheDependency element with the following parameters:

<WebCacheDependency ContainerType="IASInstance" Name="Farm1.portal.mycompany.com" InvalidationHost="internal.mycompany.com"/>
Execute the ptlconfig script, located in the directory MID_TIER_ORACLE_HOME/portal/conf, in site mode, as shown in the following example:

ptlconfig -dad portal -site -wc -em

Note:

The administration URL, which is created using the OracleAS Web Cache host name that is on the Web Cache Global Settings tab, now points to the internal Web Cache instance. Any OracleAS Web Cache instance in the cluster can be used to administer the cluster, but if you want to use an external OracleAS Web Cache instance, you must temporarily open up the administration port in the firewall to allow external to internal traffic.

9.1.9.1 Verifying the OracleAS Web Cache Invalidation Messages Configuration

To verify that OracleAS Web Cache invalidation messages have been configured to be sent from the OracleAS Portal schema in the OracleAS Metadata Repository to the internal middle tier, perform the following steps:

Log in to Portal as the administrator.
Click the Administer tab.
Click the Portal tab.
Click Global Settings.
Click the Cache tab. In the Web Cache Host Settings section, the information displayed should be the same as the one in the iasconfig.xml file.

To verify if OracleAS Web Cache invalidation messages have been configured, perform the following steps:

Ensure that internal.mycompany.com and portal.mycompany.com are being used here.
Ensure that you can log in to internal site and add a portlet to a page.
Ensure that the updated page shows new content when accessed from the internal site.
Ensure that you can log in to the external site and add a portlet to a page.
Ensure that the updated page shows new content when accessed from the external and internal sites.

You must perform these steps with one middle tier stopped in each of the external and internal parts of the Web Cache cluster. Then, repeat the steps with the other middle tier stopped.

9.1.10 Configuring the OracleAS Portal Schema in the OracleAS Metadata Repository

Configure the OracleAS Portal schema in the OracleAS Metadata Repository to send host-independent invalidations. To do this, perform the following steps:

Log in to APPHost1 and run the script OH/portal/admin/plsql/wwc/cachhii.sql using SQL*Plus.
Specify on at the prompt to enable host-independent invalidations.

9.1.11 Modifying the Oracle Text Base Search URL

When creating a URL item and specifying a relative URL, then that URL will be resolved relative to the basehref of the page on which the URL link is being rendered. For OracleAS Portal pages, the basehref is always http://host:port/portal/pls/dad where the host, port, and DAD reflect the middle tier host from which that page was accessed. Therefore, when these URLs are rendered on an OracleAS Portal page, they are resolved relative to the base URL, http://host:port/portal/pls/dad.

The URL content is indexed by Oracle Text so that it can be searched within OracleAS Portal and the content referenced by the URL can be retrieved. Indexing is done outside the context of a page request, so there is no incoming request from which to determine the basehref to use when resolving relative URLs. Therefore, it is necessary to specify the basehref to use during indexing. This basehref should be to a host that is accessible from the database server. In most cases, this is the internal host.

To set the Oracle Text Base search URL to the internal host URL, perform the following steps:

In the Services portlet, click Global Settings page.

By default, the Services portlet is on the Portal sub-tab of the Administer tab on the Portal Builder page.
Select the Search tab.
Set the Base URL field under Oracle Text Base Search to http://host:port/portal/pls/dad, where host, port, and DAD are the host, port, and DAD for the internal host.

9.1.12 Enabling Session Binding on OracleAS Web Cache

The session binding feature in OracleAS Web Cache is used to bind user sessions to a given origin server to maintain state for a period of time. Although almost all components running in a default OracleAS Portal middle tier are stateless, session binding is required for two reasons:

The Web Clipping Studio, used by both the OracleAS Web Clipping portlet and the Web Page Data Source of OmniPortlet, uses HTTP session to maintain state, for which session binding must be enabled.

Enabling session binding forces all the user requests to go to a given OracleAS Portal middle tier, resulting in a better cache hit ratio for the portal cache.

Note:

Regardless of whether you have configured an LBR in your topology, you must enable session binding in OracleAS Web Cache, if you have more than one middle tier. In this configuration OracleAS Portal does not require session binding to be set up on the LBR.

To make OracleAS Web Cache bind the portal user session to the OracleAS Portal middle tier, perform the following steps:

In OracleAS Web Cache Manager on APPHOST3, click Session Binding under Origin Servers, Sites, and Load Balancing.
In the Session Binding page, select the LBR site name (internal.mycompany.com:80) in the table, and then click Edit Selected.
From the Please select a session drop-down list, change the session value to Any Set-Cookie.
From the Please select a session binding mechanism drop-down list, select Cookie-based.
Click Submit to apply the new settings to the site internal.mycompany.com:80.
To save your configuration changes, click Apply Changes at the top of the page.
On the Cache Operations page, click Propagate to propagate the changes.
Click Restart to restart OracleAS Web Cache on APPHOST3 and APPHOST4.

9.1.13 Configuring the Oracle Drive WebDAV Client

To configure the Oracle Drive WebDAV client, add the DAVParam, ORAPORTALUIURL, in the oradav.conf file. The oradav.conf file must be configured for both internal middle tiers. The syntax to add the parameter is as follows:

DavParam ORAPORTALUIURL

Here is an example of the ORAPORTALUIURL parameter setting in the oradav.conf file:

Options Indexes

DAV oracle

DAVDepthInfinity On

DavParam ORACONTAINERNAME wwdav

DavParam ORACookieMaxAge 28800

DavParam ORASERVICE cn=iasdb,cn=oraclecontext

DavParam ORAUSER portal

DavParam ORACRYPTPASSWORD BUpsf8IQI6Ow==

DavParam ORAPACKAGENAME portal.wwdav_api_driver

DavParam ORAPORTALUIURL http://internal.mycompany.com/pls/portal/

The addition of this parameter enables the Oracle Drive WebDAV client to have the extra OracleAS Portal menu options for the correct middle tier.

The extra Oracle Drive menu options are visible when you right-click a folder or file in the Oracle Drive user interface. This displays a set of menu options such as Set Properties, Change Access Control, Preview Content, View Versions, and View Page. These OracleAS Portal menu options require a URL to be in context with the selected folder or file.

9.1.14 Validating the Completed Configuration

To verify that your complete configuration is working as expected, perform the following steps:

To clear the contents stored in OracleAS Web Cache, restart APPHOST3 and APPHOST4, as follows:
1. Access the Application Server Control Console, typically located at http://apphost3.mycompany.com:1810.
2. Click the APPHOST3 instance.
3. Click Restart All.
4. Repeat the steps for APPHOST4.
Test access to OracleAS Portal through the Load Balancing Router by completing the following steps:
1. Access the OracleAS Portal home page at http://internal.mycompany.com/pls/portal.
2. Click the portal login link.
3. Click some links in the portal.
4. Confirm that content is getting cached in OracleAS Web Cache. To do this, access the OracleAS Web Cache Manager on APPHOST3 as described in Oracle Application Server Web Cache Administrator's Guide.
  
  Under Monitoring, click Popular Requests. select Cached from the Filter Objects drop-down list, and click Update. If you accessed OracleAS Portal, you will see portal content (For example, URLs that contain /pls/portal).
  
  Perform some basic page edits in OracleAS Portal, such as adding a portlet to a page, and verify that the new content shows up. If the new content does not display properly, or errors occur, OracleAS Web Cache invalidation is misconfigured.

9.2 Configuring a Reverse Proxy for OracleAS Portal and OracleAS Single Sign-On

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.

Figure 9-2 depicts the reverse proxy configuration described in this section. Only port 443 is designated as open on the firewall because in certain cases, port 80 may have to be closed. For example, if the IIS server is listening on both 443 and 80, and OracleAS Portal is using proxy:80 for Parallel Page Engine loopback, then port 443 must be open, and port 80 closed.

Figure 9-2 Reverse Proxy Server Configuration

Description of "Figure 9-2 Reverse Proxy Server Configuration"

This section explains how to configure a reverse proxy server for OracleAS Portal with OracleAS Single Sign-On. It contains these subsections:

Section 9.2.1, "Install and Configure the Proxy Server"

Section 9.2.2, "Testing the OracleAS Single Sign-On Connection"

Section 9.2.3, "Configuring OracleAS Single Sign-On to Use a Reverse Proxy"

Section 9.2.4, "Validating the OracleAS Single Sign-On Configuration"

Section 9.2.5, "Testing the OracleAS Portal Connection"

Section 9.2.6, "Configuring OracleAS Portal for a Reverse Proxy"

Section 9.2.7, "Validating the OracleAS Portal Configuration"

9.2.1 Install and Configure the Proxy Server

This section explains how to configure your choice of proxy server for the reverse proxy: OracleAS Web Cache, the Oracle HTTP Server, or the Internet Information Services (IIS) listener. (If necessary, you may also enable SSL communication on the Oracle HTTP Server, by following the instructions in the Oracle HTTP Server Administrator's Guide.)

Follow the instructions in one of these sections for the proxy server of your choice:

Section 9.2.1.1, "Configuring OracleAS Web Cache as a Reverse Proxy"
Section 9.2.1.2, "Configuring the Oracle HTTP Server as a Reverse Proxy"
Section 9.2.1.3, "Configuring Internet Information Services as a Reverse Proxy"

9.2.1.1 Configuring OracleAS Web Cache as a Reverse Proxy

Configuring OracleAS Web Cache as a reverse proxy may be done using two proxy host computers, as depicted in Figure 9-2, "Reverse Proxy Server Configuration". The topology elements used on two proxy host computers for OracleAS Web Cache are listed in Table 9-2. The instructions in this section explain how to define the login.mycompany.com site and map it to the idmhost.mycompany.com origin server, and define the portal.mycompany.com site and map it to the apphost1.mycompany.com origin server.

Note:

Alternatively, if you have a proxy host computer with two IP addresses, you may use one OracleAS Web Cache instance that listens on two ports (one for OracleAS Single Sign-On and the other for OracleAS Portal). See the Oracle Application Server Web Cache Administrator's Guide for instructions. This is one of the advantages of using OracleAS Web Cache as a reverse proxy server instead of the Oracle HTTP Server or IIS.

Table 9-2 Topology Elements for OracleAS Web Cache Reverse Proxy

Description	Value
OracleAS Web Cache proxy computer for OracleAS Single Sign-On	login.mycompany.com
OracleAS Web Cache proxy computer for OracleAS Portal	portal.mycompany.com
OracleAS Single Sign-On computer	idmhost.mycompany.com
OracleAS Single Sign-On computer Oracle HTTP Server listen port	7777
OracleAS Portal computer	apphost1.mycompany.com
OracleAS Portal OracleAS Web Cache listen port	7777
OracleAS Portal Oracle HTTP Server listen port	7778

9.2.1.1.1 Installing OracleAS Web Cache on the Proxy Computer

Install the standalone version of OracleAS Web Cache on login.mycompany.com and portal.mycompany.com, specifying 7777 as the listening port on each installation. OracleAS Web Cache is now listening on:

http://login.mycompany.com:7777

http://portal.mycompany.com:7777

9.2.1.1.2 Applying the OracleAS Web Cache Patch

OracleAS Web Cache can function solely as a software load balancer (no caching functions are performed). You must configure this mode to use it as a reverse proxy server for OracleAS Portal.

See "OracleAS Web Cache as a Software Load Balancer" in the Oracle Application Server Web Cache Administrator's Guide for instructions on configuring OracleAS Web Cache in this manner.

9.2.1.1.3 Creating Wallets for the Reverse Proxy Servers

The reverse proxy servers login.mycompany.com and portal.mycompany.com must have SSL credentials to serve requests. Follow these steps to create a wallet and obtain an SSL certificate:

Log in to the proxy host computer as the oracle user (the user that installed OracleAS Web Cache).
Start Oracle Wallet Manager by doing one of the following:

(UNIX) Issue this command in the WC_ORACLE_HOME/bin directory:

./owm

(Windows) Select these options:

Start > Programs > Oracle OracleAS Web Cache installation instance name > Integrated Management Tools > Wallet Manger
Click Wallet, then click New.

A dialog box appears with the message:

Your default wallet directory does not exist. Do you want to create it?
Click Yes.

A dialog box may appear with the following message:

Unable to create the system default wallet directory. Please contact your Oracle System Administrator for help. You can create a wallet but you must save it in another location. Do you want to continue anyway?
Click Yes.
Provide a wallet password and confirm it. Leave the wallet type as Standard.

A dialog box appears with the message:

A new empty wallet has been created. Do you want to create a certificate request at this time?
Click Yes.
Type the following:

Common Name: login.mycompany.com

Organizational Unit: organizational unit, such as IT

Organization: organization name

Locality/City: city

State/Province: state or province

Country: country

Key Size: 2048
Click OK.

A message appears, notifying you that the certificate was successfully created.
Copy the certificate request text from the body of this dialog and paste it into an e-mail message to send to a certificate authority, such as Verisign or Thawte.
Click OK.

The main Wallet Manager window reappears; the certificate status is now Requested.
When the certificate authority sends you the certificate, you must import it into the wallet. Select and copy all of the lines in the certificate, including ---BEGIN NEW CERTIFICATE REQUEST--- and ---END NEW CERTIFICATE REQUEST---.
Click Operations, then Import User Certificate.

The Import User Certificate dialog box appears.
Click Paste the Certificate, then click OK.

Another Import User Certificate dialog box appears with the following message:

Please provide a base64 format certificate and paste it below.
Paste the certificate into the dialog box, and click OK.

One of the following occurs:
- If the certificate received is in PKCS#7 format, it is installed, and all the other certificates included with the PKCS#7 data are placed in the Trusted Certificate list.
- If the certificate received is not in PKCS#7 format, and the certificate of its CA is not already in the Trusted Certificates list, then more must be done. Oracle Wallet Manager will ask you to import the certificate of the CA that issued your certificate. This CA certificate will be placed in the Trusted Certificates list. (If the CA certificate was already in the Trusted Certificates list, your certificate is imported without additional steps.)
  
  A message at the bottom of the window confirms that the certificate was successfully installed. The Oracle Wallet Manager main window reappears, and the status of the wallet changes to Ready.
Click Wallet, then Save as. Specify a location that is accessible to you (for example, WC_ORACLE_HOME/mycompany/wallet. If the directory does not exist, you can create it now.
Click Wallet, then check the Auto Login checkbox, then click Save As.

The following message appears:

A wallet already exists in the selected location. Do you want to overwrite it?
Click Yes.
Repeat all of the preceding steps on the portal.mycompany.com computer, specifying portal.mycompany.com as the Common Name in Step 8.
Click Wallet, then Exit.

9.2.1.1.4 Configuring the OracleAS Web Cache Listen Port

Follow these steps to configure OracleAS Web Cache to listen on port 443:

Access the Web Cache Administrator at:

http://login.mycompany.com:9400/webcacheadmin

The Web Cache Administrator password dialog appears.

Enter the OracleAS Web Cache administrator password.

Note:

At installation time, The OracleAS Web Cache administrator password is set to the same password as the ias_admin password. The OracleAS Web Cache administrator password must be identical for all cache cluster members.

The Web Cache Cache Operations page appears. A scrollable frame on the left side of the window contains groups of configuration elements. To access an element, click its link. The content area of the page is then populated with the values for that element.

Under Ports, click Listen Ports.
Click Add.
Enter the following:

IP Address: ANY

Port Number: 443

Protocol: HTTPS

Wallet: WC_ORACLE_HOME/mycompany/wallet
Click Apply Changes.
Exit the Web Cache Administrator.
Stop OracleAS Web Cache by issuing this command in ORACLE_HOME/opmn/bin:

opmnctl stopproc ias-component=WebCache
Start OracleAS Web Cache as the root user by issuing this command in ORACLE_HOME/webcache/bin:

webcachesetuser.sh setroot oracle user

In the preceding command, oracle user is the user that performed the OracleAS Web Cache installation.
Repeat all of the preceding steps on the portal.mycompany.com computer.

9.2.1.1.5 Configuring Sites, the Origin Server, and Site-to-Server Mappings

Follow these steps to configure the necessary site defnitions and mappings:

Access the Web Cache Administrator at:

http://login.mycompany.com:9400/webcacheadmin

The Web Cache Administrator password dialog appears.

Enter the OracleAS Web Cache administrator password.

Note:

Click the Site Definitions link in the Origin Servers, Sites and Load Balancing section.

The Site Definitions window opens.
Click Add Site.
Enter the following information (leave other fields blank):
- Host name: login.mycompany.com
- Port: 443
- Client-side Certificate: Not required
- Default Site: Yes
- Create Alias from Site Name with/without www: No
Click Add Alias.

The Add Alias for Site window opens.
Enter the following information:
- Host name: login.mycompany.com
- Port: 7777
Click Submit.
Click the Site-to-Server Mapping link in the Origin Servers, Sites, and Load Balancing section.

The Site-to-Server Mapping page appears, in which you map the site and site alias to an origin server.
Select the first mapping in the table and click Insert Above.

The Edit/Add Site-to-Server Mapping page appears.
Select the Select From Site Definitions option.
Select login.mycompany.com.
Select idmhost1.mycompany.com in the Select Application Web Servers section.
Click Submit.
Remove unused mappings or entries containing the wild card character *.
Click Apply Changes.
Click Restart.
Repeat all of the preceding steps on the portal.mycompany.com computer, substituting portal.mycompany.com as the site and apphost1.mycompany.com as the origin server (Select Application Web Servers section).

9.2.1.2 Configuring the Oracle HTTP Server as a Reverse Proxy

To use the Oracle HTTP Server as a reverse proxy, first install the standalone version of the Oracle HTTP Server on the reverse proxy server computer. This section explains how to configure the Oracle HTTP Server to pass incoming requests to Oracle Application Server Single Sign-On, Oracle Delegated Administration Services and OracleAS Portal, and modify all HTTP headers so that only the identity of the reverse proxy server computer is visible to clients.

There are two ways to configure the Oracle HTTP Server as a reverse proxy: using the ProxyPass and ProxyPassReverse directives, or the RewriteRule directive with the [P] (force proxy) flag. The RewriteRule directive is a more flexible and powerful implementation of the proxy functionality.

9.2.1.2.1 Using the ProxyPass, ProxyPassReverse, and ProxyPreserveHost Directives

These directives, used together, configure an external server to function as a reverse proxy. This section describes each directive, and gives an example of using them in the Enterprise Deployment configuration, in which the reverse proxy server computer is the local server, and APPHOST1 is the remote server.

The ProxyPass, ProxyPassReverse, and ProxyPreserveHost directives are implemented by mod_proxy, so they must appear in the httpd.conf file at a location following the LoadModule directive that loads mod_proxy. Similarly, the RewriteRule directive must appear at a location following the LoadModule directive that loads mod_rewrite.

In Apache 2.0, the ftp and http protocols are handled by separate modules, so you must add this directive to the httpd.conf file:

LoadModule proxy_http_module modules/mod_proxy_http.so

ProxyPass Directive

This directive causes the reverse proxy server computer to appear to be a mirror of APPHOST1.

The syntax of the ProxyPass directive is:

ProxyPass path url

path is the name of a local virtual path.

url is a partial URL for the remote server.

The Oracle HTTP Server documentation describes the ProxyPass directive in detail.

Example 9-3 shows the modifications to make to the ORACLE_HOME/Apache/Apache/conf/httpd.conf file on the reverse proxy server computer to configure reverse proxy functionality. Note that the ProxyRequests directive must be set to off when you use the ProxyPass directive.

Use the ProxyPassReverse directive in conjunction with the ProxyPass directive to achieve reverse proxy functionality.

ProxyPassReverse Directive

This directive causes the Oracle HTTP Server to adjust the URL in the Location header on HTTP redirect responses. This is necessary in a reverse proxy configuration, so that the reverse proxy is not bypassed on HTTP redirects from the servers behind the reverse proxy.

The syntax of the ProxyPassReverse directive is:

ProxyPassReverse path url

path is the name of a local virtual path.

url is a partial URL for the remote server.

The Oracle HTTP Server documentation describes the ProxyPassReverse directive in detail.

ProxyPreserveHost Directive (Apache 2.0.31 and later)

This directive, when set to On, directs the server to pass the Host: line from an incoming request to the proxied host instead of to the hostname specified by the ProxyPass directive.

This directive is normally set to Off. It is useful in configurations that require the original host header to be evaluated by the back end server.

Example 9-3 httpd.conf file on the Reverse Proxy Server Computer with ProxyPass, ProxyPassReverse, and ProxyPreserveHost Directives

# (Windows) Ensure that mod_proxy is loaded for these directives
LoadModule proxy_module modules/ApacheModuleProxy.dll

# (UNIX) Ensure that mod_proxy is loaded for these directives
LoadModule proxy_module libexec/mod_proxy.so
.
.
.
# (Apache 2.0)
LoadModule proxy_http_module modules/mod_proxy_http.so

ProxyRequests off
ProxyPass path http://apphost1.mycompany.com
ProxyPassReverse path http://apphost1.mycompany.com
# (Apache 2.0)
ProxyPreserveHost On

9.2.1.2.2 Using the RewriteRule Directive

You can use the RewriteRule directive to define URL rewriting rules and to pass requests through mod_proxy, using the [P] (force proxy) flag. The combined abilities enable a more powerful, flexible implementation of the functionality provided by the ProxyPass directive.

The RewriteRule directive relies on mod_proxy and mod_rewrite for its implementation, so the directive must appear in the httpd.conf file at a location following the LoadModule directives that load mod_proxy and mod_rewrite.

The syntax of the RewriteRule directive used for reverse proxy functionality is:

RewriteRule pattern substitution [P]

pattern is a regular expression that is applied to the current URL (the current URL is the value of the URL when the rule is applied).

substitution is the string that replaces the original URL that pattern matched

The [P] (force proxy) flag is used as a third argument to invoke the proxy functionality.

Note:

If multiple flags are used in a rewriting rule, ensure that:

There are no spaces between the brackets (that the flags are separated only by commas within the brackets). For example:
```
[I,P]
```
not
```
[I, P]
```
The P flag appears last, since it forces the substituted URL through the proxy module without processing any more rewriting rules.

This directive can be used multiple times, so that each occurrence of the directive defines a rewriting rule. At run time, the rewriting rules are applied in the order in which they are defined.

The Apache HTTP Server documentation describes the RewriteRule directive in detail.

Example 9-4 shows the modifications to make to the ORACLE_HOME/Apache/Apache/conf/httpd.conf file on the reverse proxy server computer to configure reverse proxy functionality.

Example 9-4 httpd.conf file on the Reverse Proxy Server Computer with RewriteRule Directive

# (Windows) Ensure that mod_proxy and mod_rewrite are loaded for this directive
LoadModule proxy_module modules/ApacheModuleProxy.dll
LoadModule rewrite_module modules/ApacheModuleRewrite.dll

# (UNIX) Ensure that mod_proxy and mod_rewrite are loaded for this directive
LoadModule proxy_module libexec/mod_proxy.so
LoadModule rewrite_module libexec/mod_rewrite.so
.
.
.
ProxyPassReverse / http://apphost1.mycompany.com

RewriteEngine On
RewriteRule ^/(.*) http://apphost1.mycompany.com/$1 [P] 

# (Apache 2.0)
ProxyPreserveHost On

9.2.1.2.3 Using the X-FORWARDED-HOST Value with Apache v. 1.3 mod_proxy

To ensure that the correct host name and port combination is passed to mod_osso, you must place a mod_perl script on the infrastructure instance to replace the header. (In Apache 2.0, this is not necessary, as the hostname header behavior is configurable with the ProxyPreserveHost directive.)

The Apache 1.3 version of mod_proxy always replaces the host header that was sent by the browser with a host header that contains the host and port information from the back end server. This is unacceptable to mod_osso, as it expects a match between the definition of the partner application and the host header.

When mod_proxy replaces the host header, it preserves the original host header information in another header called X-FORWARDED-HOST. Therefore, you can replace the value of the host header actually sent with the desired value from X-FORWARDED-HOST.

Follow these steps on the computer hosting the Infrastructure instance:

Create a mod_perl script file, ORACLE_HOME/perl/lib/site_perl/5.6.1/Apache/ForwardedHostReplace.pm, with these contents:

       package Apache::ForwardedHostReplace;

       use Apache::Constants qw(OK DECLINED);
       use Apache::URI (); 
       use strict; 

       sub handler { 
         my $r = shift; 
         my $forwardedhost = $r->header_in("x-forwarded-host"); 


         if ( $forwardedhost ) 
         { 
           $r->header_in("host", $forwardedhost); 
         } 

         return DECLINED; 
       } 

       1;

Add these directives to ORACLE_HOME/Apache/Apache/conf/httpd.conf:

PerlModule Apache::ForwardedHostReplace
PerlHeaderParserHandler Apache::ForwardedHostReplace

Restart the Oracle HTTP Server.

9.2.1.3 Configuring Internet Information Services as a Reverse Proxy

To use the Internet Information Services (IIS) listener as a reverse proxy for an Oracle Application Server instance, you must configure it using the Oracle Application Server Proxy Plug-in for Oracle HTTP Server. The Oracle Application Server Proxy Plug-in enables you to use a third-party HTTP listener, such as IIS, to send requests to Oracle Application Server. The OracleAS Proxy Plug-in is a reverse HTTP proxy; it forwards incoming HTTP requests to an Oracle Application Server instance.

The proxy logic is provided as a plug-in, a shared library that is loaded by IIS. The plug-in uses APIs provided with IIS to directly handle HTTP requests, similar to the way in which modules are plugged into Oracle HTTP Server.

The Oracle HTTP Server can mimic the address and port that IIS is using. That is, when sending a request to Oracle HTTP Server, the proxy can be configured to send a different Host: HTTP header than the actual hostname and port that the request is being sent to, so that downstream applications are shielded from the introduction of the reverse proxy. Appendix A of the Oracle HTTP Server Administrator's Guide describes the proxy plug-in in detail.

This section explains how to configure the IIS listener for use as a reverse proxy server with Oracle Application Server components, using the Oracle Application Server Proxy Plug-in.

Note:

Example host names are supplied in these instructions for clarity only; you may substitute names of your choice.

The instructions in this section assume existence of this computing environment:

A computer behind a firewall with an Oracle Application Server Infrastructure installed, with host name internalsso.mycompany.com
A computer behind a firewall with an OracleAS Portal middle tier installed, with host name internalportal.mycompany.com
A computer in front of a firewall, with host name login.mycompany.com, with the IIS server installed
A computer in front of a firewall, with host name portal.mycompany.com, with the IIS server installed

9.2.1.3.1 Installing the Oracle Application Server Proxy Plug-in

This section explains how to obtain and install the plug-in.

Note:

Example directory and file names are supplied in these instructions for clarity only; you may substitute names of your choice.

Obtain the OracleAS Proxy Plug-in from the Oracle Application Server 10g Companion CD, in the /plugins/iis/ directory.
Create a subdirectory, oracleproxy, in the configuration directory of the IIS listener on login.mycompany.com and portal.mycompany.com.
Place the OracleAS Proxy configuration files and shared libraries in the oracleproxy directory, and ensure that the IIS process has read and execute privileges to the oracleproxy directory.

9.2.1.3.2 Configuring the Oracle Application Server Proxy Plug-in

A single configuration file controls the functionality of the OracleAS Proxy Plug-in. The presence of the configuration file in the IIS file system activates the functionality. This section explains how to create the proxy configuration files in the oracleproxy directory on each computer.

Note:

Example file and parameter names are supplied in these instructions for clarity only; you may substitute names of your choice (some parameters contain host names, so ensure proper syntax). The example files include comments to describe the parameters.

On login.mycompany.com, use a text editor to create the proxy server definition file oproxydef, with the following parameters and values:

# Server names that the proxy plug-in will recognize. 
oproxy.serverlist=ssoserver

# Hostname to use when communicating with a specific server.oproxy.ssoserver.hostname=internalsso.mycompany.com

# Port to use when communicating with a specific server.oproxy.ssoserver.port=7777

# Hostname and port that clients use to access the third-party HTTP listener.
# This value will be passed as the Host: HTTP header.
oproxy.ssoserver.alias=login.mycompany.com

# Description of URL(s) that will be redirected to this server.oproxy.ssoserver.urlrule=/*

On portal.mycompany.com, use a text editor to create the proxy server definition file oproxydef, with the following parameters and values:

# Server names that the proxy plug-in will recognize. 
oproxy.serverlist=portal

# Hostname to use when communicating with a specific server.oproxy.portal.hostname=internalportal.mycompany.com

# Port to use when communicating with a specific server.
oproxy.portal.port=7777

# Hostname and port that clients use to access the third-party HTTP listener.
# This value will be passed as the Host: HTTP header.
oproxy.portal.alias=portal.mycompany.com

# Description of URL(s) that will be redirected to this server.oproxy.portal.urlrule=/*

9.2.1.3.3 Configuring the IIS Listener to Use the Oracle Application Server Proxy Plug-in

This section provides proxy plug-in configuration instructions for the IIS listener on Windows systems. The process involves creating Windows registry entries and using the IIS management console to add directories and filters. You must restart the listener after configuring the plug-in. To configure the plug-in, perform the following steps:

Disable the Oracle HTTP Server in the Oracle Application Server instance by performing these steps:
1. Navigate to the page for the Oracle Application Server instance in Oracle Enterprise Manager 10g Application Server Control Console.
2. Select the Oracle HTTP Server in the System Components list.
3. Click Enable/Disable Components.
Select Start > Run.
In the Run dialog box, type regedit.

The Registry Editor window opens.
Expand the HKEY_LOCAL_MACHINE folder (click the + preceding its name).
Expand the SOFTWARE folder (click the + preceding its name).
Click the ORACLE folder.
Select Edit > New > Key.

A new folder is added under the ORACLE folder with the name New Key #1.
Type IIS Proxy Adapter for the key name.
Select Edit > New > String Value.

A new value is added in the right window pane with the name New Value #1.
Type server_defs for the value name.
Select Edit > Modify.

The Edit String dialog box appears.
In the Value field, type the full path of the proxy server definition file and click OK.
(Optional) Specify a log file and logging level using the Edit > New > String Value procedure in steps 8-11.
1. Add a string value with the name log_file and the desired location of the log file (for example, d:\proxy\proxy.log)
2. Add a string value with the name log_level and a value for the desired log level. Valid values are debug, inform, error and emerg.
Using the IIS management console, add a new virtual directory to the IIS Web site with the same physical path as that of oracle_proxy.dll. Name the directory oproxy and give it execute access.
Using the IIS management console, right-click IIS Web Site, then choose Properties from the menu. Click the ISPI File Tab and add oracle_proxy.dll as a filter in the IIS Web site. The name of the filter should be oproxy and its executable must point to the directory containing oracle_proxy.dll (for example, d:\proxy\oracle_proxy.dll).
Stop, and then start the IIS Server, ensuring that the oproxy filter is marked with a green upward arrow.

For usage notes and troubleshooting information about the Oracle Application Server Proxy Plug-In, see Appendix A of the Oracle HTTP Server Administrator's Guide.

9.2.2 Testing the OracleAS Single Sign-On Connection

At this point, you can test the connection to OracleAS Single Sign-On by accessing the following URL:

http://login.mycompany.com:7777/pls/orasso

The Access Partner Applications page appears. However, the login link still points to internalsso.mycompany.com.

9.2.3 Configuring OracleAS Single Sign-On to Use a Reverse Proxy

The procedure for configuring OracleAS Single Sign-On to use a reverse proxy server comprises these tasks:

Ensuring that IP Checking is Off
Executing the ssocfg Script
Updating the targets.xml File
Updating the httpd.conf File
Registering mod_osso to Use the Proxy Host Name
Updating the Single Sign-On Configuration

9.2.3.1 Ensuring that IP Checking is Off

Access the following URL:

http://idmhost1.mycompany.com:7777/pls/orasso

The Access Partner Applications page appears.
Click Login.

The Login page appears.
Enter the administrator's user name and password and click Login.

The Home page appears.
Click SSO Server Administration.

The SSO Server Administration page appears.
Click Edit SSO Server Configuration.

The Edit SSO Server page appears.
Ensure that the Verify IP addresses for requests made to the SSO server box is deselected.

9.2.3.2 Executing the ssocfg Script

Issue this command in ORACLE_HOME/sso/bin:

ssocfg.sh https proxyName proxyHttpsPort (UNIX)

ssocfg.bat https proxyName proxyHTTPsPort (Windows)

9.2.3.3 Updating the targets.xml File

Open the ORACLE_HOME/sysman/emd/targets.xml file and locate the target type oracle_sso_server.

Update the HTTPMachine and HTTPPort attributes with the proxy server host and port attributes that were passed to ssocfg. For example:

<Property NAME="HTTPMachine" VALUE="proxyName"/>
<Property NAME="HTTPPort" VALUE="proxyHttpsPort"/>
<Property NAME="HTTPProtocol" VALUE="https"/>

Save and close the file.
Reload the Application Server Control Console by issuing this command:

ORACLE_HOME/bin/emctl reload

9.2.3.4 Updating the httpd.conf File

Access the Oracle Enterprise Manager 10g Application Server Control Console.
Click the link for the instance to configure.
Click the HTTP Server link.
Click the Administration link.
Click Advanced Server Properties.
Select httpd.conf.

An editor window opens for the httpd.conf file.
Change the ServerName and Port directive values to the proxy server host and port values that were passed to ssocfg. For example:
```
KeepAlive off
ServerName proxyName
Port proxyPort
```
Navigate to the end of the file.

Create a virtual host container. This causes the single sign-on login module in OC4J_SECURITY to be invoked when a user logs into the proxy server.

# UNIX
LoadModule certheaders_module libexec/mod_certheaders.so

# Windows
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll

NameVirtualHost idmhost1.mycompany.com:7777

<VirtualHost idmhost1.mycompany.com:7777>
  ServerName login.mycompany.com
  Port 443
  RewriteEngine On
  RewriteOptions inherit
  SimulateHttps On
</VirtualHost>

9.2.3.5 Updating Oracle Internet Directory with the Operation URL

You must modify the Delegated Administration Services URL in Oracle Internet Directory. To do this, follow these steps on IDMHOST1:

Use a text editor to create a file named setdasurl.ldif with these contents:

dn:cn=OperationURLs,cn=DAS,cn=Products,cn=OracleContext
changetype: modify
replace: orcldasurlbase
orcldasurlbase: https://login.mycompany.com/

Set the ORACLE_HOME environment variable to specify the Oracle home in which ldapmodify is available.
Issue this command:

ldapmodify -D "cn=orcladmin" -w password -v -f setdasurl.ldif
Access OracleAS Portal at this URL:

http://APPHOST1.mycompany.com:7777/pls/portal
Log in as the portal user and provide the password defined during installation.
Click Administer, then Global Settings, then SSO/OID.
Check the Refresh Cache for OID Parameters box.
Click Apply.
Click OK.

9.2.3.6 Registering mod_osso to Use the Proxy Host Name

Set the ORACLE_HOME environment variable to the directory in which Oracle Application Server is installed, using the applicable command, substituting oraHome with the Oracle home directory:

UNIX (csh):

setenv ORACLE_HOME oraHome

UNIX (Bourne and ksh):

ORACLE_HOME=oraHome; export ORACLE_HOME

Windows:

set ORACLE_HOME oraHome
Execute the ssoreg script by issuing one of the following commands in ORACLE_HOME/sso/bin. The command and parameters are shown on separate lines for readability; optional parameters are bracketed. Descriptions of all parameters are given in Table 9-3.

UNIX:

ssoreg.sh

-oracle_home_path oracleHome

-site_name siteName

-config_mod_osso TRUE

-mod_osso_url https://login.mycompany.com

[-virtualhost]

[-update_mode CREATE | DELETE | MODIFY]

[-config_file configFilePath]

[-admin_info adminInfo]

[-admin_id adminId]

Windows:

ssoreg.bat

(Parameters are the same as for UNIX.)

Restart the Oracle HTTP Server by issuing this command:

ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server

Table 9-3 ssoreg Parameters

Parameter	Description
oracle_home_path	Absolute path to the Oracle home.
site_name	The host name and port of the partner application.
config_mod_osso	Indicates that mod_osso is the application being registered. This parameter must be included in order for the osso.conf file to be generated.
mod_osso_url	The URL used to access the partner application. This parameter must be specified in the format http://host.domain. For example: https://www.mycompany.com
virtualhost	(Optional) Indicates that a virtual host is being registered with the single sign-on server.
update_mode	(Optional) Creates, deletes, or modifies the partner registration record.
config_file	(Optional)Location of the osso.conf file for the virtual host, if one is being configured. For example: ORACLE_HOME/Apache/Apache/conf/osso/virtual_host_name/osso.conf.
admin_info	(Optional) User name of the mod_osso administrator.
admin_id	(Optional) E-mail address of the mod_osso administrator.

Log in to the OracleAS Single Sign-On Administration page as the Administrator, and use the Administer Partner Applications page to delete the entry for the partner application apphost1.mycompany.com.

9.2.3.7 Updating the Single Sign-On Configuration

Update the DCM metadata repository with the changes to the local files by issuing this command in ORACLE_HOME/dcm/bin:

dcmctl upateconfig
Restart the single sign-on middle tier by issuing these commands in ORACLE_HOME/bin:

opmnctl restartproc process-type=HTTP_Server

opmnctl restartproc process-type=OC4J_SECURITY

9.2.4 Validating the OracleAS Single Sign-On Configuration

Follow these steps to ensure that the OracleAS Single Sign-On configuration is functioning as it should.

Access the following URL:

https://login.mycompany.com/pls/orasso

The Access Partner Applications page appears. The login link now points to login.mycompany.com.
Click Login.

The Login page appears.
Enter the administrator's user name and password and click Login.

If the Home page appears (the login is successful), the proxy is configured correctly for OracleAS Single Sign-On.

9.2.5 Testing the OracleAS Portal Connection

At this point, you can test the connection to OracleAS Portal.

Access the following URL:

http://portal.mycompany.com/pls/portal

The OracleAS Portal page appears. However, the login link still points to internalsso.mycompany.com.

9.2.6 Configuring OracleAS Portal for a Reverse Proxy

After installing and configuring the reverse proxy server and configuring OracleAS Single Sign-On to use it, configure OracleAS Portal as described in this section.

The procedure for configuring OracleAS Portal to use a proxy server comprises these tasks:

Ensuring Validity of Self-Referential URLs Rendered on OracleAS Portal Pages
Configuring Loopback Communication to the Internal Server
Specifying the OracleAS Portal Published Address and Protocol
Configuring Seeded Providers and Locally Hosted Web Providers
Registering the Domain Name
Augmenting the Parallel Page Engine x509certfile for Web Providers Exposed Over SSL (Optional)
Registering Web Providers or Provider Groups Exposed over SSL (Optional)
Enabling the Federated Portal Adapter for SSL (Optional)
Registering OracleAS Portal as an Oracle Ultra Search Content Source (Optional)

9.2.6.1 Ensuring Validity of Self-Referential URLs Rendered on OracleAS Portal Pages

Follow thes steps to define a virtual host on the middle tier for the proxy server.

Use the Oracle Enterprise Manager 10g Application Server Control Console to access the OracleAS Portal middle tier page on APPHOST1. Start a browser and access http://hostname:1810 and click the link for the application server instance hosting OracleAS Portal.
Click the HTTP Server link.
Click the Administration link.
Click Advanced Server Properties.
Select httpd.conf.

An editor window opens for the httpd.conf file.
Navigate to the end of the file.

Create a virtual host container for the proxy server, as shown in the following example:

# UNIX
LoadModule certheaders_module libexec/mod_certheaders.so
# Windows
LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll

NameVirtualHost apphost1.mycompany.com:7778

<VirtualHost apphost1.mycompany.com:7778>
   ServerName portal.mycompany.com
   Port 443
   RewriteEngine On
   RewriteOptions inherit
   SimulateHttps On
</VirtualHost>

<VirtualHost apphost1.mycompany.com:7778>
   ServerName apphost1.mycompany.com
   Port 7777
   RewriteEngine On
   RewriteOptions inherit
</VirtualHost>

Click Apply.
Restart the Oracle HTTP Server when prompted.

9.2.6.2 Configuring Loopback Communication to the Internal Server

In order for the computer that hosts login.mycompany.com to be able to resolve the proxy name within the firewall, you must create entries in the local hosts file on that computer. For example:

# Sample HOSTS file
127.0.0.1 localhost
123.45.67.8 www.proxyName.com

If you do not provide the entries in the hosts file as specified in the sample hosts file example, then you need to configure the Oracle Application Server computer to recognize a proxy server that would take the request out to the Internet and back in through the reverse proxy server (www.proxyName.com), or configure the reverse proxy server's internal interface to respond to www.proxyName.com.

9.2.6.3 Specifying the OracleAS Portal Published Address and Protocol

The host name and port number by which OracleAS Portal is addressed is usually the OracleAS Web Cache host and port (since OracleAS Web Cache is usually configured as the first listener). However, in a configuration with a reverse proxy server in front of OracleAS Web Cache, the published host name and port will be that of the reverse proxy server.

In this configuration, the OracleAS Web Cache invalidation messages must be sent directly to the OracleAS Web Cache computer, as opposed to the reverse proxy server. When the published host name is different from the host name used for OracleAS Web Cache invalidation, you can use the Portal Dependency Settings file, iasconfig.xml, to specify these settings.

The iasconfig.xml file must be updated to provide the correct farm name, host name, and port information to access OracleAS Portal through the reverse proxy server, and to perform the OracleAS Web Cache invalidation.

Follow these steps to configure these settings:

Edit the ORACLE_HOME/portal/conf/iasconfig.xml file to include the entries shown in bold in Example 9-5.

Example 9-5 iasconfig.xml File Edited to Include Farm Element

<IASConfig XSDVersion="1.0">

<IASFarm Name="Farm-1.portal.mycompany.com" Host="portal.mycompany.com">
      <WebCacheComponent ListenPort="443" InvalidationPort="9401" InvalidationUsername="invalidator" InvalidationPassword="welcome1" SSLEnabled="true"/>
   </IASFarm>
<IASInstance Name="iAS-1.oid.mycompany.com" Host="oid.mycompany.com">      <OIDComponent AdminPassword="@BVs2KPJEWC5a0l4n8lbTxUY=" PortSSLEnabled="false" LDAPPort="389" AdminDN="cn=orcladmin"/>
</IASInstance>

<IASInstance Name="iAS-1.apphost1.mycompany.com" Host="apphost1.mycompany.com">       <EMComponent ConsoleHTTPPort="1810" SSLEnabled="false"/>
</IASInstance>

<PortalInstance DADLocation="/pls/portal" SchemaUsername="portal" SchemaPassword="@Beyh8p2bOWELQCsA5zRtuYc=" ConnectString="cn=iasdb,cn=oraclecontext">
      <WebCacheDependency ContainerType="IASFarm" Name=" Farm-1.portal.mycompany.com "/>
<OIDDependency ContainerType="IASInstance" Name="iAS-1.oid.mycompany.com"/>
<EMDependency ContainerType="IASInstance" Name="iAS-1.apphost1.mycompany.com"/>
</PortalInstance> 
</IASConfig>

Encrypt any plain text passwords in iasconfig.xml by issuing this command in ORACLE_HOME/portal/conf:

ptlconfig -encrypt

Update the WebCacheDependency element in the iasconfig.xml file to include the InvalidationHost property as shown in this example:

<WebCacheDependency ContainerType="IASFarm" Name=" Farm-1.portal.mycompany.com " InvalidationHost="internal.mycompany.com" />

Execute the ptlconfig script by issuing this command in ORACLE_HOME/portal/conf:

ptlconfig -dad portal -site -wc -em

9.2.6.4 Configuring the Parallel Page Engine Loop-Back with the Load Balancing Router on APPHOST1

In this step, you enable (non-SSL) loop-back communication between the proxy server and the Parallel Page Engine on APPHOST1.

Follow these steps to create the loop-back configuration:

Open the APPHOST1_ORACLE_HOME/j2ee/OC4J_Portal/applications/portal/portal/WEB-INF/web.xml file.
Locate the Page servlet section.

Add the lines shown in bold:

<servlet>
<servlet-name>page</servlet-name>
   <servlet-class>oracle.webdb.page.ParallelServlet</servlet-class>
          <init-param>
             <param-name>useScheme</param-name>
             <param-value>http</param-value>
          </init-param>
          <init-param>
             <param-name>usePort</param-name>
             <param-value>7777</param-value>
          </init-param>
          <init-param>
             <param-name>httpsports</param-name>
             <param-value>443</param-value>
          </init-param>
</servlet>

Save the web.xml file.
Save the manual configuration changes in the Distributed Configuration Management repository by issuing the following command on APPHOST1 in ORACLE_HOME/dcm/bin:

dcmctl updateconfig
Restart all components on APPHOST1 by issuing the following command in ORACLE_HOME/opmn/bin:

opmnctl stopall

opmnctl startall

9.2.6.5 Configuring OracleAS Web Cache with the Reverse Proxy Server on APPHOST1

You must configure a site definition, site alias, and a site-to-server mapping to make OracleAS Web Cache function correctly with the reverse proxy server. Use the Web Cache Manager, the graphical user interface provided for editing the configuration stored in the webcache.xml file.

Access the Web Cache Administrator at:

http://apphost1.mycompany.com:9400/webcacheadmin

The Web Cache Administrator password dialog appears.

Enter the OracleAS Web Cache administrator password.

Note:

Click the Site Definitions link in the Origin Servers, Sites and Load Balancing section.

The Site Definitions window opens.
Click Add Site.
Enter the following information (leave other fields blank):
- Host name: portal.mycompany.com
- Port: 443
- Client-side Certificate: Not required
- Default Site: Yes
- Create Alias from Site Name with/without www: No
Click Submit.
Select the radio button for the site for which the alias will be added (portal.mycompany.com).
Click Add Alias.

The Add Alias for Site window opens.
Enter portal.mycompany.com for the host name and 7777 for the port. (7777 is the value for the usePort parameter in the web.xml file in the Parallel Page Engine configuration.)
Click Submit.

The alias is added. An alias is needed in the configuration because Portal sends invalidation messages with the value of the HOST attribute in the invalidation message the same as the site name (in this case, portal.mycompany.com:443), but OracleAS Web Cache caches the portal content keyed on a host:port combination such as portal.mycompany.com:7777; thus, the invalidation is not executed. Therefore, it is necessary to define an alias, so that OracleAS Web Cache manages the content caching recognizing portal.mycompany.com:443 and portal.mycompany.com:7777 as one and the same, and thereby correctly invalidating OracleAS Portal content, although the content is keyed on a different host:port combination than the site name.
Click Add Alias.

A window with host name and port fields opens.
Enter portal.mycompany.com for the host name and 80 for the port.

Click Submit.

The alias is added.

Note:

An alias for port 80 is needed because the HOST header sent by the browser will be portal.mycompany.com (without a port number appended to it). Since OracleAS Web Cache is listening on the HTTP port, it will assume that the port number is 80 and use this to determine the site-to-server mapping, and for any cache key creation.

Click Apply Changes.
Click the Site-to-Server Mapping link in the Origin Servers, Sites, and Load Balancing section.

The Site-to-Server Mapping page appears, in which you map the site and site alias to an origin server.
Select the first mapping in the table and click Insert Above.

The Edit/Add Site-to-Server Mapping page appears.
Select the Select From Site Definitions option.
Select portal.mycompany.com.
Select apphost1.mycompany.com in the Select Application Web Servers section.
Click Submit.
Remove unused mappings or entries containing the wild card character *.
Click Apply Changes.
Click Restart.

9.2.6.6 Configuring Seeded Providers and Locally Hosted Web Providers

Edit the ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/omniPortlet/WEB-INF/web.xml file to include these parameters:

<context-param>
     <param-name>useScheme</param-name>
     <param-value>http</param-value>
</context-param>
<context-param>
     <param-name>usePort</param-name>
     <param-value>7777</param-value>
</context-param>

Issue this command in ORACLE_HOME/opmn/bin:

opmnctl restartproc ias-component=OC4J_Portal
Log in to OracleAS Portal as the administrator (for example, PORTAL).
Click Administer.
Click Portlets.
In the Remote Providers portlet, Name field, enter WEBCLIPPING.
Click Edit.
Click Connection.
In the URL field, change the protocol to http and the port in the URL to 7777.
Click OK.
Repeat steps 4 through 8, substituting OMNIPORTLET for WEBCLIPPING.
Add the proxy server to the hosts file.

When you register locally hosted Web providers (that is, Web providers operating on the same computer as OracleAS Portal), such as the JPDK sample provider, you must register them with the HTTP protocol, www.proxyName.com as the host name, and 7777 as the port number.

9.2.6.7 Registering the Domain Name

You must register the proxy server host name on a domain name server on the Internet.

9.2.6.8 Re-registering mod_osso on APPHOST1

Set the ORACLE_HOME environment variable to the current Oracle home.
Edit the SSO registration script ORACLE_HOME/sso/bin/ssoreg as shown in Example 9-6, and then execute it. Example 9-6 shows the usage of ssoreg.sh on UNIX; on Windows, the script name is ssoreg.bat.

Note:
The script shown in Example 9-6 has multiple lines for readability only. When you execute the script, all parameters are on a single continuous line.
Example 9-6 ssoreg Usage on UNIX
```
ORACLE_HOME/sso/bin/ssoreg.sh
-site_name portal.mycompany.com
-mod_osso_url https://portal.mycompany.com
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME 
-config_file ORACLE_HOME/Apache/Apache/conf/osso/osso.conf
-admin_info cn=orcladmin
-virtualhost
```
A partner application, portal.mycompany.com, is created.
Restart the Oracle HTTP Server by issuing this command:

ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server
Access the following URL:

https://login.mycompany.com/pls/orasso
Log in to the OracleAS Single Sign-On Administration page as the Administrator, and use the Administer Partner Applications page to delete the entry for the partner application apphost1.mycompany.com.

9.2.6.9 Augmenting the Parallel Page Engine x509certfile for Web Providers Exposed Over SSL (Optional)

If you use the IIS listener and registering Web provider exposed over HTTPS, you must augment the provider certificate to the x509certfile defined in the Parallel Page Engine's ORACLE_HOME/j2ee/OC4J_Portal/applications/portal/portal/WEB-INF/web.xml file. Add the x509certfile parameter as shown:

<servlet-name>page</servlet-name>
<servlet-class>oracle.webdb.page.ParallelServlet</servlet-class>
<init-param>
 <param-name>x509certfile</param-name>
 <param-value>C:\mySSLconfig\trustedCerts.txt</param-value>
</init-param>

9.2.6.10 Registering Web Providers or Provider Groups Exposed over SSL (Optional)

See Section 7.3.10 for instructions.

9.2.6.11 Enabling the Federated Portal Adapter for SSL (Optional)

See Section 7.3.11 for instructions.

9.2.6.12 Registering OracleAS Portal as an Oracle Ultra Search Content Source (Optional)

See Section 7.3.12 for instructions.

9.2.6.13 Using Oracle HTTP Server 1.3 as a Reverse Proxy for OracleAS Portal

When you use Oracle HTTP Server version 1.3 as a reverse proxy for OracleAS Portal, the configuration steps in this section are required in order to resolve OracleAS Portal OracleAS Web Cache invalidation.

On the OracleAS Portal middle tier:

Perform the steps specified in Section 9.2.1.2.3, "Using the X-FORWARDED-HOST Value with Apache v. 1.3 mod_proxy".
Access the Web Cache Administrator at:

http://apphost1.mycompany.com:9400/webcacheadmin

The Web Cache Administrator password dialog appears.

For the user name, enter ias_admin or administrator, and enter the OracleAS Web Cache administrator password.

Note:

The Web Cache Manager page appears. A scrollable frame on the left side of the window contains groups of configuration elements. To access an element, click its link. The content area of the page is then populated with the values for that element.
Click the Site Definition link in the Origin Servers, Sites, and Load Balancing section.

The Site Definition page appears.
Select the radio button for the site for which the alias will be added (apphost1.mycompany.com).

The Add Alias for Site window opens.
Enter portal.mycompany.com for the host name and 443 for the port.
Click Submit.
Click Apply Changes.
Click Restart.

9.2.7 Validating the OracleAS Portal Configuration

Perform this step to ensure that the OracleAS Portal configuration is functioning as it should.

Access the following URL:

http://myportal.mycompany.com/pls/portal

The OracleAS Portal page appears. The login link now points to login.mycompany.com.

Notes:

The Web Cache Administration link in the Services portlet will not work in this configuration. Use Oracle Enterprise Manager 10g Application Server Control Console on the computer hosting OracleAS Web Cache instead.

The Portal Services Monitoring link in the Services portlet will not work in this configuration.

9.3 Configuring J2EE and Web Cache on the Web Tier

This section explains how to install and configure myJ2EE using a J2EE and Web Cache installation on the Web Server Tier, instead of a standalone Oracle HTTP Server. Advantages to this configuration include the ability to use Oracle Enterprise Manager 10g Application Server Control Console to manage the Oracle HTTP Server, and the ability to manage all of the Oracle Application Server instances in the configuration as part of an Oracle Application Server File-Based Farm.

9.3.1 Installing and Configuring the Security Infrastructure

Follow the instructions in Section 6.1, "Installing and Configuring the Security Infrastructure".

9.3.2 Installing and Configuring the Application Tier

The application tier consists of multiple computers hosting middle tier Oracle Application Server instances in an Oracle Application Server File-Based Farm. Each instance contains multiple Oracle Application Server Containers for J2EE instances, hosting deployed applications. In the complete configuration, requests are balanced among the OC4J instances on the application tier computers to create a performant and fault tolerant application environment. Figure 2-1, "Enterprise Deployment Architecture for myJ2EECompany.com", shows the application tier (APPHOST1 and APPHOST2).

9.3.2.1 A Note About Port Assignments for the Oracle Application Server File-Based Farm

Before you begin installing and configuring the OracleAS File-Based Farm for myJ2EECompany, you should understand the implications of the default port assignments for Distributed Configuration Management, in the case of environments that require inter-instance communication across a firewall.

The Oracle Universal Installer assigns the ports described inTable 9-4 by default when the instance is installed.

Table 9-4 Oracle Universal Installer Default Port Assignments

Quantity Purpose/Description

Quantity	Purpose/Description
1	DCM Discovery Port. The first instance installed on a computer is assigned port 7100 for this; the second instance installed on a computer is assigned 7101, and so on. This is defined in the `ORACLE_HOME/dcm/config/dcmCache.xml` file, in the `discoverer` element (for example, `<discoverer discovery-port ="7100" original-"true" xmlns=""/>`
50	Range of ports for inter-instance communication: 7120 to 7179. These are defined in the `ORACLE_HOME/dcm/config/dcmCache.xml` file, in the port element (for example, `<port lower="7120" upper="7179">`.) After installation, you will probably want to limit the number of ports open on the firewall. The actual port needs for inter-instance communication are: 1 for the Oracle Enterprise Manager 10g Application Server Control Console on each instance 1 for the DCM daemon on each instance 1 for each dcmctl client operating on each instance

DCM Discovery Port. The first instance installed on a computer is assigned port 7100 for this; the second instance installed on a computer is assigned 7101, and so on. This is defined in the ORACLE_HOME/dcm/config/dcmCache.xml file, in the discoverer element (for example, <discoverer discovery-port ="7100" original-"true" xmlns=""/>

Range of ports for inter-instance communication: 7120 to 7179. These are defined in the ORACLE_HOME/dcm/config/dcmCache.xml file, in the port element (for example, <port lower="7120" upper="7179">.)

After installation, you will probably want to limit the number of ports open on the firewall. The actual port needs for inter-instance communication are:

1 for the Oracle Enterprise Manager 10g Application Server Control Console on each instance
1 for the DCM daemon on each instance
1 for each dcmctl client operating on each instance

If the ports in the range 7100 to 7179 were open on the firewall before installation, the instances in the farm will be able to communicate immediately after installation. Note that:

If you want the port assignments to be of a different numeric range from these, then, before installation, you must assign a DCM Discovery Port using the staticports.ini file, and select the Manual option during installation. (See Section B.3, "Using the Static Ports Feature with Oracle Universal Installer" for more information.) The range of ports will then be assigned accordingly, as specified in Table 9-4.
After installation of all instances, you should configure the firewall to close the unused ports within the assigned range on each instance.

The procedure for installing and configuring the Application Tier is the same as that for the primary configuration of myJ2EE. Perform all steps in these sections:

9.3.3 Installing and Configuring the Web Tier

The Web Tier consists of multiple middle tier Oracle Application Server J2EE and Web Cache instances, with only Oracle HTTP Server configured. The Oracle HTTP Servers which route the requests to the OC4J instances on the application tier computers.

9.3.3.1 Installing the Web Tier Application Servers on WEBHOST1 and WEBHOST2

Follow these steps to install an Oracle Application Server middle tier on WEBHOST1 and WEBHOST2:

Ensure that the system, patch, kernel and other requirements are met as specified in the Oracle Application Server Installation Guide. You can find this guide in the Oracle Application Server platform documentation library for the platform and version you are using.
Copy the staticports.ini file from the Disk1/stage/Response directory to a local directory, such as TMP. You will provide the path to this file during installation.

Edit the staticport.ini file to assign the following custom ports:

Oracle HTTP Server port = 7777
Oracle HTTP Server Listen port = 7778
Application Server Control port = 1810

Notes:

Ensure that these ports are not already in use by any other service on the computer. Using the Static Ports feature to install the Application Server Tier ensures that the port assignments will be consistent, if the ports are correctly specified in the file and the port is not already in use. If a port is incorrectly specified, the Oracle Universal Installer will assign the default port. If a port is already in use, the Oracle Universal Installer will select the next available port.

See Section B.3, "Using the Static Ports Feature with Oracle Universal Installer" for more information.

Start the Oracle Universal Installer as follows:

On UNIX, issue this command: runInstaller

On Windows, double-click setup.exe

The Welcome screen appears.
Click Next.

On UNIX systems, the Specify Inventory Directory and Credentials screen appears.
Specify the directory you want to be the oraInventory directory and the operating system group that has write permission to it.
Click Next.

On UNIX systems, a dialog appears, prompting you to run the orainstRoot.sh script.
Open a window and run the script, following the prompts in the window.
Return to the Oracle Universal Installer screen and click Next.

The Specify File Locations screen appears with default locations for:
- The product files for installation (Source)
- The name and path to the Oracle home (Destination)
Click Next.

The Select a Product to Install screen appears.

Figure 9-3 Oracle Universal Installer Select a Product to Install Screen

Description of "Figure 9-3 Oracle Universal Installer Select a Product to Install Screen"
Select Oracle Application Server 10g, as shown in Figure 9-3, and click Next.

The Select Installation Type screen appears.

Figure 9-4 Oracle Universal Installer Select Installation Type Screen

Description of "Figure 9-4 Oracle Universal Installer Select Installation Type Screen"
Select J2EE and Web Cache, as shown in Figure 9-4, and click Next.

The Product-Specific Prerequisite Checks screen appears.
Click Next.

The Confirm Pre-Installation Requirements screen appears.
Ensure that the requirements are met and click Next.

The Select Configuration Options screen appears.

Figure 9-5 Oracle Universal Installer Select Configuration Options Screen

Description of "Figure 9-5 Oracle Universal Installer Select Configuration Options Screen"
Select OracleAS Web Cache and OracleAS 10g Farm Repository, as shown in Figure 9-5, and click Next.

The Specify Port Configuration Options screen appears.
Select Manual, specify the location of the staticports.ini file, and click Next.

The Select Repository Type screen appears.

Figure 9-6 Oracle Universal Installer Select Repository Type Screen

Description of "Figure 9-6 Oracle Universal Installer Select Repository Type Screen"
Select Join an existing OracleAS File-based Farm, as shown in Figure 9-6, and click Next.

The Specify File-based Farm Repository screen appears.

Specify the host name of APPHOST1, and the DCM Discovery Port on which the OracleAS File-based Farm Repository listens, and click Next.

Note:

The port range 7100-7179 is used for communication between DCM instances. The first installed instance of an OracleAS File-Based Farm on a computer has port 7100 assigned as its DCM Discovery Port. A subsequently installed instance will use port 7101, and so on. See Section 9.3.2.1, "A Note About Port Assignments for the Oracle Application Server File-Based Farm" for more information.

The Specify Instance Name and ias_admin Password screen appears.

Specify an instance name and the Oracle Application Server administrator's password and click Next.

The Summary screen appears.
Click Next.

On UNIX systems, a dialog appears, prompting you to run the root.sh script.
Open a window and run the script, following the prompts in the window.
Return to the Oracle Universal Installer screen and click Next.

The Configuration Assistants screen appears. Multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, the End of Installation screen appears.
Click Exit, and then confirm your choice to exit.
Verify that the installation was successful by viewing the application server instance in Oracle Enterprise Manager 10g. Start a browser and access:

http://hostname:1810