Oracle E-Business Suite R12 Configuration in a DMZ

Applies to:

Oracle Application Object Library Information in this document applies to any platform.

Abstract

This document describes methods for making a subset of Oracle E-Business Suite Release 12 functionality accessible via the Internet to external users

Document History

Updated-Date: 31-OCT-2011

Oracle E-Business Suite R12 Configuration in a DMZ

This document describes methods for making a subset of Oracle E-Business Suite Release 12 functionality accessible via the Internet to external users

Summary

Oracle E-Business Suite Release 12 Configuration in a DMZ

Last Updated: October 31, 2011

The most current version of this document can be obtained in Oracle Metalink Note 380490.1. The change log at the end of this document tracks modifications.

Contents

� Section 1: Overview � Oracle E-Business Suite Release 12 Architecture in a DMZ Configuration � Terminology

� Section 2: DMZ Deployment Options � Option 2.1: Using a Reverse Proxy and an External Web Tier � Option 2.2: Using Separate Oracle E-Business Suite Release 12 Web Tiers � Option 2.3: Using HTTP Hardware Load Balancers in DMZ Configurations � Option 2.4: Using Reverse Proxies only in DMZ � Option 2.5: Using Hardware Load Balancers With No External Web Tier � Known Restrictions � Support Considerations

� Section 3: Required Patches for DMZ Configurations � Section 4: Creating an External Web Tier for E-Business Suite � Section 5: Configuring the E-Business Suite for DMZ Deployments

� 5.1: Update Hierarchy type � 5.2: Update Node Trust Level � 5.3: Update List of Responsibilities � 5.4: Configuration Details for Using Reverse Proxy and an external Web Tier in DMZ � 5.4.1: Update Oracle E-Business Suite Release 12 Applications Context File � 5.4.2: Run AutoConfig and Restart Oracle HTTP Server

Oracle E-Business Suite R12 Configuration in a DMZ [ID 380490.1]

Modified 21-DEC-2011 Type WHITE PAPER Status PUBLISHED

of 42

13/01/2012https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=WHITE%20PAPER&id=380490.1

� 5.5: Configuration Details for Using Separate E-Business Suite Release 12 Web Tier in DMZ � 5.6: Configuration Details for Using HTTP Hardware Load Balancers in DMZ � 5.6.1: Update Oracle E-Business Suite Release 12 Applications Context File � 5.6.2: Run AutoConfig and Restart Oracle HTTP Server � 5.7: Enable Oracle E-Business Suite Application Server Security � 5.8: Enable Distributed Oracle Java Object Cache Functionality: � 5.9 Configuration Details for Using reverse proxy with No External Web Tier � 5.9.1: Create new Context Files for the External Entry Point � 5.9.2: Verify and Update the New Context Files Created for the External Entry Point � 5.9.3: Run AutoConfig and Restart Oracle Applications Processes � 5.10 Configuration Details for Using Hardware Load Balancers with No External Web Tier � 5.10.1: Create new Context Files for the External Entry Point � 5.10.2: Verify and Update the New Context Files Created for the External Entry Points � 5.10.3: Run AutoConfig and Restart Oracle Applications Processes

� Appendices � A. List of External Facing Oracle E-Business Suite Release 12 Products � B. Oracle E-Business Suite Release 12 Product Specific Configurations � C. Configuration Option for Functionally Directed Load Distribution � D. Reverse Proxy Configuration � E. Configuring the URL Firewall � F. List of Ports to Open in a DMZ Configuration � G. Configuring Multiple Web Entry Points and DMZs with Single Sign On � H. Troubleshooting � I. Disabling E-Business Suite Release 12 Application Services on the External Web Tier � J. Disabling "About this page" Link From the Release 12 Login Page � K. Related Documentation

Section 1: Overview

This document describes methods for making a subset of Oracle E-Business Suite Release 12 functionality accessible via the Internet to external users. This document discusses supported network topologies and architectures for the E-Business Suite, including:

� The use of reverse proxy servers in demilitarized zones (DMZ) � The use of multiple domains -- where different E-Business Suite Release 12 users access the E-Business Suite via different URLs -- with multiple application servers � The use of hardware-based load-balancers in these configurations � The use of SSO servers within the DMZ

This document is intended for administrators who perform Oracle E-Business Suite Release 12 administration. It assumes knowledge of networking technologies. The procedures described in this document have security implications. Prior to the implementation of any configuration options described this document, E-Business Suite system administrators are strongly advised to review deployment architectures with their enterprise networking and security groups.

Oracle E-Business Suite Release 12 Architecture in a DMZ Configuration

When configuring Oracle E-Business Suite in a DMZ configuration, firewalls are deployed at various levels as shown in Figure F2 to ensure that only authorized traffic is allowed to cross the firewall boundaries. The firewalls ensure that if intrusion attempts against machines in the DMZ are successful, the intrusion is contained within the DMZ, leaving the the machines in the intranet unaffected.

The following configuration options are supported:

� Use of separate web node for external usage � Setting of server level profile values � Associating trust levels to application middle tier nodes � Limiting available responsibilities to a restricted set for the external web node � Deploying a reverse proxy in front of the external web node � Configuring a URL firewall and mod security in the reverse proxy � Running only essential Oracle E-Business Suite Application services on the external web tier

of 42


Terminology

Below are definitions of some of the terms that are used in this document:

Firewall

Firewalls control access between the internet and a corporation's internal network or intranet. Firewalls define which internet communications will be permitted into the corporate network, and which will be blocked. A well-designed firewall can foil many common internet-based security attacks.

DMZ

The DMZ, which stands for DeMilitarized Zone consists of the portions of a corporate network that are between the corporate intranet and the Internet. The DMZ can be a simple one segment LAN or it can be broken down into multiple regions as shown in Figure F2. The main benefit of a properly-configured DMZ is better security: in the event of a security breach, only the area contained within the DMZ is exposed to potential damage, while the corporate intranet remains somewhat protected.

Load Balancer

Load balancers distribute an application's load over many identically configured servers. This distribution ensures consistent application availability even when one or more servers fail.

Reverse Proxy

A reverse proxy server is an intermediate server that sits between a client and the actual web server and makes requests to the web server on behalf of the client. You can find more information on reverse proxy servers and how to configure them in appendix D. Reverse Proxy Configuration of this document.

Service

A service is a functional set of Oracle E-Business Suite application processes running on one or more nodes.

of 42


Node

A node is referred to as a server that runs a set of E-Business Suite R12 application processes or database processes. In a single node installation of Oracle E-Business Suite, all the application processes including the database processes run on one node whereas in a multi node installation, the processes run on multiple nodes.

Internal Applications Middle Tier

The internal applications middle tier is the server configured for internal users to access Oracle E-Business Suite. It runs the following major application services:

� Web and Forms Services � Administration and Concurrent Manager Services � Reports and Discoverer Services

External Applications Web Tier

The external applications web tier is the server configured for external users for accessing Oracle E-Business Suite. It runs the following application service:

� Web server

URL Firewall

URL Firewall contains a white list of URLs, for the externally exposed E-Business Suite Modules, that may be accessed from the Internet. You can find more information on URL Firewall and how to configure it in appendix E. Configuring the URL Firewall of this document.

Section 2: DMZ Deployment Options

Option 2.1: Using a Reverse Proxy and an External Web Tier

The architecture diagram in Figure F3 represents a reverse proxy in the demilitarized zone (DMZ) behind an external firewall, and an Oracle E-Business Suite Release 12 external web tier in another demilitarized zone behind an internal firewall. This option allows multiple domain names for external and internal middle tiers. For example, external users may access the E-Business Suite via "partners.external.com", and internal users may access the same E-Business Suite instance via "employees.internal.com".

In this configuration, the reverse proxy server can be set up with Oracle HTTP Server or third-party reverse proxy servers. Please refer to Appendix D. Reverse Proxy Configuration for more information on configuring the E-Business Suite to support reverse proxy servers.

In this configuration, the external Applications web tier is required to:

1. Restrict access to a limited set of Oracle Applications responsibilities for users logging in via the Internet 2. Allow user access to only Oracle E-Business Suite Release 12 products that can be deployed for Internet access

of 42


Option 2.2: Using Separate Oracle E-Business Suite Release 12 Web Tiers

The architecture diagram in Figure F4 represents an Oracle E-Business Suite Release 12 external web tier in a demilitarized zone (DMZ) behind a DMZ external firewall. This option allows multiple domain names for external and internal middle tiers. This deployment option requires the external Oracle E-Business Suite web tier in order to meet the same security requirements discussed in 2.1: Using a Reverse Proxy and an External Web Tier.



of 42


Option 2.3: Using HTTP Hardware Load Balancer in DMZ Configuration

The architecture diagram in Figure F5 represents multiple Oracle E-Business Suite Release 12 external web tiers that are load-balanced by a HTTP hardware load balancer in a demilitarized zone (DMZ) behind a DMZ external firewall. Another HTTP Layer Hardware load balancer is used to distribute load across multiple Oracle E-Business Suite internal middle tiers in the intranet. This option allows separate domain names for external and internal middle tiers to be deployed in a highly scalable and fault tolerant configuration.



of 42


Option 2.4: Using Reverse Proxy with no External Web Tier

The architecture diagram shown in the figure below represents a reverse proxy server configured to forward external client requests to an Oracle HTTP listener running on an intranet application middle tier server. In this configuration, internal and external users use different http listeners and oc4j processes to access Oracle E-Business Suite.

This configuration requires a distinct Oracle HTTP Server/OC4J instance configured per Web Entry Point. You can not share the configuration of one web entry point with another. For example, you can not share Oracle HTTP Server configured for internal.us.oracle.com with external.us.oracle.com . There has to be two Oracle HTTP Server/oc4j running for each of the Web Entry Points

of 42


Proceed to Section 5.9 for detailed instructions on how to configure the topology shown in the figure above.

You can also configure a dedicated middle tier server in the intranet and front end this server with a reverse proxy in the DMZ for external users. See diagram below:

of 42


Option 2.5: Using Hardware Load Balancers With No External Web Tier

The architecture diagram shown in the figure F11 below represents a hardware load balancer configured to balance the load from the external clients among the Oracle HTTP listeners running on the intranet application middle tier servers. In this configuration, internal and external users use different http listeners and oc4j processes to access the Oracle E-Business Suite. As shown in the diagram below, only the load balancer configured within the DMZ, while all the other servers remain within the intranet or the internal network. This configuration make use of the Shared file system technology described in Oracle Metalink Note 384248.1 and the internal servers effectively perform the functions of both the internal as well as the external web tier. Because in this configuration there is no external application tier and all application web nodes use the same file system with different configurations, then we can take advantage of the Shared File System technology described in Oracle Metalink Note 384248.1.

This configuration requires an instance of Oracle HTTP Server/OC4J configured per Web Entry Point. You can not share the configuration of one web entry point with another.

of 42


Proceed to Section 5.10.1 for detailed instructions to configure the topology shown in the figure F11 above.

Known Restrictions

Shared file system (APPL_TOP, COMMON_TOP, ORA_TOP) cannot be shared between external web tier and internal middle tier. However, this restriction does not apply to configuration Option 2.4: Using Reverse Proxy with no External Web Tier (Figure 9) where an external web tier is simulated on the same physical internal middle tier by using a 2nd NIC card.

Support Considerations

All customer configurations will be supported. However, the level of supportability will be dependent upon the implementation.

1. Customers who follow the instructions and implement a tested and certified topology as documented in this Note are fully supported. Oracle recommends the use of one of the configurations described in this Note. 2. Customers who implement an alternative topology not listed in this note are supported on a best-efforts basis . The Oracle Applications Technology Group will aim to provide an adequate solution to address a customerâ22s problem.

Severity 1 bugs in this category will only be accepted for situations where a customer's production system is down. Otherwise, an escalated Severity 2 status is the highest supported severity rating.

SSL Terminator Configuration

If you are terminating SSL connection at a web entry point other than the application tier node, you must ensure that ssl_terminator.conf file is included in the httpd.conf on the application tiers. For more information refer Oracle Metalink Note : 376700.1 "Enabling SSL in Oracle Applications Release 12".

of 42


Section 3: Required Patches for DMZ Configurations

No additional patches are currently required to support DMZs for E-Business Suite Release 12.

Section 4: Creating an External Web Tier for E-Business Suite

The process of implementing a DMZ configuration for your E-Business Suite environment will vary depending on the deployment option that you select. The implementation process described here assumes that you have a fully-configured E-Business Suite with an internal Application web tier, and that you would like to add an external web tier to that existing configuration. Regardless of the DMZ deployment option selected in Section 2, the following core steps must be completed:

Step 1. Identify Release 12 modules for external deployment

Verify that the Oracle E-Business Suite Release 12 modules that you need for external deployment have been certified for that configuration. A list of certified Oracle E-Business Suite modules for external deployment is listed in Appendix A - List of External Facing Oracle E-Business Suite Products. If you plan on deploying a product that is not listed, log a Service Request with Oracle Support requesting certification of that product for external deployment.

Step 2. Clone the internal web tier to create a new external web tier

Clone the internal Oracle E-Business suite middle tier to the machine that you identified to be the external web tier in the DMZ. For additional information on cloning Oracle Applications, see Metalink Note 406982.1 Cloning Oracle Applications Release 12 with Rapid Clone.

Step 3. Deploy a reverse proxy server (Optional)

If you plan to use a reverse proxy server in your configuration, deploy that server in front of your newly-created external Application web tier. See Appendix D. Reverse Proxy Configuration for more information on configuring the E-Business Suite to support reverse proxy servers.

Step 4. Ensure that network firewalls are configured correctly

Ensure that the network firewall rules have been defined correctly and are permitting authorized E-Business Suite traffic between all network segments:

1. Verify that access between intranet-based desktop clients and the internal Application web tier is permitted and working 2. Verify that access between the internal Application web tier and the Applications database server is permitted and working 3. If a reverse proxy server is not part of your deployment, communication between Internet-based desktop clients and the external web tier servers must be permitted and working. 4. If a reverse proxy server is configured:

� Communication between Internet-based desktop clients and the reverse proxy server must be permitted and working � Communication between the reverse proxy server and the external Application web tier must be permitted and working

5. Verify that access between the Applications external web tier servers to the Applications database server is permitted and working.

Section 5: Configuring the E-Business Suite for DMZ Deployments

This section provides the configuration instructions for the deployment models described in this document. Certain common configuration steps must be carried out regardless of which deployment model is used. The details for these common steps are explained from section 5.1 through section 5.4. After completing the common steps, you can proceed to either section 5.5, section 5.6 or section 5.7 depending on which deployment option is chosen.

5.1: Update Hierarchy Type

Several user profile options are used to construct various URLs in an E-Business Suite R12 environment. These user profiles are as follows:

User Profile Name Internal Name

1. Applications Web Agent APPS_WEB_AGENT

of 42


The default hierarchy type value for the above profile options is Security. See diagram below:

The configuration of the E-Business Suite environment for DMZ requires these profile options hierarchy type to be set to SERVRESP.

1. To change the profile options hierarchy type values to SERVRESP, execute the txkChangeProfH.sql SQL script as shown below:

2. After the txkChangeProfH.sql script executes successfully, run AutoConfig on all nodes to complete the profile options configuration.

5.2: Update Node Trust Level

Oracle E-Business Suite Release 12 has the capability to restrict access to a predefined set of responsibilities based on the Web server from which the user logs in. This capability is provided by tagging web servers with a trust level indicated by the Node Trust Level (NODE_TRUST_LEVEL) server profile option. The Node Trust Level indicates the level of trust associated with a particular web server. Currently, three trust levels are supported:

2. Applications Servlet Agent APPS_SERVLET_AGENT

3. Applications JSP Agent APPS_JSP_AGENT

4. Applications Framework Agent APPS_FRAMEWORK_AGENT

5. ICX:Forms Launcher ICX_FORMS_LAUNCHER

6. ICX: Oracle Discoverer Launcher ICX_DISCOVERER_LAUNCHER

7. ICX: Oracle Discoverer Viewer Launcher ICX_DISCOVERER_VIEWER_LAUNCHER

8. Applications Help Web Agent HELP_WEB_AGENT

9. Applications Portal APPS_PORTAL

10. BOM:Configurator URL of UI Manager CZ_UIMGR_URL

11. QP: Pricing Engine URL QP_PRICING_ENGINE_URL

12. TCF:HOST TCF:HOST

sqlplus apps/apps @/patch/115/sql/txkChangeProfH.sql SERVRESP

of 42


Administrative Servers marked as Administrative are typically those used exclusively by system administrators. These servers are considered secure and provide access to any and all E-Business Suite functions.

Normal Servers marked as Normal are those used by employees within a companyâ22s firewall. Users logging in from normal servers have access to only a limited set of responsibilities.

External Servers marked as External are those used by customers or employees outside of a companyâ22s firewall. These servers have access to an even smaller set of responsibilities.

The default value for this profile option for all E-Business Suite middle tiers is Normal. If you wish to learn more about the Node Trust Level profile option, please refer to Oracle Applications System Administrators Guide .

Set the NODE_TRUST_LEVEL profile option value on the external web tier in your Oracle E-business Suite Release 12 environment to External. See diagram below.

To change the value of the Node Trust Level profile option value to External for a particular node, perform the following steps:

1. Login to Oracle E-Business Suite as sysadmin user using the internal URL 2. Select the System Administrator Responsibility 3. Select Profile / System 4. From the 'Find system profile option Values' window, select the server that you want to designate as the external web tier 5. Query for %NODE%TRUST%. You will see a profile option named 'Node Trust Level'. The value for this profile option at the site level will be Normal. Leave this setting unchanged. 6. Set the value of this profile option to External at the server level. The site level value should remain set to Normal

5.3: Update List of Responsibilities

The steps described in this section are required only if you have marked any of the Oracle E-Business Suite Release 12 middle tiers as External as described in section 5.2.

After updating the server-level profile value for Node Trust Level for the external web tier(s) to External, users can no longer see any responsibilities when they login via the external web tier. In order for a responsibility to be available from the external E-Business Suite web tier, set the Responsibility Trust Level profile option value for that responsibility to External at the responsibility level. For information on additional product specific responsibilities that can be made externally accessible from the external E-Business Suite middle tier, please refer to Appendix B1. Oracle E-Business Suite Product Specific Configurations.

To change the value of the Responsibility Trust Level profile option at the responsibility level for a particular responsibility, perform the following steps:

1. Login to Oracle E-Business Suite as sysadmin user using the internal URL 2. Select System Administrator Responsibility 3. Select Profile / System 4. From the 'Find system profile option Values' window, select the responsibility that you want to make available to users logging in via the external web tier 5. Query for %RESP%TRUST%. You will see a profile option named 'Responsibility trust level'. The value for this profile option at site level will be Normal. Leave this setting unchanged. 6. Set the value of this profile option for the chosen responsibility to External at the responsibility level. The site-level value should remain Normal. 7. Repeat for all responsibilities that you want to make available from the external web tier.

of 42


5.4: Configuration Details for Using Reverse Proxy and an External Web Tier in DMZ

The steps described in this section assume that you have already set up the reverse proxy server of your choice and you are ready to make modifications to the Oracle E-Business Suite Applications Context file on the external web tier. To complete the configuration for this option, follow the steps given below.

5.4.1: Update Oracle E-Business Suite Applications Context File

On the external Oracle E-Business Suite web node, run the AutoConfig Context Editor as documented in the Oracle MetaLink note 387859.1 "Using AutoConfig to Manage System Configurations with Oracle Applications Release 12". In the Context Detail screen, set the following configuration values:

� set the webentry point, s_webentryhost, to the reverse proxy server � set the webentry domain, s_webentrydomain, to the domain name of the reverse proxy server � set the external URL, s_external_url to the external web node URL. � set the active webport, s_active_webport, to the port where the reverse proxy server listen for client requests. For example port 80 for HTTP or 443 for HTTPS � set the webentry protocol, s_webentryurlprotocol, to the protocol value the clients use to access the reverse proxy server � set the login page, s_login_page, to <webentry protocol>://<webentry host>.<webentry domain>:<active web port>. Replace <webentry protocol>, <webentry host>, <webentry domain>, and <active web port> with their respective values

� set the help web agent s_help_web_agent, to <webentry protocol>://<webentry host>.<webentry domain>:<active web port> . Replace <webentry protocol>, <webentry host>, <webentry domain>, and <active web port> with their respective values.

5.4.2: Run AutoConfig and Restart Oracle Application Server Processes

1. Run AutoConfig on each Applications middle tier . Please refer to the Oracle MetaLink note 387859.1 "Using AutoConfig to Manage System Configurations with Oracle Applications R12 " for more information on AutoConfig. 2. After AutoConfig completes successfully, restart Oracle Application server processes on the external web tier.

Proceed to the Appendices for any additional Oracle E-Business Suite product specific settings that needs to be done.

5.5: Configuration Details for Using Separate Oracle E-Business Suite Web Tier in DMZ

There are no extra steps needed for this configuration. Proceed to the Appendices for any additional Oracle E-Business Suite product specific settings that needs to be done.

5.6: Configuration Details for Using HTTP Hardware Load Balancers in DMZ

To complete the configuration for this option, follow the steps given below.

Oracle does not certify specific reverse proxy solutions from third-party vendors. The instructions included in this document are generally applicable to third-party reverse proxy solutions, including (but not restricted to) Apache, Microsoft Proxy Server, and other products.

of 42


5.6.1: Update Oracle Applications Context File

On the internal Applications middle-tier nodes, run the AutoConfig Context Editor as documented in the Oracle MetaLink note 387859.1 "Using AutoConfig to Manage System Configurations with Oracle Applications R12 ". In the Context Detail screen, set the following configuration values:

� set the webentry point, s_webentryhost, to the load balancer that is used to load balance the internal Applications middle tiers � set the webentry domain, s_webentrydomain, to the domain name of the load balancer � set the active webport, s_active_webport, to the value of the load balancer's external port � set the webentry protocol, s_webentryurlprotocol, to the load balancer's protocol e.g. "http" or "https". � set the login page, s_login_page, to <webentry protocol>://<webentry host>.<webentry domain>:<active web port>. Replace <webentry protocol>, <webentry host>, <webentry domain>, and <active web port> with their respective values

� set the help web agent, s_help_web_agent, to <webentry protocol>://<webentry host>.<webentry domain>:<active web port> . Replace <webentry protocol>, <webentry host>, <webentry domain>, and <active web port> with their respective values

On the external Applications web tier node, run the AutoConfig Context Editor as documented in the Oracle MetaLink note 387859.1 "Using AutoConfig to Manage System Configurations with Oracle Applications R12 ". In the Context Detail screen, set the following configuration values:

� set the webentry point, s_webentryhost, to the load balancer that is used to load balance the external Applications middle tiers � set the webentry domain, s_webentrydomain, to the domain name of the load balancer � set the external URL, s_external_url to the external web node URL. � set the active webport, s_active_webport, to the value of the load balancer's external port � set the webentry protocol, s_webentryurlprotocol, to the load balancer's protocol e.g. "http" or "https" � set the login page, s_login_page, to <webentry protocol>://<webentry host>.<webentry domain>:<active web port>. Replace <webentry protocol>, <webentry host>, <webentry domain>, and <active web port> with their respective values.

� set the help web agent, s_help_web_agent, to <webentry protocol>://<webentry host>.<webentry domain>:<active web port> . Replace <webentry protocol>, <webentry host>, <webentry domain>, and <active web port> with their respective values

5.6.2: Run AutoConfig and Restart Oracle Applications Processes

1. Run AutoConfig on each Applications middle tier to complete the configuration. Please refer to the Oracle MetaLink note 387859.1 "Using AutoConfig to Manage System Configurations with Oracle Applications R12 " for more information on AutoConfig.

2. After AutoConfig completes successfully, restart Oracle Applications server processes.

Proceed to the Appendices for any additional Oracle E-Business Suite product specific settings that needs to be done.

5.7: Enable Oracle E-Business Suite Application Server Security

Oracle E-Business Suite Release 12 is deployed in a multi-tier configuration with one Database Server and many possible middle-tier Application Servers. The Application Servers include Apache JSP/Servlet, Forms, Discoverer and also some client programs such as Application Desktop Integrator, Oracle Discoverer Admin Edition. Any program which makes a SQLNET connection to the Oracle E-Business Suite database needs to be trusted at some level. This security feature ensures that such SQLNET connections are coming from trusted machines and/or trusted programs.

The Server Security feature supports authentication of application server machines and code modules in order to access the database. When Server Security is activated, Application Servers are required to supply server IDs (like passwords) and/or code IDs to access a database server. Server IDs identify the machine from which the connection is originating. Code IDs identify the module and patch level from which the connection is originating. Code IDs are included in applications code by development. The database server can be set to allow access only from specific machines and/or by code at a desired patch level.

The application server security feature is activated by default for all E-Business Suite installations. It is recommended that you ensure that the server security feature is enabled by performing the steps given below:

Run the AutoConfig Context Editor as documented in the Oracle MetaLink note 387859.1 "Using AutoConfig to Manage System Configurations with Oracle Applications R12 ". In the Context Detail screen, review the following configuration values for both internal and external nodes:

� Value of Application Server Security Authentication (s_appserverid_authentication) is set to SECURE . If the value is not set to SECURE, follow the instructions given below: � Set the value of Application Server Security Authentication (s_appserverid_authentication) to SECURE � Run AutoConfig on each Applications middle tier to complete the configuration. Please refer to the Oracle MetaLink note 387859.1 "Using AutoConfig to Manage System Configurations with Oracle Applications R12 " for more information on AutoConfig

� After AutoConfig completes successfully, restart Oracle HTTP Server and OC4J processes

of 42


5.8: Enable Distributed Oracle Java Object Cache Functionality

Distributed caching functionality has to be enabled in a DMZ environment to avoid data inconsistencies for data such as profiles, menu, responsibilities and product specific data. To complete this configuration, follow the steps given below:

� Identify the highest number of JVMs that serve the oacore JVM group in the internal and external middle tiers. For eg: if there are 3 JVMs in the internal and 2 JVMs configured for the external middle tier, take the number as 3. � Identify the number of java processes spawned by the concurrent manager tier. For eg: if there are 3 JVMs spawned by the ICM, take the number as 3 . Add this to the number of oacore JVMs . In the example given above, the total number JVMs thus become 6 . So, six ports need to be opened in the firewall. You can use the 'pstree' command to check the number of java processes spawned by the concurrent manager parent process. For eg: pstree -p 26258 where 26258 is the process ID of the FNDSM process.

� Identify the ports to open in the firewall that separates the external middle tier and the internal middle tier . For eg: if the JVM count is 3, you have to open 3 ports on this firewall. � This range of ports need to be specified as a value for the autoconfig variable ( s_fnd_cache_port_range ) . Please make sure that the value is same in all the applications context files . The value should be specified as a range. For eg: 36500-36505. When AutoConfig completes the configuration, the value specified for this variable in the context file will get updated in the FND_CACHE_PORT_RANGE profile option.

� In addition to the ports specified above, you must ensure that the Java Object Cache Port specified as a value for the autoconfig variable s_java_object_cache_port is also open on the firewall that separate the external and internal middle tiers.

You must run Autoconfig to complete the configuration after editing the applications context file.

5.9: Configuration Details for Using reverse proxy with No External Web Tier

This configuration requires your internal application middle tier server to have at least two network interfaces. One network interface is required for the external entry point and another for the internal entry point. These network interfaces must be configured to resolve to two different hostnames in the DNS. For example: /etc/hosts of Internal Server 1 130.30.21.1 internal1.company.com internal1 130.30.21.2 external1.company.com external1

5.9.1: Create a new context file for the external Web Entry Point

1. To create a context file for the external entry point, execute the commands shown in the table below:

Attention In a multinode installation, the AutoConfig variable s_java_object_cache_port must be set identically on all nodes. Similarly, s_fnd_cache_port_range must be set identically on all nodes. Please note that s_java_object_cache_port must be set to a different value from s_fnd_cache_port_range in the same applications context file to avoid port conflicts.

$ perl $COMMON_TOP/clone/bin/adclonectx.pl \ contextfile=$CONTEXT_FILE \ outfile= <name of the output file including location> For example:

Internal Server Name 1: internal1.company.com

External Server Name 1: external1.company.com

Context file for Internal Entry Point on Internal Server 1 including its location: /d1/applmgr/visappl/admin/VIS_internal1.xml

Context file to be created for External Entry Point on Internal Server 1 including its location: /d1/applmgr/visappl/admin/VIS_external1.xml

The script will prompt for various inputs from the user as shown in the table below. please note that the default prompt values are provided for reference purpose only and may not reflect the actual values in your

of 42


5.9.2: Verify and Update the New Context Files Created for the External Entry Point

environment.

After you provide all the required inputs, the clonectx utility will proceed and create the new context file for the external entry point at the location specified in the command

Prompt Required Value Comments

Enter the Apps password

Target System Hostname (virtual or normal) [internal1]:

external1Enter the physical hostname. Not the virtual hostname

Do you want the inputs to be validated (y/n) [n] ?:

Y

Target system database SID [VIS] VIS Enter the target database SID

Target System Database Server Node [db-node]

db-nodeEnter the hostname where the new database instance is running

Target System Base directory /d1/home/user9/R12/apps Enter the base directory of APPS install

Target System Instance Home Directory [/d1/home/user9/R12/inst]:

/d1/home/user9/R12/inst

Username for the applications file system owner [applmgr]

applmgr

Group for the applications file system owner [dba]:

dba

Target System Root Service [enabled] : enabledMust be enabled if configuring 'Web Entry Point Services' or 'Web Application Services'.

Target System Web Entry Point Services [enabled] :

enabled Must be enabled if configuring 'Web Entry Point Services'

Target System Web Application Services [enabled]:

enabled Must be enabled if configuring 'Web Entry Point Services'.

Target System Batch Processing Services [enabled] :

enabledMust be enabled if configuring 'Batch Processing Services'.

Target System Other Services [disabled] :

enabled Must be enabled if configuring 'Other Service Group'.

Do you want to preserve the Display set to internal:0.0 (y/n) [y] ?:

Y

Do you want to preserve the port values from the source system on the target system (y/n) [y] ?

Y

It is possible that adclone utiity will report an error and prompt you to choose an alternative port pool if the services for the internal instance is running. To prevent this from happening, shutdown the application tier services when you run this utility.

AutoConfig Variable

Required Value Comments

s_isWeb YESMake sure s_isWeb is set to YES. This is the default setting for all node types

s_isWebDev YESMake sure s_isWebDev is set to YES. This is the default setting for all node types

s_http_listen_parameterNew Port for the http listener

Pick a port that is not used by any other service

of 42



1. Run AutoConfig on each Applications middle tier to complete the configuration. Please refer to the Oracle MetaLink Note 387859.1 "Using AutoConfig to Manage System Configurations with Oracle Applications R12 " for more information on AutoConfig.


5.10: Configuration Details for Using Hardware Load Balancer with No External Web Tier

5.10.1: Create new Context Files for the External Entry Point

s_https_listen_parameterNew Port for the https listener


s_webentryurlprotocolSet the value to the web entry protocol

For example, value will be either http or https

s_webentryhostSet the value to the webentry host

s_webentrydomainSet the value to the webentry domain

s_active_webportSet the value to the active port

s_login_pageSet the value to point to the new webentry configuration

s_server_ip_address

Set the value of this variable to the IP address of the external facing network interface

Attention

This configuration requires your internal application middle tier server to have at least two network interfaces. One network interface is required for the external entry point and another for the internal entry point. These network interfaces must be configured to resolve to two different hostnames in the DNS. For example: /etc/hosts of Internal Server 1

130.30.21.1 internal1.company.com internal1 130.30.21.2 external1.company.com external1

/etc/hosts of Internal Server 2

130.30.21.3 internal2.company.com internal2 130.30.21.4 external2.company.com external2

of 42


1. To create a context file for the external entry point, execute the commands shown in the table below:

$ perl $COMMON_TOP/clone/bin/adclonectx.pl \ contextfile=<context file name> \ outfile=<name of output file> For example:






Context file to be created for External Entry Point on Internal Server 1 including its location: /d1/applmgr/visappl/admin/VIS_external1.xml


Context file to be created for External Entry Point on Internal Server 2 including its location:

/d1/applmgr/visappl/admin/VIS_external2.xml

Database ID: VIS

For the above given example, you will enter the command as

$ perl $COMMON_TOP/clone/bin/adclonectx.pl \ contextfile= /d1/visappl/admin/VIS_internal1.xml \ outfile=/d1/visappl/admin/VIS_external1.xml

$ perl $COMMON_TOP/clone/bin/adclonectx.pl \ contextfile= /d1/visappl/admin/VIS_internal1.xml \ outfile=/d1/visappl/admin/VIS_external2.xml

The script will prompt for various inputs from the user as shown in the table below. please note that the default prompt values are provided for reference purpose only and may not reflect the actual values in your environment.

Prompt Required Value Comments

Enter the Apps password

Target System Hostname (virtual or normal) [internal1]:

external1Enter the current hostname.Most of the time it will be the same as default value.

Do you want the inputs to be validated (y/n) [n] ?:

Y

Target system database SID [VIS] VIS Enter the target database SID

Target System Database Server Node [db-node]

db-nodeEnter the hostname where the new database instance is running

Target System Base directory /d1/home/user9/R12/apps Enter the base directory of APPS install

of 42


5.10.2: Verify and Update the New Context Files Created for the External Entry Points

Table given below gives a list of AutoConfig variables that need to be reviewed and edited if required.

After you provide all the required inputs, the clonectx utility will proceed and create the new context file for the external entry point at the location specified in the command

Target System Instance Home Directory [/d1/home/user9/R12/inst]:

/d1/home/user9/R12/inst

Username for the applications file system owner [applmgr]

applmgr

Group for the applications file system owner [dba]:

dba

Target System Root Service [enabled] :

enabledMust be enabled if configuring 'Web Entry Point Services' or 'Web Application Services'.

Target System Web Entry Point Services [enabled] :

enabled Must be enabled if configuring 'Web Entry Point Services'

Target System Web Application Services [enabled]:

enabled Must be enabled if configuring 'Web Entry Point Services'.

Target System Batch Processing Services [enabled] :

enabledMust be enabled if configuring 'Batch Processing Services'.

Target System Other Services [disabled] :

enabled Must be enabled if configuring 'Other Service Group'.

Do you want to preserve the Display set to internal:0.0 (y/n) [y] ?:

Y

Do you want to preserve the port values from the source system on the target system (y/n) [y] ?

Y

It is possible that adclone utiity will report an error and prompt you to choose an alternative port pool if the services for the internal instance is running. To prevent this from happening, shutdown the application tier services when you run this utility.

AutoConfig Variable

Required Value Comments

s_isWeb YESMake sure s_isWeb is set to YES. This is the default setting for all node types

s_isWebDev YESMake sure s_isWebDev is set to YES. This is the default setting for all node types

s_http_listen_parameterNew Port for the http listener


s_https_listen_parameterNew Port for the https listener


s_webentryurlprotocolSet the value to the webentry protocol

For example, value will be either http or https

s_webentryhostSet the value to the webentry host

s_webentrydomainSet the value to the webentry host domain

of 42



1. Run AutoConfig on each Applications middle tier to complete the configuration. Please refer to the Oracle MetaLink Note 387859.1 "Using AutoConfig to Manage System Configurations with Oracle Applications R12 " for more information on AutoConfig.


Appendices

A. List of External Facing Oracle E-Business Suite Release 12 Products B. Oracle E-Business Suite Release 12 Product Specific Configurations C. Configuration Option for Functionally Directed Load Distribution D. Reverse Proxy Configuration E. Configuring the URL Firewall F. List of Ports to Open in a DMZ Configuration G. Configuring Multiple Web Entry Points and DMZs with Single Sign-On H. Troubleshooting I. Disabling E-Business Suite Release 12 Application Services on the External Web Tier J. Disabling "About this page" Link From the Release 12 Login Page K. Related Documentation

Appendix A : List of External Facing Oracle E-Business Suite Release 12 Products

Below is a list of Oracle certified E-Business Suite Release 12 products that can be deployed for external use. If you are planning on deploying a product that is not listed in the table below, log a Service Request with Oracle Support requesting certification of that product for external deployment. The "URL Firewall Rules" column indicate whether there are any special rules that need to be enabled in the URL FW for the product to function. An "Yes" in the column indicates there are special rules.

s_active_webportSet the value to the active port

s_login_pageSet the value to point to the new webentry configuration

s_server_ip_address

Set the value of this variable to the IP address of the external facing interface

Product Name Product ID Product Code Product Family URL Firewall Rules Patch Requirement

iSupplier Portal 208 POS Procurement Yes

Oracle Sourcing 1273 PON Procurement Yes

Oracle Receivables 1106 OIR Financials Yes

iRecruitment 1193 IRC Human Resources Yes

Oracle Time and Labor 310 OTL Human Resources Yes

Oracle Learning Management 810 OTA Human Resources Yes

Self Service Benefits 290 BEN Human Resources No

Self Service Human Resources 1566 SSHR Human Resources No FP.KRup2

of 42


Appendix B : Oracle E-Business Suite Release 12 Product Specific Configurations

B1: Oracle E-Business Suite Release 12 Product Specific Configurations

B1.1: Additional Configurations for iStore

B1.1.1: Time-To-Live Settings for Cached Objects B1.1.2: Deploying iStore Pages in Http & Https Configuration

B1.2: AltBatchValidateURL Setting for iStore Integration with Oracle Configurator

B2: Forward Proxy Configuration

B1: Oracle E-Business Suite R12 Product Specific Configurations

If any of the following products are installed and configured, you must refer to the respective documents as shown in the table below for more information on which responsibilities can be made externally accessible from the Internet.

Please refer to section 5.3: Update List of Responsibilities for the necessary steps to make the responsibilities listed below available on the external web server.

To perform any product-specific profile settings, you must refer to the respective product documents shown below.

Oracle iSupport 381 IBU CRM Yes

Oracle iStore 384 IBE CRM Yes

Oracle Marketing 229 AMS CRM Yes

Oracle Partner Relationship Management 1065 PRM CRM Yes

Oracle Survey 1578 IES CRM Yes

Oracle Transportation 1060 FTE Manufacturing Yes

Oracle Contracts Core 154 OKC Manufacturing N/A

Oracle Service Contracts 432 OKS Manufacturing N/A

Oracle Collaborative Planning 1037 SCE Manufacturing Yes

Oracle User Management 1475 UMX Application Object Library No

Order Information Portal 660 ONT Order Management No

Oracle Sales for Handhelds 1558 ASP CRM Yes

Oracle Internet Expenses 397 OIE Financials No

Oracle Performance Management 2010 OPM Human Resources No

Compensation Workbench 4427 CWB Human Resources No

Oracle Payroll 506 PAY Human Resources No

Oracle Quoting 1296 QOT CRM No

Oracle Field Service Third Party Portal 747 FSE CRM No

Product Name Externally Accessible Responsibilities Addtional Profile Settings Additional Documents

of 42


iSupplier Portal � iSupplier Portal Full Access � POS Supplier Guest User � Plan to Pay Supplier View � Plan, Source, Pay Supplier View � Source to Pay Supplier View � Supplier Profile Manager � Procure to Pay Supplier View

� POS: External URL � POS: Internal URL

� Oracle iSupplier Portal Documentation Resources R12 Note:396880.1

� Enable Web Access By External Supplier Users to Oracle iSupplier Portal Documentation Resources R12 and Oracle Sourcing Documentation Resources R12 Note:396879.1

Oracle Sourcing � Sourcing Supplier � PON: External Applications Framework Agent

� PON: External login URL

� Oracle Sourcing Documentation Resources R12 � Enable Web Access By External Supplier Users to Oracle iSupplier Portal Documentation Resources R12 and Oracle Sourcing Documentation Resources R12 (Note

iSupport � iSupport Business User � iSupport Guest User � iSupport Individual User � iSupport Primary User � iSupport Site: Business User � iSupport Site: Individual User � iSupport Site: Guest User � iSupport Site: Primary User

� Oracle iSupport Implementation and Administration Guide

iStore � IBE_CUSTOMER � IBE: iStore Secure URL � IBE: iStore Non Secure URL

� Oracle iStore Implementation and Administration Guide

� Refer to Appendix B1.1 for additional required configuration steps for iStore.

iRecruitment � iRecruitment External Site Visitor � iRecruitment External Candidate � iRecruitment Employee Site Visitor � iRecruitment Employee Candidate � iRecruitment Agency

� Oracle iRecruitment Implementation and User Guide

Oracle Learning Management � Learner Self-Service � Oracle Learning Management Implementation Guide

Oracle iReceivables � iReceivables Account Managament � iReceivables 2.0 Anonymous Internal

� Oracle iReceivables Implementation Guide

Oracle Transportation Execution � Transportation Execution Carrier User � Oracle Transportation Execution User Guide in the Virtual Applications Documentation Library

Oracle Partner Relationship Management

� Partner Super User � Default Partner User

� PV: Locator Server URL � PV: System Login URL � PV: iStore Login URL � PV:Self Service URL with Workflow Notification

� Oracle Partner Management Implementation and Administration Guide

Oracle Marketing � AMS : Server URL � Oracle Marketing Implementation Guide

Oracle Contracts Core � OKC: Contracts Online - External Party Access

Oracle Service Contracts � Service Contracts Electronic Renewals � Service Contracts Online Acceptance

Oracle Collaborative Planning � Supply Chain Collaboration Planner � Supply Chain Collaboration Manager

� Oracle Collaborative Planning Implementation and User's Guide

Order Information Portal � Order Information External User � OM: Records on Summary Page for External Users

� OM: Customer Service Feedback � OM: Customer Service Report Defect

� Oracle Order Management Implementation Manual in in the Virtual Applications Documentation Library.

Refer to section 8.6 Order Information

of 42


B1.1: Additional Configurations for iStore

B1.1.1: Time-To-Live Setting for Cached Objects

iStore uses Java caching framework to cache frequently used objects in the JVM. Each JVM will have a copy of an object in the Java Cache. When an object is updated by one JVM, it is invalidated in all JVMs across all Applications middle tier servers.

At the present time, cache updates in the Applications internal middle-tier server will not get reflected in the Applications external web server. There are a couple of options to work around this known issue:

1. Shutdown and restart the Oracle HTTP server on the Applications external web server when an object in a cache is updated on the Applications internal middle-tier server. When JVMs are restarted, objects will be freshly fetched into the cache.

2. Set Time-To-Live values for certain cache components so that these cache objects are invalidated on a periodic basis. Cache objects get refreshed when they are accessed for the first time after an invalidation. Since Time-To-Live values themselves are cached, the Oracle HTTP server on the Applications external middle-tier server needs to be bounced once for the new values to take effect.

The exact Time-To-Live values will depend upon business requirements, how often objects in a cache component are updated and what the tolerance level is for having stale objects in the cache. Information on setting up Time-To-Live interval is available at:

OracleÂ® Applications CRM System Administratorâ22s Guide in the Virtual Applications Documentation Library Sections Managing Component Caches and Editing Component Cache Details.

iStore uses Java Cache extensively to cache product catalog objects. Information on iStore Cache Components is available at:

OracleÂ® iStore Implementation and Administration Guide in the Virtual Applications Documentation Library Section Component Caches for Oracle iStore in JTT.

B1.1.2: Deploying iStore Pages in Http & Https Configuration

For better performance, it is recommended to deploy iStore public pages under HTTP and employ HTTPS only for those pages and processes that transmit sensitive data. In DMZ deployment, this requires the reverse proxy server to listen on two ports, one for HTTP and the other for HTTPS. Both the HTTP and HTTPS reverse proxy listeners should be configured to forward the requests to the external web server. In this configuration, values for profiles "IBE: iStore Non Secure URL" and "IBE: iStore Secure URL" should point to HTTP and HTTPS reverse proxy server URL respectively.

If iStore public pages are also deployed via HTTPS, values of both the profiles "IBE: iStore Non Secure URL" and "IBE: iStore Secure URL" should point to the HTTPS reverse proxy server and port and can not be left empty. Refer to section "Setting up Secure Socket Layer Connections" of OracleÂ® iStore Implementation and Administration Guide in the Virtual Applications Documentation Library for more details.

B1.1.3: AltBatchValidateURL Setting for iStore Integration with Oracle Configurator

In a DMZ configuration, it is likely that the database installed in the intranet can not communicate with the external application middle tier due to fact that the external web server port is not opened on the firewalls that separate the intranet servers from dmz servers. In such situations, the AltBatchValidateURL should be set to the URL for the configurator servlet on the internal application middle tier server.

Self Service Human Resource � Employee Self-Service � Manager Self-Service

Oracle Internet Expenses � Internet Expenses � Expenses Analysis and Reporting

Oracle Payroll � Online Payslip (For localizations) � W2 and W4 for US Legislation

Oracle Quoting � Quoting User

Oracle Field Service Third Party Portal

� Field Service Technical Portal � Field Service Third Party Administrator Portal

� Field Service Third Party Technician Portal

Oracle Sales for Handhelds � Wireless Sales User

of 42


B1.1.4: iStore Restrictions on Multiple Domains

iStore profile options IBE_SECURE_URL and IBE_NON_SECURE_URL are set at the site level for an E-Business Suite environment.

Due to this restriction, deploying iStore in a DMZ configuration where the internal and external domains differ will result in intermittent losses of end-user session information and user redirects to the incorrect minisites. This known issue is expected to be resolved in future iStore releases.

B2: Forward Proxy Configuration

The DMZ Forward Proxy should be configured whether or not a DMZ Reverse Proxy is used, and must be configured to handle outbound DMZ-to-Internet and outbound DMZ-to-Intranet HTTP traffic.Oracle E-Business Suite Application Tier configured in the DMZ must have access to a forward proxy server. This is required by the external modules configured in the DMZ for connecting to external/internal sites to perform certain tasks like resume parsing for iRecruitment. Other modules that are known to use the forward proxy are Oracle Transportation Management and Oracle partner relationship management.

Set the proxy variables in the applications context file as shown in the table below and run autoconfig:

All application tier nodes both in the DMZ and intranet must use the same proxy server

Firewall Impact: 1.If the DMZ Forward Proxy is separated from the DMZ by a DMZ outbound firewall, then customer needs to change the DMZ outbound firewall configuration to allow for outbound DMZ-to-"DMZ Forward Proxy" HTTP communication.

2. If the DMZ Forward Proxy is within the DMZ, then the customer needs to change the DMZ outbound firewall configuration to allow for outbound "DMZ Forward Proxy"-to-Internet and outbound "DMZ Forward Proxy"-to-Intranet HTTP communication.

Appendix C: Configuration Option for Functionally Directed Load Distribution

This is not a certified configuration option; it is currently supported on a best effort basis. Oracle E-Business Suite customers can redirect load to specific machines based on user responsibilities.

1. Apply all the patches mentioned in Section 3: Required Patches. 2. Use SERVRESP profile hierarchy type for the profiles mentioned in section 5.1: Update Hierarchy type. 3. Assign values at the responsibility & server combination level for the profiles listed in section 5.1.

For example, setting the profiles listed in section 5.1 at the responsibility level for HR responsibilities will result in all HR users going to one specific entry point. The entry point represents one specific machine or a load balanced group of machines (that is the loadbalancer entry point).

Appendix D: Reverse Proxy Configuration

A reverse proxy server is an intermediate server that sits between a client and the actual web server and makes requests to the web server on behalf of the client. The client is unaware of the presence of the reverse proxy.

Benefits of using a reverse proxy server are:

� Adds a level of isolation between the client and the actual server � Allows using standard web port numbers (80 and 443) on the external interface while running the actual web server on higher numbered ports thus avoiding having to start the actual web application server processes as root. � Allows certain rules (or filters) to limit the http requests that are presented to the actual web server � Optionally allows for caching of contents

A number of options exist for choosing a reverse proxy:

Context Variables Name Default Value Description

s_proxyhost null Forward Proxy Host

s_proxyport null Forward Proxy Port

s_proxybypassdomain s_domainname Forward Proxy Bypass Domain

of 42


1. Use Oracle 10g Application Server standalone version 2. Use Oracle Application Server Webcache 3. Use apache httpd from http://httpd.apache.org 4. Use any of a number of commercially available reverse proxies, which often provide some level of added security as well.

There are pros and cons for each of these solutions, and the customer must choose according to preferences, supportability, existing IT standards and local policies. The table below present some advantages and disadvantages for each of the options mentioned above

If you choose to use Oracle WebCache as your reverse proxy server, please refer to the Oracle MetaLink Note 380486.1 : Installing and Configuring Web Cache 10g and Oracle E-Business Suite 12 .

In the remainder of this appendix we will describe the steps required to setup a reverse proxy based on apache2 from httpd.apache.org. Apache 2.0 is selected for the following reasons :

� can be built in a minimum configuration � supports HTTP/1.1 for better performance � Is well known, and the configuration steps described for the apache based reverse proxy will be useful when configuring any other reverse proxy

Building an Apache based Reverse Proxy from Source

Apache is available from httpd.apache.org. It is recommend that you download the source code and configure and build the executables locally. This will allow you to configure apache with only the modules required for reverse proxy duty. The following modules will be built and added to the apache server for additional security:

� mod_ssl will be added to provide encrypted https connections across the internet. Please note that this may require you to purchase a certificate from a well-known and trusted Certificate Authority (CA) such as Verisign or GoDaddy. � mod_security for its ability to discover and block requests that are obviously malformed, Null byte check, the url encoding check, the directory traversal prevention and the UTF-8 Unicode checks. � mod_rewrite as this is the engine used to implement the URL firewall.

If you are using an apache 1.3.x version, it is important to consider the load order (and thus the execution order) of the various modules in apache. The modules should be loaded in such an order as to ensure that the modules are executed in the following order:

1. mod_security - Reject obviously bad requests before anything else happens 2. mod_rewrite - Check for allowed URL before mod_proxy hands the request over to the external web tier

Software Advantages Disadvantages

Oracle 10g Application Server Standalone

� Supported by Oracle � Can directly use the URL Firewall as mod_rewrite module is configured with this server

� Certified with Oracle E-Business Suite in DMZ configuration

Oracle Application Server Web Cache

� Standalone version available � Supported by Oracle � Can support caching of E-Business Suite Content � Supports filtering of URLs

Does not understand the rewrite rules of the URL Firewall

Apache server from Apache Software Foundation

� Reputable provider of open source software � Available on many platforms � Can be configured and built to only include the required modules � Widely used Web server � Can directly use the URL Firewall as mod_rewrite module can be configured with this server

� Certified with Oracle E-Business Suite in DMZ configuration � Well Known, Well documented

You will have to download, compile, install and test the proxy

Commercially Available Reverse Proxy Servers

� Supported by the software vendor � May support URL filtering and content rewriting � May integrate with pre-selected enterprise single sign-on

� Not certified with Oracle E-Business Suite in DMZ configuration

� May not understand the rewrite rules of the URL Firewall

of 42


3. mod_proxy - Only proxy requests that seem valid (have passed the 2 above filtering steps) to the external web tier

Apache 2.0.x will require a source code change to ensure the proper execution order. This will be covered in the instructions below.

Build Apache2 for Secure Proxy Configuration

The instructions to build Apache 2.0 based reverse proxy is provided as a convenience and although following these instructions is expected to provide a working Apache 2.0 reverse proxy, these instructions and sample files are provided "as-is" and do not necessarily represent security best practice. You should therefore confirm suitability by your own verification and testing. Oracle do not support Apache nor do we make any specific claims to its suitability for your business requirements. If you have any questions or issues about configuring Apache 2.0 as a reverse proxy, please review the Apache documentation (http://httpd.apache.org/docs/) and or direct your query to the appropriate Apache.org forum (http://httpd.apache.org/docs/2.2/faq/)

The steps described below will compile and link the following modules with the Apache2 Server.

� mod_ proxy � mod_proxy_http � mod_ rewrite � mod_ssl � mod_setenvif � mod_security

Obtain the latest version of the apache (2.0.54) src code from http://httpd.apache.org/download.

� Check that the tar balls and the md5s file are present in the directory and verify the MD5 checksum.

� Unpack the TAR balls:

� Configure Apache - put this in a small script (runc.sh), that way you have a record of how it was configured

$ export http_proxy=http://www-proxy:80 # if you need a proxy to get out $ cd ; mkdir src ; cd src # go to the build source directory $ lynx http://httpd.apache.org/download # navigate to a mirror and save .tar.gz and .md5 $ wget http://www.modsecurity.org/download/modsecurity-1.8.7.tar.gz $ wget http://www.modsecurity.org/download/modsecurity-1.8.7.tar.gz.md5

.

$ ls -l total 7672 -rw-r--r-- 1 egravers egravers 59 Mar 5 07:47 modsecurity-1.8.7.tar.gz.md5 -rw-r--r-- 1 egravers egravers 313004 Mar 5 07:47 modsecurity-1.8.7.tar.gz -rw-r--r-- 1 egravers egravers 54 Jul 14 14:34 httpd-2.0.54.tar.gz.md5 -rw-r--r-- 1 egravers egravers 7508193 Jul 14 14:36 httpd-2.0.54.tar.gz

$ md5sum -c httpd-2.0.54.tar.gz.md5 # should not produce any output $ md5sum -c modsecurity-1.8.7.tar.gz.md5 # should not produce any output

$ tar xzvf httpd-2.0.54.tar.gz $ tar xzvf modsecurity-1.8.7.tar.gz

$ cd httpd-2.0.54

$ ./configure -prefix /dmz \ --enable-ssl \ --enable-setenvif \ --enable-proxy \ --enable-proxy_http \ --enable-headers \

of 42


Before compiling, a small change need to be done to the source of mod_proxy.c. This is to ensure that mod_proxy does not proxy a request to the external web tier before the URL firewall based on mod_rewrite has a chance to reject it. It also ensures that mod_proxy gets it's translate_name hook called after mod_rewrite's hook gets called.

All you have to do is change the second parameter in the ap_hook_translate_name from NULL to aszSucc and save the file.

As you can see, both modules want this hook to be called early (APR_HOOK_FIRST), however they do not specify any preference with respect to ordering with other modules. So we just register that mod_proxy want to be called after mod_rewrite.

� Check that the expected modules are included (and no others)

� As root install apache to /dmz

--enable-rewrite \ --enable-so \ --disable-charset-lite \ --disable-include \ --disable-env \ --disable-status \ --disable-autoindex \ --disable-asis \ --disable-cgi \ --disable-negotiation \ --disable-imap \ --disable-actions \ --disable-userdir \ --disable-alias

$ cd ~/src ; # go to the build source directory $ cd modules/proxy/

$ diff mod_proxy.c mod_proxy.c.dist 1085c1085 < ap_hook_translate_name(proxy_trans, NULL, NULL, APR_HOOK_FIRST); --- > ap_hook_translate_name(proxy_trans, aszSucc , NULL, APR_HOOK_FIRST);

$ cd ../.. # back to main build directory $ make

$ ./httpd -l Compiled in modules: core.c mod_access.c mod_auth.c mod_log_config.c mod_headers.c mod_setenvif.c mod_proxy.c proxy_http.c mod_ssl.c prefork.c http_core.c mod_mime.c mod_dir.c mod_rewrite.c mod_so.c

of 42


� As root - install mod_security

At this point apache 2.0 got installed in /dmz. Try to start the server using apachectl, however the installed httpd.conf file has some directives for modules that were not included. You can remove these errors - one by one by attempting start and fixing the problem reported until apache actually starts. The following directives had to be removed after completing the above steps:

� UserDir � Alias � AliasMatch � RedirectMatch � ScriptAlias � IndexOptions FancyIndexing VersionSort � AddIconByEncoding � AddIconByType � AddIcon � DefaultIcon � ReadmeName � HeaderName � IndexIgnore � LanguagePriority � ForceLanguagePriority

Once you have sanitized the default httpd.conf file you can proceed and test

� Start apache without SSL

� Verify that server is running and is listening on port 80 (http)

Success!! We have httpd listening on port 80.You can verify that the server is working by using a browser to go to http://site/index.html.en . Note that you will have to specify the full name of the index.html.NN file, including language as we did not include mod_negotiation or mod_dir in this build of the apache server.

� Stop the apache http server

� Setting up the SSL certificate

Follow the instructions given below to generate a self signed certificate for test purposes. The encryption is as good as a purchased certificate, however web browsers will warn their users about a unrecognized (un-trusted) Certificate

$ su # umask 022 # make install # chown -R root:sys /dmz

# cd ../modsecurity-1.8.7/apache2/ # /dmz/bin/apxs -cia mod_security.c

# /dmz/bin/apachectl start

# netstat -lntp | sort -t: +1n Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3993/sshd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 24772/httpd

# /dmz/bin/apachectl stop

of 42


Authority. For your real deployment you will need to purchase a SSL certificate from a Certificate Authority.

� Generating and installing a test certificate:

� Start apache with SSL

� Verify that server is running and is listening on both port 80 (http) and 443 (https):

Success!! We have httpd listening on port 80 and 443.

You can verify that the server is working by using a browser to go to http://site/index.html.en and https://site/index.html.en.

As before, you will have to specify the full name of the index.html.NN file (including language) as the modules "mod_negotiation" or "mod_dir" was not compiled and configured in this build of the apache server. Note also that your browser will complain when accessing the https URL as it does not recognize the Certificate Authority that signed the SSL certificate.

At this point, all the required infrastructure pieces are working, it is time to configure the apache for proxy duty.

Following configuration files are needed in /dmz/conf:

� httpd.conf -- apache configuration file � security.conf -- make mod_security stop obviously bad requests � url_fw.conf -- allow only required URLs through (see appendix E. Configuring the URL Firewall)

This is covered in the Install and Configure section below.

Install and configure

When the executables have been built and installed it is time to configure the runtime settings in the configuration files, this includes

� Configuring Apache httpd (on port 80) � Configuring mod_ssl and certificate (on port 443) � Configure mod_proxy (pass entire URL space to external webtier)

# cd /dmz/conf # umask 022 # mkdir ssl.key # mkdir ssl.crt # mkdir ssl.crl # openssl req \ -new \ -x509 \ -days 30 \ -keyout ssl.key/server.key \ -out ssl.crt/server.crt \ -subj '/CN=Test-Only Certificate' # chmod 600 ssl.key/server.key # private key; root and only root should have access

/dmz/bin/apachectl startssl

# netstat -lntp | sort -t: +1n Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3993/sshd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 24772/httpd tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 24772/httpd

of 42


� Configuring mod_security � Configuring the URL Firewall

Below is a diagram of the deployment. Presumably you will have a firewall in front of the reverse proxy and another between the reverse proxy and the external web tier.

Oracle recommends that all E-Business Suite traffic over the internet be encrypted, i.e. using HTTPS on the standard port 443/tcp. Users may expect to just type the hostname of your external site into the address field of their browsers, which will cause the browser to prepend http:// and assume the default HTTP port 80/tcp. To accomodate such users, the reverse proxy should allow this initial connect to the standard HTTP port 80/tcp and immediately redirect the browser to the standard HTTPS port.

This can be achieved by using the following rewrite rule for the port 80 virtual host:

The Oracle iStore product is using both HTTP and HTTPS for performance reasons, and the iStore application will switch between the two protocols as required.

This means that for deployments including iStore the http/80/tcp virtual host should not contain the 'redirect-all-to-https' rule. In this case, a careful selection of initial page and http and https links from it should be created. We also want to ensure that a user cannot call any of the URLs that are supposed to be run over HTTPS via HTTP. (A user could deliberately change the URL in his browser to be http:// rather than https://). We ensure that by only allowing the subset of iStores URL that are considered non sensitive to be accepted in the http virtual host.

You can download the fully functioning configuration files, httpd.conf and security.conf.

The assumptions made while creating these config files are:

� the reverse proxy will be accessed via the hostname www.example.com � the E-Business Suite external webtier is called extweb.example.com � the server admin is [email protected] � the apache proxy was configured and installed to /dmz

You will have to modify the file to reflect your host and domain names and the location for /dmz. Once you have modified the above two configuration files and copied them to /dmz/conf/ it is time to test the proxy.

RewriteRule ^/(.*) https://www.example.com/$1 [R,L]

of 42


Once you have tested the reverse proxy with the above two configuration files, it is time to prepare for installation on the production hardware in the DMZ.

Copy the /dmz.tgz file from the test box to root's home directory on the DMZ host and install it.

Edit the configuration files to reflect host names and port numbers for the production DMZ, and install the real, CA signed SSL certificate.

Then start the reverse proxy

The next step is to configure the URL Firewall on the reverse proxy for the Oracle E-Business Suite products you wish to expose to the external parties. Once done, make sure that you include in the reverse proxy configuration file the customized url_fw.conf configuration file from httpd.conf and bounce the reverse proxy.

Below is a list of references related to building a secure apache proxy, you want to check these out for additional explanation on many of the configuration decisions made above - or for better ideas on how to build your very own.

� http://www.securityfocus.com/infocus/1818 -- Apache 2 with SSL/TLS Step-by-Step, Part 1 � http://www.securityfocus.com/infocus/1820 -- Apache 2 with SSL/TLS Step-by-Step, Part 2 � http://www.securityfocus.com/infocus/1823 -- Apache 2 with SSL/TLS Step-by-Step, Part 3 � http://www.apacheweek.com/features/reverseproxies -- Running a Reverse Proxy with Apache (2) � http://www.securityfocus.com/infocus/1739 -- Web Security Appliance With Apache and mod_security � http://httpd.apache.org/docs-2.0/install.html -- From the source � http://httpd.apache.org/docs-2.0/mod/mod_proxy.html -- From the mod_proxy doc � http://www.modsecurity.org/ -- all you ever wanted to know about mod_security

Although the following topics are beyond the scope of this document, system administrators are advised to consider these factors prior to deploying a reverse proxy into a environment:

� O/S Hardening � Load balancing for Redundancy (avoiding single points of failures) � Fail-over strategies � Log rotation and analysis

Appendix E: Configuring the URL Firewall

# /dmz/bin/apachectl start #note that you do not need startssl # netstat -lntp | sort -t: +1n Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3993/sshd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 2472/httpd tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 2472/httpd

# /dmz/bin/apachectl stop # rm -f /dmz/logs/* # delete old log files # rm -rf /dmz/manual* # delete the Apache documentation # tar cvzf /dmz.tgz /dmz # tar up the runtime proxy

dmz# cd / dmz# tar xvzf ~/dmz.tgz # unpack the runtime proxy

dmz# /dmz/bin/apachectl start dmz# netstat -lntp | sort -t: +1n Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 993/sshd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 2234/httpd tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 2234/httpd

of 42


The purpose of the URL Firewall is to ensure that only URLs required for the externally exposed functionality can be accessed from the internet.

The URL firewall is implemented as a whitelist list of URLs required; any URL request that is not matched in the whitelist list is refused. This will limit the exposure of your Oracle E-Business Suite deployment by reducing the attack surface available to external parties.

The URL Firewall can be deployed on the external webtier or in the reverse proxy. If you are deploying a reverse proxy that can process mod_rewrite rules, we recommend that the URL Firewall be deployed on the reverse proxy in order to reject un-authorized requests as early as possible.

The URL Firewall is shipped as an apache configuration file containing rewrite rules interpreted by mod_rewrite. The URL Firewall configuration file (url_fw.conf) will be generated on all the web tiers by the AutoConfig utility. To Include this configuration file in Oracle HTTP Server configuration file (httpd.conf), perform the following steps:

� Change value of the autoconfig variable s_enable_urlfirewall. By default the value of this variable is set to '#' which indicates that the URL firewall is disabled. To enable the URL firewall, the pound sign '#' must be removed .

You must ensure that for nodes that are marked as external, this configuration file should be included in the http server configuration.

The file consists of blocks of URLs that may be required depending on the deployed product mix and ends with a rule that rejects the request if it has not been matched by one of the enabled rules. You will have to manually edit this file to enable the URLs in the block that corresponds to the product(s) you are deploying for external access.

The url_fw.conf file has the following blocks

� INITIAL PAGE - defines the default start page � STATIC - static files such as images, stylesheets, javascript and html � COMMON - common components used by multiple products � LOCAL - required for local login � FORMS - if your product mix requires the use of Oracle Forms � XXX - where XXX is a product abbreviation

You will always need the STATIC, COMMON and LOCAL blocks. Depending on the product(s) you are deploying, you may need additional blocks of URLs enabled. This is summarized in the table below.

Product Name Product Code Product Family Blocks Required

iSupplier Portal POS Procurement POS

Oracle Sourcing PON Procurement PON

Oracle iReceivables OIR Financials OIR

iRecruitment IRC Human Resources IRC

Oracle Time & Labor OTL Human Resources OTL

Oracle Learning Management OTA Human Resources OTA

Oracle iSupport IBU CRM IBU

Oracle iStore IBE CRM IBE + CZ* optional

Oracle Marketing AMS CRM AMS

Oracle Partner Relationship Management PRM CRM PRM

Oracle Survey IES CRM IES

Field Sales ASP CRM ASP

Oracle Transportation FTE Manufacturing FTE

Oracle Contracts Core OKC Manufacturing none

Oracle Service Contracts OKS Manufacturing OKS

Personal Portfolio IGP IGP

of 42


*) iStore needs the CZ block if it is integrated with the Configurator.

In addition to uncommenting the blocks of URLs specified above you will have to consider and decide how to handle the following for your deployment:

� Initial page - what page should be displayed when external users go to / � Help - what should happen when external users click on the Help icon

The syntax of the ErrorDocument directive in url_fw.conf need modification (to use double quotes), if you have configured apache2 as the reverse proxy server. The default file shipped uses Apache 1.3.x syntax.

Configure Initial Page

In the shipping version of url_fw.conf external users will be presented with the standard Apps Login page when they go to / (actually http://your.site.com ) on your external site.

If you are deploying products that allow users to surf part of the site prior to authentication, presenting them with a login page may not make any sense. For example if you are deploying iStore, users have an expectation to be able to browse the goods without logging in. If you are deploying iRecruitment, maybe external users can browse available job postings prior to identifying themselves.

If you are integrating the external access to E-Business Suite via an existing company website, you may want to include a new page with your corporate branding and links to the appropriate entry points of Oracle Applications.

To change the initial (/) page, locate the INITIAL PAGE block and change the first line in that block to provide the page of your choice.

the rule says: upon a request for /, redirect ([R]edirect) to /OA_HTML/AppsLogin and stop further rewriting ([L]ast).

If your deployment is only iRecruitment or only iStore the above rule could be replaced with one of the following

For help in selecting an appropriate initial page, see the Implementation Guide for the products you are deploying externally.

URL Firewall Configuration for Webservices Deployed in the DMZ

A Webservices URL Firewall configuration file url_fw_ws.conf must be generated in the application tier nodes that host the external modules to prevent unauthorized access to SOAprovider servlet. This configuration file can be generated by performing the following steps:

Successful completion of the the script given above will generate url_fw_ws.conf at $INST_TOP/ora/10.1.3/Apache/Apache/conf . This configuration file will then be automatically included when autoconfig is executed on the external nodes.

Appendix F: List of Ports to Open in a DMZ Configuration

The diagram shown below represents the list of ports that need to be opened on the firewalls in a DMZ configuration.

Oracle Collaborative Planning SCE Manufacturing SCE+Forms

RewriteRule ^/$ /OA_HTML/AppsLogin [R,L]

RewriteRule ^/$ /OA_HTML/IrcVisitor.jsp [R,L] or RewriteRule ^/$ /OA_HTML/ibeCZzpHome.jsp [R,L]

$ txkrun.pl -script=GenWebServiceUrlFwConf

of 42


If users need access to additional components like Oracle Forms in server mode and Oracle Discoverer Plus, then additional ports may need to be opened on the External, Internal and the Data Firewall.

Some of the Oracle E-Business Suite modules like Oracle Configurator use UTL_HTTP package to communicate from the database to the application tier where the web server is installed. This is done over the HTTP(s) protocol. So, if there is a firewall configured between the application and database tier, http port must be opened on this firewall for this communication to succeed.

Appendix G: Configuring Multiple Web Entry Points and DMZs with Single Sign-On

You can deploy Oracle E-Business Suite environments with DMZs and multiple web-entry points. These configurations may optionally be integrated with Oracle Single Sign-On or Oracle Access Manager for centralized authentication. Either of these solutions also requires Oracle Internet Directory.

of 42


Perform the following steps to implement this configuration:

1. Follow the instructions in Note 376811.1 to install and configure Oracle Application Server 10g with E-Business Suite.

2. Configure your DMZs and multiple web-entry points for your E-Business Suite environments as described in Sections 2 to 5, above. Confirm that these environments are working properly before continuing.

3. The configuration displayed in Figure F8 uses a reverse proxy server as the web entry point for both the external application tier and the SSO server. must reconfigure both the SSO and the external application tier to point to the reverse proxy server. This configuration requires a virtual host be configured for both the SSO and External Application tier web entry point. This is required for the most secure deployment as no additional ports need to be opened on the external firewall.

4. To register your E-Business Suite environment with Single Sign-On 10g, run the registration utility described in Oracle MetaLink Note 376811.1, using the options appropriate for your deployment of Oracle Application Server 10g. The SSO / OID registration utility automates the Single Sign-On 10g partner application registration process for multiple web-entry point deployments. The registration utility automatically performs separate partner application registrations for each registered web-entry point, based on the E-Business database profile values for APPS_FRAMEWORK_AGENT. No special command-line parameters are required. The registration utility only needs to be run once, on any middle-tier server, regardless of whether the middle-tier server is located.

For example: You have two domains: partners.company.com and employees.company.com. The partners.company.com domain corresponds to the external middle-tier, and the employees.company.com domain corresponds to the internal middle-tier. To register your E-Business Suite environment with Single Sign-On 10g, run the registration utility once, on either the external or internal middle-tier server. The registration utility automatically detects and registers both middle-tiers. There is no need to run the registration utility on each middle-tier separately.

5. Run the AutoConfig utility as documented in the Oracle MetaLink Note 387859.1 "Using AutoConfig to Manage System Configurations with Oracle Applications R12 " and restart the Oracle Application Tier processes.

Figure F8, shown above, depicts a configuration in which the internal and external users are authenticated via a single Oracle Single Sign On server installed in the DMZ. The LDAP directory, Oracle Internet Directory, remains on the internal network. The "SSO server" can be OSSO 10g or Oracle Access Manager 11g (with mod_osso as the agent for Oracle E-Business Suite).

Please note that the figure F8 shown above lists only ports that are needed to be opened for that specific configuration. Additional ports may need to be opened if you have any other architecture variants. The configuration of external and internal web entry points using multiple OSSO servers is not supported at this time.

of 42


Figure G9, shown above, depicts a configuration in which the internal and external users are authenticated by Oracle Access Manager 10gR3 and Oracle E-Business Suite AccessGate. The entry point, WebGate, resides in the DMZ along with Oracle E-Business Suite AccessGate. The WebGate intercepts authentication requests and relays them to the Access Manager server. The Access Manager servers are installed on the internal network, along with Oracle Internet Directory. Oracle E-Business Suite AccessGate receives the authenticated session from Oracle Access Manager, and connects to the Oracle E-Business Suite database in order to link the Oracle Internet Directory (OID) user to an Oracle E-Business Suite user. Once this mapping is done, the originally requested resource is returned with a valid authenticated Oracle E-Business Suite user session. All subsequent requests for Oracle E-Business Suite resources are then returned directly to the user as long as the user session remains valid.

Perform the following steps to implement this configuration:

1. Follow the instructions in My Oracle Support Knowledge Document 975182.1, to install Oracle E-Business Suite AccessGate, and configure WebGate and Oracle Access Manager 10gR3. (See the next step, however, for an important change when configuring in a DMZ.)

2. When following the instructions to configure the Oracle E-Business Suite AccessGate in a DMZ, you will need to replace any references to the values of [WebGate host]:[WebGate port][WebGate host]:[WebGate port][WebGate host]:[WebGate port][WebGate host]:[WebGate port] in two places with the hostname and port on your reverse proxy that forwards to the WebGate:

� Step 4d, when setting the Redirection URL for failed authentication attempts; and � Step 6b, when setting the APPS_AUTH_AGENT profile option.

On the reverse proxy, you must then add a proxy rule to redirect URLs containing the context rule to the WebGate host and port accordingly.

of 42


3. If you are configuring separate WebGates for internal and external users, you may set the APPS_AUTH_AGENT profile option at the SERVER level, so that internal users are directed to one URL for authentication, and external users to another.

4. If you choose to implement the Lost Password or Reset Password on First Login features, you will need to install an additional WebPass in the DMZ, as well. The WebPass requires that you open port 6022 on the internal firewall to allow it to communicate with the internal Identity Server. (Note: this is not shown in the diagram above.) Once you have installed and configured a user-facing WebPass, make sure the APPS_AUTH_FORGOT_PASSWORD_LINK profile option in Step 6b is updated to point to either this new WebPass host, or a reverse proxy that sits in front of it.

5. Be sure to also review the setting for the Preferred HTTP Host parameter for your WebGate. For more information on configuring WebGate and Access Server with a reverse proxy, refer to the Oracle Access Manager Deployment Guide.

6. Configure your DMZs and multiple web-entry points for your E-Business Suite environments as described in Sections 2 to 5, above. Confirm that these environments are working properly before continuing.

Note that it is not necessary to open ports in the data firewall for LDAP and LDAP/S connections. LDAP connections are made only from the Oracle Access Manager's Access Server, which is located inside the firewall, and not from any of the components located in the DMZ. If you previously had these ports open for Oracle Single Sign-On Server and are no longer using OSSO for external authentication, you should close these ports on the data firewall for maximum security.

Appendix H: Troubleshooting

H1: Internal and External Middle Tiers in Different Domains H2: Firewalls Disconnects SQL*Net Connections H3: DNS Resolution of Machines and Devices Involved in the DMZ Configuration H4: HTTP Error 400 - Bad request H5: HTTP Error 410 - Gone H6: Redirection to an incorrect server during login

H1: Internal and External Middle Tiers in Different Domains

If any of your middle tier servers or the reverse proxy server is running on machines with different domain names or different virtual host domain names, you must execute the following SQL command when logged into the database as the APPS user:

H2: Firewalls Disconnects SQL*Net Connections

Most firewalls disconnect SQL*Net connections after 30 minutes of inactivity. To fix this problem, add the following parameter to the existing [RDBMS_ORACLE_HOME]/network/admin/_/sqlnet.ora on the database tier:

SQLNET.EXPIRE_TIME=10

H3: DNS Resolution of Machines and Devices Involved in the DMZ Configuration

In a DMZ setup, there are a number of components involved in the configuration. For example network components such as firewall devices, hardware load balancers, ssl accelerators and machines hosting the application software. A successful configuration of these components require proper name resolution at machine and at DNS levels from various segments of your network. Given below are some of the commonly used operating system utilties that can be used to verify the DNS setup.

� nslookup � ping � traceroute � nmap

H4: HTTP Error 400 - Bad request

If you receive an "HTTP Error 400 - Bad request" on your browser, it means that the Oracle HTTP Server or the Reverse Proxy Server denied the request due to a rule set in mod security. Review the error_log file to gather more information on why the request was denied.

SQL> update icx_parameters set session_cookie_domain = null; SQL> commit;

of 42


H5: HTTP Error 410 - Gone

If you receive an " HTTP Error 410 - Gone" on your browser, it means that the Oracle HTTP Server or the Reverse Proxy Server denied the request due to a rule set in the URL Firewall. Review the access_log or rewrite_log to gather more information on why the request denied.

If you identify a URL that is being blocked that you think should be allowed for your deployment, simply add the URL to the url_fw.conf file. Bounce the (Oracle HTTP Server or the Reverse Proxy Server) to make the change active.

H6: Redirection to an Incorrect Server During Login

If you are getting redirected to an incorrect server during the login process, check the following:

� Whether the hirearchy type of the profile options mentioned in Section 5.1 is set to SERVRESP.

� Whether the profile option values for the fnd profile options (APPS_FRAMEWORK_AGENT, APPS_WEB_AGENT, APPS_JSP_AGENT, APPS_SERVLET_AGENT) are pointing to the correct node. Replace the node_id with the node_id of the external and internal web tier. For example:

� Whether the dbc file pointed to by the JVM parameter (JTFDBCFILE) in oc4j.properties exists.

� Whether the value of the parameter APPL_SERVER_ID, set in the dbc file for the node is the same as the value of the server_id in the fnd_nodes table.

Appendix I: Disabling E-Business Suite Release 12 Application Services on the External Web Tier

On the external web tier, you need to run only the Oracle E-Business Suite application services that are needed by the external facing E-Business Suite module. All services except the "Root Service Group", Web Entry Point Services and "Web Application Services" must be disabled. In addition, you can disable the forms and oafm web application services .To disable a service, perform the following steps:

� Run the AutoConfig Context Editor as documented in the Oracle MetaLink Note 387859.1 "Using AutoConfig to Manage System Configurations with Oracle Applications R12 ". � Click on Site Map, AutoConfig � Select the Applications Context file of the external web tier, Click on Edit Parameters, Processes � Perform the required updates and save the changes.

Appendix J: Disabling "About this page" Link From the Release 12 Login Page

There is a new link named "About this Page" on the Release 12 Login page. Displaying this link is the default for Release 12. The "About this Page" link points to a page that provides a wealth of information about the applications instance such as applied patches, profiles, technology components, etc. to all users prior to authentication. This is not desirable on a DMZ type of environment.

This link is displayed only when the profile option value for FND: Diagnostics is set to "YES" at SITE level. So, to disable this link on all your servers all you have to do is set this profile option to NO at the SITE level.

To disable the link on a server by server basis follow these steps:

1. Change the hirearchy type of FND_DIAGNOSTICS profile option to Server-Responsibilty. 2. Set the profile option value at server level to NO for the servers where the link is to be disabled, while keeping the Site level value set to YES.

select PROFILE_OPTION_NAME,HIERARCHY_TYPE from fnd_profile_options where profile_option_name in ('APPS_WEB_AGENT','APPS_SERVLET_AGENT','APPS_JSP_AGENT','APPS_FRAMEWORK_AGENT', 'ICX_FORMS_LAUNCHER','ICX_DISCOVERER_LAUNCHER','ICX_DISCOVERER_VIEWER_LAUNCHER', 'HELP_WEB_AGENT','APPS_PORTAL','CZ_UIMGR_URL','QP_PRICING_ENGINE_URL','TCF:HOST');

select fnd_profile.value_specific('APPS_FRAMEWORK_AGENT',null,null,null,null,) from dual;

DJTFDBCFILE=

select node_name,node_id,server_id from fnd_nodes;

of 42


Appendix K: Related Documentation

� Oracle Applications System Administrator's Guide - Security � Oracle Applications System Administrators Guide � Best Practices for Securing Oracle E-Business Suite R12 � Using Load-Balancers with Oracle E-Business Suite Release 12 � Using AutoConfig to Manage System Configurations with Oracle E-Business Suite Release 12 � Cloning Oracle Applications Release 12 with Rapid Clone � Sharing the Application Tier File System in Oracle E-Business Suite Release 12 � Enabling SSL in Oracle Application Release 12

Change Log

Change Log

Date Description

OCT 28, 2011 � Documented that Oracle Access Manager 11g (with mod_osso as the agent for Oracle E-Business Suite) is supported below Figure F8.

OCT 24. 2011 � ASP added to the list of certified products

Dec 20. 2010 � Oracle Quoting/ Third Party Portal Added to list of certified products

Dec 22, 2009 � Updated the Appendix A and Appendix B with latest DMZ certified products

Dec 21, 2009 � Added Oracle Access Manager Configuration

Dec 04 , 2009 � OIE added to the list of certified products

Sept 18, 2009 � OIP added to the list of certified products

May 09, 2009 � Instructions to enable webentry point services

April 15, 2009 � Added Forward Proxy Configuration

March 03, 2009 � OTL Added to list of certified products

of 42


Note 380490.1 by Oracle Applications Development Copyright Â© 2009 Oracle Corporation Last updated: October 24 2011

Back to top

February 06, 2009 � SSO configuration updates

January 21, 2009 � Removed reference to the configurator note as it does not exist.

September 30, 2008 � Added reverse proxy configuration (section 5.9), clarified web entry point requirements.

July 11, 2008 � Added SSHR product as certified in Appendix A and added "Enable SSL terminator" note into Option 2.4.

May 23, 2008 � Added ASP product as certified in Appendix A .

April 23, 2008� Added "Using Hardware Load Balancers With No External Web Tier" section, "Removed jserv references " and added the step run autoconfig in section "Using Reverse Proxies only in DMZ ".

November 06, 2007 � Removed references to txkSOHM.pl since it is not used in R12.

March 21, 2007 � Added "Enable Distributed Oracle Java Object Cache Functionality" section and "Using Reverse Proxy Only in DMZ" section.

January 22 , 2007 � Document creation date

Attachments

reverseproxy_withsso_in_dmz-oam.png (45.55 KB)

reverseproxy_withsso_in_dmz.gif (28.59 KB)

Related

Products

� Oracle E-Business Suite > Applications Technology > Application Object Library > Oracle Application Object Library

Keywords

Errors

DMZ; R12; EBS; INSTALL & CONFIGURE; REDIRECT; SOA

HTTP-410; HTTP-400

of 42


Oracle E-Business Suite R12 Configuration in a DMZ

Documents

Transcript of Oracle E-Business Suite R12 Configuration in a DMZ