5 Configuring Security

The ability to control user access to Web content and to protect against intrusion is the critical issue affecting enterprise deployment. This chapter describes how to configure security for Oracle Web Cache.

For general information about security, see the Oracle Fusion Middleware Security Guide.

This chapter includes the following topics:

5.1 Introduction to Security in Oracle Web Cache

This section describes the Oracle Web Cache security model. It contains the following topics:

5.1.1 Oracle Web Cache Security Model

Oracle Web Cache provides the following security-related features:

5.1.1.1 Restricted Administration

Oracle Web Cache restricts administration with the following features:

  • Password authentication for administration and invalidation operations

  • Control over which ports are used for administration and invalidation operations

  • IP and subnet administration restrictions

5.1.1.2 Secure Sockets Layer (SSL)

The HTTPS protocol (HTTP over SSL) is used to encrypt network traffic. Oracle Web Cache supports HTTPS for all of its network traffic, including HTTP clients, administration, invalidation, and statistics requests, and to communicate with its origin servers and cache cluster peers.

As shown in Figure 5-1, you can configure Oracle Web Cache to receive HTTPS client requests and send HTTPS requests to origin servers.

Figure 5-1 SSL for Secure Connections

Description of Figure 5-1 follows
Description of "Figure 5-1 SSL for Secure Connections"

When sending requests to origin servers, note that HTTPS traffic can be processor intensive. If traffic from Oracle Web Cache to an origin server must travel over the open Internet, configure Oracle Web Cache to send HTTPS requests to the origin servers. If traffic only travels through a LAN in a data center, then consider using HTTP to reduce load on the origin servers.

Oracle Web Cache supports both server-side and client-side certificates. SSL server certificates can be used to verify the authenticity of the server, and SSL client certificates can be used to restrict access to certain clients. SSL however is generally not used alone for user verification.

This section interacts with the following entities:

5.1.1.2.1 Certificate Authority

A certificate authority (CA) is a trusted third party that certifies the identity of third parties and other entities, such as users, databases, administrators, clients, and servers. The certificate authority verifies the party identity and grants a certificate, signing it with its private key. The certificate you use in Oracle Web Cache must be signed by a CA.

Different CAs may have different identification requirements when issuing certificates. One may require the presentation of a user's driver's license, while another may require notarization of the certificate request form, or fingerprints of the requesting party.

The CA publishes its own certificate, which includes its public key. Each network entity has a list of certificates of the CAs it trusts. Before communicating with another entity, a given entity uses this list to verify that the signature on the other entity's certificate is from a known, trusted CA.

Network entities can obtain their certificates from the same or different CAs. By default, Oracle Wallet Manager automatically installs with trusted certificates from VeriSign, RSA, Entrust, and GTE CyberTrust.

5.1.1.2.2 Certificate

A certificate is a digital data record used for authenticating network entities such as a server or a client. It is created when a party's public key is signed by a trusted CA. A certificate ensures that a party's identification information is correct, and that the public key actually belongs to that party.

A certificate contains the party's name, public key, and an expiration date—as well as a serial number and certificate chain information. It can also contain information about the privileges associated with the certificate.

When a network entity receives a certificate, it verifies that it is a trusted certificate—one issued and signed by a trusted certificate authority. A certificate remains valid until it expires or is terminated.

Oracle Web Cache supports the following:

  • Server-side certificates: A server-side certificate is a method for verifying the identity of the contacted server. It binds information about the server to the server's public key and must be signed by a trusted CA.

    For server-side certificates, Oracle Web Cache sends the server certificate to the client browser during the SSL handshake, then processes the request for the object. If the requested object is not stored in the cache, the cache forwards the request to the application Web server, a peer cache (in a cluster), or a subordinate cache (in a hierarchy).

    One server-side certificate is required for each unique site configuration. HTTPS does not support multiple virtual hosts on a single port. For example, an environment with 20 site IP address and port number configurations requires 20 separate certificates.

  • Client-side certificates: A client-side certificate is a method for verifying the identity of the client. It binds information about the client user to the user's public key and must be digitally signed by a trusted CA. Certificate Revocation Lists (CRLs) validate the peer certificate in the SSL handshake and ensure that the certificate is not on the list of revoked certificates issued by the CA.

    For client-side certificates, the client browser sends the certificate to the cache during the SSL handshake, then the cache processes the request for the object. If the requested object is not stored in the cache, the cache forwards the request to the application Web server, a peer cache (in a cluster), or another cache (in a hierarchy). To transfer information about the client-side certificate to another cache or to the application Web server, Oracle Web Cache adds HTTP headers to the request. These headers begin with the string SSL-Client-Cert.

    In addition, depending on your deployment, you configure caches to accept the certificate information in HTTP headers from peer caches or from any entities (such as a provider or remote cache) or to not accept the certificate information in headers.

    Note the following about client-side certificates:

    • Client-side certificates are not required for HTTPS requests. They are generally used when PKI-based user authentication is needed, such as in finance, government, or military applications.

    • You can specify that an entire site require client-side certificates.

    • If the listening port requires client certificates, then the connection is refused. If the site requires client certificates and the SSL port does not, then HTTP error 403 Forbidden returns.

    • Oracle Web Cache supports the use of client-side certificates with Oracle HTTP Server only.

    • Oracle Web Cache does not support client-side certificates with a distributed cache hierarchy because the security of the certificates cannot be guaranteed.

    • Although the Oracle HTTP Server supports OpenSSL certificate revocation lists, Oracle Web Cache does not. If you use client-side certificates, you must modify your application to check if the client-side certificate has been revoked. You can do this using a CGI script or servlet.

    • Oracle Fusion Middleware does not support Microsoft Server Gated Cryptography Certificates (SGC) or VeriSign Global Server IDs. This cryptography enables export version browsers to transparently upgrade to strong 128-bit encryption from weaker 40-bit encryption when communicating with an application server. Without this cryptography, browsers with the weaker 40-bit encryption cannot negotiate a secure connection to Oracle Fusion Middleware.

5.1.1.2.3 Wallet

A wallet is a repository used to manage authentication data such as keys, certificates, and trusted certificates needed by SSL. A wallet has an X.509 version 3 certificate, private key, and list of trusted certificates.

Security administrators use Oracle Wallet Manager to manage security credentials on the Oracle Web Cache server. Wallet owners use it to manage security credentials on clients. Specifically, Oracle Wallet Manager is used to do the following:

  • Generate a public-private key pair and create a certificate request for submission to a certificate authority.

  • Install a certificate for the identity.

  • Configure trusted certificates for the identity.

To configure HTTPS for Oracle Web Cache, create a wallet on the Oracle Web Cache server for each supported site. You specify the location of the wallet for each of the Oracle Web Cache HTTPS listening and operations ports (to support incoming HTTPS requests), and the origin server (to support outgoing HTTPS requests). You can share one wallet, or you can create separate wallets. If you use the same wallet, keep in mind that it can support only one server-side certificate.

Note that Oracle Web Cache installs a default wallet with a default certificate, but this wallet should only be used for testing purposes, not in production environments. The SSL connection is not considered secure when using the default wallet. In a production environment, create a new wallet and create a new certificate or import a trusted certificate into the wallet.

See Oracle Fusion Middleware Administrator's Guide for further information about Oracle Wallet Manager.

5.1.1.2.4 How SSL Works

To describe how SSL works in an HTTPS connection, the word client is used to describe either a browser or Oracle Web Cache, and the word server is used to describe either Oracle Web Cache or an origin server. For example, when a browser is the client, the server can be Oracle Web Cache or an origin server; when Oracle Web Cache is the client, the server can be an origin server.

The authentication process between the client and server consists of the steps that follow:

  1. The client and server determine which cipher (encryption algorithm) to use.

  2. SSL performs the handshake between the client and the server to establish a secure connection.

An SSL handshake includes the following actions:

  1. The client and server establish which cipher suites to use.

  2. The server sends its certificate to the client, and the client verifies that the server's certificate was signed by a trusted CA.

  3. Optionally, the server requests a client certificate and the client responds by sending the client certificate to the server. The server verifies that the client certificate was signed by a trusted CA.

  4. The client and server exchange key information using public key cryptography; based on this information, each generates a session key. All subsequent communications between the client and the server is encrypted and decrypted by using this set of session keys and the cipher.

5.1.1.3 SSL Acceleration

Oracle Web Cache provides SSL acceleration by moving the SSL processing to the Web tier.

In addition to off-board SSL acceleration solutions, Oracle Fusion Middleware supports both software-only SSL operations and nCipher's BHAPI-compliant hardware for deployment on servers running Oracle Web Cache and Oracle HTTP Server. When executed in software, SSL operations place a strain on server CPU resources, causing a reduction in throughput and slower overall performance. The nCipher hardware off loads the SSL key exchange processing from a server's CPUs, increasing the number of concurrent SSL connections and improving response times for SSL-protected content.

See http://www.ncipher.com for more information about nCipher.

5.1.2 Resources Protected

By default, the user that performed the installation is the owner of Oracle Web Cache files. Most files are readable by the user ID specified in the Process Identity page of Oracle Web Cache Manager (Properties > Process Identity).

If you change the process identity user, you must manually change the ownership of Oracle Web Cache files and directories to the new user ID and group ID with the chown command.

5.1.3 Authorization and Access Enforcement

The mod_access module of Oracle HTTP Server controls access to the URLs based on characteristics of a request, such as host name or IP address. Oracle Web Cache does not restrict IP address restrictions on a URL basis. If you are using mod_access with Oracle Web Cache, ensure that the protected resources are not cached either by not specifying a caching rule or by explicitly setting a caching rule not to cache the content.

To pass the client IP directly to the Oracle HTTP Server, configure the Order directive in the httpd.conf file. For more information, see the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.

5.1.4 Leveraging Oracle Identity Management Infrastructure

The Oracle Identity Management infrastructure centralizes management of security across the enterprise

5.1.4.1 About Caching Content from Oracle Single Sign-On Servers

For security reasons, you should not cache content from Oracle Single Sign-On servers

5.1.4.2 About Caching Oracle Single Sign-On Partner Applications (mod_osso)

You can configure Oracle Web Cache to cache content for Oracle HTTP Servers running Single Sign-On partner applications. By default, mod_osso protected pages are configured as non-cacheable with a Surrogate-Control: no-store response header.

To override mod_osso default behavior, set OssoSendCacheHeaders to off in the httpd.conf file. For example:

<Location /foo/>
OssoSendCacheHeaders off  
</Location>

This example disables the setting by mod_osso of any cache headers for any URL that starts with /foo. For these URLs, the application is responsible for setting the cache control headers, including Surrogate-Control as appropriate.

If Oracle Web Cache is load balancing requests for identical Single Sign-On partner applications, configure the Oracle HTTP Servers as a cluster, so the applications act as a single partner application. You can then configure Oracle Web Cache to perform stateless load balancing of requests to the servers. If the application mid-tier is not clustered, stateful load balancing is necessary.

5.1.4.3 About Authentication through Oracle Single Sign-On

You can configure Oracle Web Cache to require authentication through Oracle Single Sign-On. Incoming requests must have a valid Oracle Single Sign-On cookie to be served by Oracle Web Cache. See Section 5.8 for configuration details.

5.2 Configuring Password Security

Before submitting invalidation and statistics monitoring requests, establish secure passwords for sending the requests.

The invalidator account is an administrator authorized to send invalidation requests. The invalidator account sends HTTP POST requests to invalidate objects in the cache.

The administrator account is the Oracle Web Cache administrator authorized to log in to Oracle Web Cache Manager and make configuration changes through that interface. This administrator is also authorized to send statistic monitoring requests to the Oracle Web Cache statistics monitoring port. If after monitoring metrics from Fusion Middleware Control you need additional performance metrics, you can access the statistic monitoring port with the administrator account to view detailed performance metrics. See Section 8.4.

The default password for these accounts is the password you supplied in the Web Cache Administrator page of the Oracle Universal Installer. Before you begin configuration, change the passwords for these accounts to a secure password. You must perform this configuration in Fusion Middleware Control.

To establish secure passwords for the invalidator and monitor accounts:

  1. Navigate to the Web Cache Home page in Fusion Middleware Control. See Section 2.6.2.

  2. From the Web Cache menu, select Administration > Passwords.

    The Passwords page displays.

  3. In the New Password field, enter a new password, keeping the following restrictions in mind:

    • Passwords must be between 5 and 30 characters.

    • At least one character must be a number.

    • Passwords can contain only alphanumeric and underscore (_) characters.

    • Passwords must begin with an alphabetic character. Passwords cannot begin with a number, the underscore (_), the dollar sign ($), or the number sign (#).

    • Passwords cannot be Oracle reserved words. The Oracle Database SQL Reference lists the reserved words.

  4. In the Confirm Password field, reenter the new password to confirm you entered the password correctly.

  5. Click Apply.

  6. Restart Oracle Web Cache. See Section 2.13.

    If Oracle Web Cache is not restarted, you may encounter an error when accessing some Fusion Middleware Control pages.

5.3 Configuring Access Control

By default, the computer on which you installed Oracle Web Cache is the trusted host. You can change the trusted subnet or trusted host from which administration, invalidation, and statistics monitoring requests can take place.

To specify if some or all of the traffic to an application is restricted to use HTTPS:

  1. From Oracle Web Cache Manager, in the navigator frame, select Properties > Security. See Section 2.7.2.

    The Security page appears.

  2. In the Security page, click Change Trusted Subnets under the Current Trusted Subnets.

    The Change Trusted Subnets dialog box appears.

  3. Select an option:

    All subnets: Allows requests from all computers in all the subnets in the network.

    This machine only: Allows requests from only this computer.

    Enter list of IP addresses: Allows requests from all IP addresses you enter in a comma-delimited list. You can enter IP addresses in using these format:

    • Complete IP address in dot notation, including the network number, subnet address, and unique host number

      Example: 10.1.0.0

    • Network/netmask pair for subnet restriction through masking

      Example: 10.1.0.0/255.255.0.0 allows all the hosts in the 10.1 subnet access.

    • Network/nnn Classless Inter-Domain Routing (CIDR) specification to require nnn bits from high end to match

      Example: 10.1.0.0/16 allows all the hosts in the 10.1 subnet access. This example is similar to the network/netmask example, except the netmask consists of nnn high-order 1 bits.

  4. Click Submit.

  5. Restart Oracle Web Cache using opmnctl. See Section 2.13.1.

5.4 Configuring Oracle Web Cache for HTTPS Requests

To provide more security for your Web site, you can configure Oracle Web Cache to receive HTTPS protocol client requests and send HTTPS requests to the origin server. HTTPS uses SSL to encrypt and decrypt user page requests as well as the pages that are returned by the Oracle Web Cache and origin servers. You can also configure Oracle Web Cache to send traffic to the origin server through an HTTPS listening port.

To configure HTTPS support for Oracle Web Cache, perform these tasks:

5.4.1 Task 1: Create Wallets

To support HTTPS for Oracle Web Cache, you must create a wallet on the Oracle Web Cache server for each supported site. You need wallets to support the following HTTPS requests:

  • Client requests for sites hosted by Oracle Web Cache

  • Administration, invalidation, and statistics monitoring requests to Oracle Web Cache

  • Oracle Web Cache requests to origin servers, as well as admin server process requests for requests to invalidation and statistics monitoring ports enabled for SSL

For each site that Oracle Web Cache supports, configure at least one wallet. You specify the location of the wallet for each of the Oracle Web Cache HTTPS listening and operations ports (to support incoming HTTPS requests), and the origin server (to support outgoing HTTPS requests). You can share one wallet, or you can create separate wallets. If you use the same wallet, keep in mind that it can support only one server-side certificate.

To create a wallet:

  1. Navigate to the Web Cache Home page in Fusion Middleware Control. See Section 2.6.2.

  2. From the Web Cache menu, select Security and then Wallets.

    The Wallets page displays.

  3. Perform the tasks in section "Create a Wallet" of the Oracle Fusion Middleware Administrator's Guide.

5.4.2 Task 2: Configure an HTTPS Listening Port

To configure HTTPS protocol support between client and Oracle Web Cache, you must configure an HTTPS listening port for Oracle Web Cache.

To add an HTTPS listening port:

  1. Navigate to the Web Cache Home page in Fusion Middleware Control. See Section 2.6.2.

  2. Create the listening port:

    1. From the Web Cache menu, select Administration > Ports Configuration.

      The Ports Configuration page displays.

    2. Click Create.

      The Create Port page appears.

    3. From the Port Type list, select NORM.

    4. In the IP Address field, specify the computer running Oracle Web Cache:

      - IP version 4 address written in a 32-bit dotted decimal notation or an IP version 6 address written in a 128-bit notation. See Section 2.5.

      - A host name that resolves to an IP address of the computer running Oracle Web Cache. If you do not want to rely on Domain Name System (DNS) to resolve the host name, use a different name resolution mechanism, such as the UNIX etc/hosts file.

      - ANY to represent any IP address

    5. In the Port field, enter the listening port from which Oracle Web Cache receives client requests for the Web site.

      Ensure that this port number is not in use.

      Port numbers less than 1024 are reserved for use by privileged processes on UNIX. To configure Oracle Web Cache to listen on a port less than 1024, such as on port 80, run the Oracle Web Cache webcached executable with the root privilege. If the webcached executable is not run as root, Oracle Web Cache fails to start.

      See Section 5.9 for instructions on changing the webcached executable to run as root.

    6. Click OK.

  3. Enable the port for SSL:

    1. From the Web Cache menu, select Security > SSL Configuration.

      The SSL Configuration page displays.

    2. Select the row for the endpoint you created in Step 2 and click Edit.

      The Edit Port page displays.

    3. In the SSL Configuration section, click Enable SSL.

    4. In the Server Wallet Name field, select the wallet you created in Section 5.4.1.

    5. In the Advanced SSL Settings section, click Expand (+) to expand the configuration settings:

    6. From the Client Authentication list, select the type of client authentication.

      - Server Authentication: A server authenticates itself to a client.

      - Mutual Authentication: A client authenticates itself to a server and that server authenticates itself to the client.

      - No Authentication: Neither server nor client are required to authenticate.

      - Optional Client Authentication: The server authenticates itself to the client, but the client may or may not authenticate itself to the server. Even if the client does not authenticate itself, the SSL session still goes through.

    7. From the SSL protocol version list, select the version of SSL to use.

      - All: This selection enables the v1, v3, and v3-v2Hello options.

      - v1: This selection supports TLS version 1 traffic.

      - v3: This selection provides SSL version 3 traffic.

      - v3_v2Hello: This selection combines the SSL version 2 hello message format with SSL version 3 handling to support SSL version upgrade during handshake operations.

    8. Click OK.

5.4.3 Task 3: Configure SSL Settings for Oracle Web Cache Connections to Origin Servers

In this task, specify which SSL wallet to use for Oracle Web Cache connections to origin servers. This wallet must contain a certificate that matches the wallet used by the origin servers.

To specify which SSL wallet to use for Web Cache connections to origin servers:

  1. Navigate to the Web Cache Home page in Fusion Middleware Control. See Section 2.6.2.

  2. From the Web Cache menu, select Security and then SSL Configuration.

    The SSL Configuration page displays.

  3. Click the Expand icon next to the SSL Communication Between Web Cache and Oracle HTTP Server section.

  4. Click Change Wallet to display the Select Client Wallet dialog.

  5. Select the wallet to use, and click OK. Ensure this wallet contains a certificate that matches the wallet used by the origin server.

5.4.4 Task 4: Configure a Site to Require HTTPS Requests

If your environment has a mix of HTTP and HTTPS traffic, follow these instructions to restrict traffic for a specific site (or URL prefix subset of the site), so that the requests must be received by Oracle Web Cache over SSL connections only.

To configure the site settings, use a combination of Fusion Middleware Control and Oracle Web Cache Manager:

  1. In the Fusion Middleware Control, specify a site definition and site-to-server mapping, as described in Section 2.11.3 and Section 2.11.4. When configuring the site definition, ensure you specify an HTTPS listening port. This site uses the wallet defined for that port.

  2. From the Web Cache menu, select Availability > Restart to save the configuration settings and restart Oracle Web Cache.

  3. From Oracle Web Cache Manager, in the navigator frame, select Properties > Site Definition. See Section 2.7.2.

  4. Select the site you created in Step 1, and click Show/Edit Site.

  5. In the Show/Edit dialog, in the HTTPS Only Prefix field, enter the URL prefix for which only HTTPS requests are served. If all traffic must be restricted to HTTPS, enter "/ " for the entire site.

  6. Click Submit.

5.4.4.1 Modify ssl.conf for Keep-Alive Connections

By default, Oracle HTTP Server does not maintain keep-alive connection for HTTPS client requests from Microsoft Internet Explorer 5.5 and later releases. Internet Explorer has known issues with trying to reuse SSL connections after they have timed out. In order for Oracle HTTP Server to maintain keep-alive connections from Oracle Web Cache, you must remove the following entry from the ssl.conf file in $ORACLE_HOME/Apache/Apache/conf directory on UNIX or ORACLE_HOME\Apache\Apache\conf directory on Windows.

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

The ssl.conf file specifies the SSL definitions for Oracle HTTP Server. If this entry is not removed, then keep-alive connections are disabled. See Section 2.11.5 for further information about configuring the keep-alive timeout in Oracle Web Cache.

5.4.5 Task 5: Restart Oracle Web Cache

See Section 2.13.

5.4.6 Task 6: Perform Additional Configuration for Oracle WebLogic Servers

If the orgin server is an Oracle WebLogic Server, you need to specify an extra attribute for Oracle Web Cache to process SSL requests correctly:

To configure Oracle Web Cache for a configuration in which the origin server is an Oracle WebLogic Server:

  1. Use a text editor to open webcache.xml, located in:

    (UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>

  2. Locate the HOST ID element.

  3. Add the SERVERTYPE attribute to the CACHE element. For example:

    <HOST ID="host_ID" NAME="WLS_server_name" PORT="WLS_server_port" LOADLIMIT="100" OSSTATE="ON" SERVERTYPE="WebLogic"/>
...

  4. Save webcache.xml.

  5. Restart Oracle Web Cache with the following command:

    opmnctl restartproc ias-component=component_name

    This executable is found in the following directory:

    (UNIX) ORACLE_INSTANCE/bin
(Windows) ORACLE_INSTANCE\bin

5.5 Additional HTTPS Configuration

After performing the tasks in Section 5.4, you can perform the following optional configuration:

5.5.1 Configuring HTTPS Operation Ports

To configure HTTPS ports to listen for administration, invalidation, or statistics monitoring requests in Fusion Middleware Control:

  1. Navigate to the Web Cache Home page in Fusion Middleware Control. See Section 2.6.2.

  2. Create the listening port:

    1. From the Web Cache menu, select Administration > Ports Configuration.

      The Ports Configuration page displays.

    2. Click Create.

      The Create Port page appears.

    3. From the Port Type list, select the port type, ADMINISTRATION, INVALIDATION, or STATISTICS.

    4. In the IP Address field, specify the computer running Oracle Web Cache:

      - IP version 4 address written in a 32-bit dotted decimal notation or an IP version 6 address written in a 128-bit notation. See Section 2.5.

      - A host name that resolves to an IP address of the computer running Oracle Web Cache. If you do not want to rely on Domain Name System (DNS) to resolve the host name, use a different name resolution mechanism, such as the UNIX /etc/hosts file.

      - ANY to represent any IP address

    5. In the Port field, enter the listening port from which Oracle Web Cache receives client requests for the Web site.

      Ensure that this port number is not in use.

      Port numbers less than 1024 are reserved for use by privileged processes on UNIX. To configure Oracle Web Cache to listen on a port less than 1024, such as on port 80, run the Oracle Web Cache webcached executable with the root privilege. If the webcached executable is not run as root, Oracle Web Cache fails to start.

      See Section 5.9 for instructions on changing the webcached executable to run as root.

    6. Click OK.

  3. Enable the port for SSL:

    1. From the Web Cache menu, select Security > SSL Configuration.

      The SSL Configuration page displays.

    2. Select the row for the endpoint you created in Step 2 and click Edit.

      The Edit Port page displays.

    3. In the SSL Configuration section, click Enable SSL.

    4. In the Server Wallet Name field, select the wallet you created in Section 5.4.1.

    5. In the Advanced SSL Settings section, click Expand (+) to expand the configuration settings:

    6. From the SSL Authentication list, select the type of client authentication.

      - Server Authentication: A server authenticates itself to a client.

      - Mutual Authentication: A client authenticates itself to a server and that server authenticates itself to the client.

      - No Authentication: Neither server nor client are required to authenticate.

      - Optional Client Authentication: The server authenticates itself to the client, but the client may or may not authenticate itself to the server. Even if the client does not authenticate itself, the SSL session still goes through.

    7. From the SSL Protocol Version list, select the version of SSL to use.

    8. Click OK.

5.5.2 Requiring Client-Side Certificates

You can require that clients send certificates (client-side certificates) to the cache to verify the identity of the client.

With client-side certificates, the client browser sends the certificate to the cache during the SSL handshake. Then, the server processes the request for the object. If the requested object is not stored in the cache, the cache forwards the request to the application Web server, a peer cache (in a cluster), or a subordinate cache (in a hierarchy). To transfer information about the client-side certificate to another cache or to the application Web server, Oracle Web Cache adds HTTP headers to the request. The headers begin with the string SSL-Client-Cert.

Note the following points about using client-side certificates:

  • In a simple configuration (client to cache to application Web server), the client sends the certificate to the cache during the SSL handshake. If the requested object is not stored in the cache, the cache forwards the request to the application Web server and transfers the client-side certificate information in headers to the application Web server. The application Web server recognizes the headers and responds to the request.

  • In a cluster, the client sends the certificate to a cache cluster member during the SSL handshake. If the requested object is not stored in that cache, the cluster member requests it from a peer (the cluster member that owns the object). With client-side certificates, Oracle Web Cache must be able to pass the client-side certificate information in headers to the peer cluster member, and the peer must be able to pass the headers to the application Web server.

  • If a site requires client certificates, then a 403 Forbidden error returns if a client certificate is not provided. If a listen port requires client certificates, then the SSL handshake fails if a client certificate is not provided.

    Note:

    Oracle Web Cache supports the use of client-side certificates with Oracle HTTP Server only.

    Oracle Web Cache does not support client-side certificates with a distributed cache hierarchy because the security of the certificates cannot be guaranteed.

The following topics describe how to configure client-side certificate settings:

5.5.2.1 Configuring Client-Side Certificate Settings for the HTTPS Listening Ports

To use client-side certificates, you must enable an HTTPS listening port, as described in Section 5.4.2. If you have a cache cluster, you must enable HTTPS listening ports for all cluster members. In addition, you must configure Oracle Web Cache to require client browsers to provide SSL certificates.

After configuring the client-side certificate, to enable Oracle Web Cache to transfer certificate information to Oracle HTTP Server, add the AddCertHeader directive to httpd.conf. See the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server for information about adding the AddCertHeader directive.

5.5.2.2 Configuring Client-Side Certificate Settings for Cache Clusters

If you have a cache cluster, you must prevent a cache from accepting the certificate information in HTTP headers from any source other than a peer cluster member. In addition, each cache must be able to pass the client-side certificate information in headers to the peer cluster member, and the peer must be able to pass them to the application Web server.

To configure this behavior in Oracle Web Cache Manager:

  1. From Oracle Web Cache Manager, in the navigator frame, select Properties > Security. See Section 2.7.2.

  2. In the Security Header Configuration section of the Security page, set the value of Accept SSL client certificates encoded in SSL-Client-Cert HTTP headers to NO (the default), so Oracle Web Cache does not accept the certificate information in HTTP headers. This setting prevents caches in a cache cluster from accepting the certificate information in HTTP headers.

  3. In the Cluster Security Configuration section, set the value of the Route requests that contain SSL client certificates to cache cluster peers to YES, enabling Oracle Web Cache to pass information about the client-side certificate in HTTP headers to a peer cache. This setting is used for caches in a cache cluster so that they can pass the information to a peer cache.

  4. Click Apply Changes.

  5. Restart Oracle Web Cache. See Section 2.13.

5.5.2.3 Configuring Client-Side Certificate Settings for a Site

You can also specify that an entire site require client-side certificates. If a site requires client certificates, then a 403 Forbidden error returns if a client certificate is not provided.

To configure a site to use client-side certificates:

  1. From Oracle Web Cache Manager, in the navigator frame, select Properties > Site Definition. See Section 2.7.2.

  2. In the Site Definitions page, select the site and click Show/Edit Site.

  3. In the Show/Edit dialog, in the Client-Side Certificate field, select Required.

  4. Click Submit.

  5. Restart Oracle Web Cache. See Section 2.13.

5.5.3 Configuring Certificate Revocation Lists (CRLs)

Fusion Middleware Control or Oracle Web Cache Manager do not provide support for client certificate validation with Certificate Revocation Lists (CRLs). You can configure this support by manually editing the webcache.xml file.

Client certificate revocation status is checked against CRLs that are located in a file system directory. Typically, CRL definitions are valid for a few days, and must be updated on a regular basis. Whenever the CRL definitions are modified, you must restart Oracle Web Cache.

When CRL validation is enabled and available, Oracle Web Cache performs certificate revocation status checking for client certificates. The SSL connection is rejected if a certificate is revoked. SSL connections are accepted if no CRL is found, or if the certificate has not been revoked.

To configure certificate validation with CRL

  1. Enable client certificate for the HTTPS listen port. See Section 5.5.2.

  2. Use a text editor to open webcache.xml, located in:

    (UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>

  3. Locate the HTTPS listen port in webcache.xml for which CRL checking needs to be enabled, and add the SSLCRLENABLE="YES" parameter to the LISTEN directive. For example:

    ...
<LISTEN IPADDR="ANY" PORT="443" PORTTYPE="NORM" SSLENABLED="SSLV3_V2H"  CLIENT_CERT="YES" SSLCRLENABLE="YES" STRONG_CRYPTO_ONLY="NO">
...

  4. Configure CRL file location by adding the SSLCRLPATH and SSLCRLFILE parameters to the HTTPS LISTEN directive.

    • SSLCRLPATH: Enter the path to the directory where CRLs are stored. Ensure that the path is correct; otherwise CRL checking will not work. This parameter has no default value.

    • SSLCRLFILE: Enter the path to a comprehensive CRL file where PEM-encoded (BASE64 CRLs are concatenated in order of preference in one file. If this parameter is set, then the file must be present at the specified location. Otherwise CRL checking will not work.

    For example:

    ...
<LISTEN IPADDR="ANY" PORT="443" PORTTYPE="NORM" SSLENABLED="SSLV3_V2H"  CLIENT_CERT="YES" SSLCRLENABLE="YES"  SSLCRLFILE="/ORACLE_HOME/webcache/crls/sample_crl" SSLCRLPATH="/ORACLE_HOME/webcache/crls/" STRONG_CRYPTO_ONLY="NO">
...

    Use the command line utility orapki to rename CRLs in your file system. See section "Certificate Revocation List Management" in the Oracle Database Advanced Security Administrator's Guide from the Oracle Database documentation library for information about using orapki.

  5. Save webcache.xml.

  6. Restart Oracle Web Cache with the following command:

    opmnctl restartproc ias-component=component_name

    This executable is found in the following directory:

    (UNIX) ORACLE_INSTANCE/bin
(Windows) ORACLE_INSTANCE\bin

    In a cluster configuration, when configuration changes are made directly to a cluster member's webcache.xml file, use Fusion Middleware Control or Oracle Web Cache Manager to propagate the change to other cluster members. See Section 3.6 and Section 3.7.

5.6 Configuring HTTP Request Header Size

By default, Oracle Web Cache provides the following limits for HTTP request header field:

  • 819000 bytes for the total sum of all HTTP request header fields in requests

    Oracle recommends setting the header size to a lower value than the default to ensure security and prevent denial-of-service attacks from malicious clients.

    If the length of the request is larger than the allowed limit,Oracle Web Cache sends an error to the client and reports the error 11356 to the event log:

    Total request header length exceeds configured maximum. A forbidden error response is returned to the client.

  • 8152 bytes for an individual HTTP request header field

    Oracle recommends setting the individual header size based on how large an application sets HTTP requests header fields.

    If the length of the request is larger than the allowed limit, Oracle Web Cache sends an error to the client and reports the error 11355 to the event log:

    Single request header length exceeds configured maximum. A forbidden error response is returned to the client.

To modify the default header limits:

  1. From Oracle Web Cache Manager, in the navigator frame, select Properties > Security. See Section 2.7.2.

    The Security page appears.

  2. In the HTTP Request Header Limits section of the Security page, click Edit.

    The HTTP Request Header Limits dialog box appears.

  3. In the Maximum combined header size in bytes field, specify the total sum of all HTTP request header fields in requests. Specify a limit of at least 4096 bytes (4 KB).

  4. In the Maximum individual header size in bytes field, specify the allowed length limit of an individual HTTP request header fields. Specify a limit of at least 256 bytes.

  5. Click Submit, and then click Apply Changes.

  6. Restart Oracle Web Cache. See Section 2.13.

5.7 Ensuring That ClientIP Headers Are Valid

A client, such as a browser, can send information about its IP address in a header in a request. However, because a client could use a false IP address in the header, allowing a cache to forward that information to another cache or to the origin server can be a potential security problem. By default, Oracle Web Cache removes any IP header information forwarded from a client and replaces it with a header that contains the correct IP address of the client. (In this case, a client can be a browser or another cache in a hierarchy.)

In a cache hierarchy, Oracle Web Cache must be able to preserve the information that is forwarded from one cache to another in the hierarchy or from a cache to the origin server.

To configure these settings:

  1. From Oracle Web Cache Manager, in the navigator frame, select Properties > Security. See Section 2.7.2.

  2. In the Security Header Configuration section of the Security page, check the value of the Accept client IP addresses encoded in ClientIP headers field.

    If the value is NO, Oracle Web Cache removes any ClientIP request-header forwarded from the client and replaces it with a header that contains the correct IP address.

    If the value is YES, Oracle Web Cache accepts the header received from the client and can forward it to another cache or the origin server.

  3. If the settings do not match the following information, click Edit and change the settings in the Security Header Configuration dialog:

    • For a simple configuration, the value should be NO.

    • In a cache cluster, the value should be NO for all cluster members.

    • In a distributed cache hierarchy, for the remote cache, the value should be NO.

    • In a distributed cache hierarchy, for a central cache that receives requests only from other caches, the value should be YES.

      If the central cache receives requests from both browsers and other caches in the hierarchy, Oracle Web Cache cannot distinguish which is a browser and which is another cache. In this case, if you specify YES, a false IP address could potentially be forwarded from a browser. However, correct information would be forwarded from another cache. If you specify NO, a false IP address could not be forwarded from a browser. However, the information forwarded from another cache would contain the IP address of the cache, not of the original client.

  4. Click Submit, and then click Apply Changes.

  5. Restart Oracle Web Cache. See Section 2.13.

5.8 Configuring Support for Caching Secured Content

You can configure Oracle Web Cache to support caching content that is secured by Oracle Single Sign-On authentication with no other authorization requirements.

To enable this setting in Oracle Web Cache Manager:

  1. From Oracle Web Cache Manager, in the navigator frame, select Origin Servers, Sites, and Load Balancing > Site Definitions. See Section 2.7.2.

  2. Select a configured site and click Edit Show/Edit Site.

  3. In the For Site dialog, in the Attributes section, select the type of authentication required for requested objects:

    • Oracle Single Sign-On: Select to require authentication through Oracle Single Sign-On. Oracle Web Cache requires a valid Oracle Single Sign-On cookie to serve requests.

    • None: Select to not require any authentication.

  4. Click Submit.

  5. Restart Oracle Web Cache. See Section 2.13.

5.9 Running webcached with Root Privilege

On UNIX, you must configure webcached to run with root privilege in the following cases:

  • Privileged port numbers less than 1024 are being used for Oracle Web Cache listening ports.

  • There are more than 1,024 file descriptors being used for connections to Oracle Web Cache.

  • The current opmnctl user does not match the configured process identity user in the Process Identity page (Properties > Process Identity) of Oracle Web Cache Manager.

This section contains the following topics:

5.9.1 Configuring Process Identity

By default, the user that performed the installation is the owner of Oracle Web Cache processes. This user can execute opmnctl commands. Users that belong to the same group ID of the user that performed installation can also execute opmnctl commands.

If the current opmnctl user does not match the configured user in the Process Identity page of Oracle Web Cache Manager, the Oracle Web Cache webcached executable must run as root. If the webcached executable is not able to run as root, error events are reported to the event log file, and Oracle Web Cache fails to start.

To change the user ID and group ID for the Oracle Web Cache processes on UNIX:

  1. From Oracle Web Cache Manager, in the navigator frame, select Properties > Process Identity. See Section 2.7.2.

    The Process Identity page appears.

  2. Select the cache for which you want to modify settings, and then click Change IDs.

    The Change Process Identity dialog box appears.

  3. Enter the new user in the User ID field and the group ID of the user in the Group ID field.

  4. Click Submit.

  5. Use the webcache_setuser.sh script as follows to change file and directory ownership:

    webcache_setuser.sh setidentity <user_ID>

    where <user_ID> is the user you specified in the User ID field of the Process Identity page.

    The setidentity command changes the ownership of the following files and directories to the new user ID:

    • webcache.xml configuration file in:

      (UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\webcache_name>

    • Event and access log files in:

      (UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>

  6. Restart Oracle Web Cache using opmnctl. See Section 2.13.1.

5.9.2 Configuring Root Privilege for Privileged Ports and More than 1,024 File Descriptors

For a configuration with privileged ports or to increase the file descriptor limit for Oracle Web Cache, you have two options:

  • Raise the limit for the particular user that is running Oracle Web Cache. Oracle recommends this mechanism. Refer to operating-system documentation for further information about raising the limit for a user.

  • Use the setroot command of webcache_setuser.sh to provide Oracle Web Cache with root privilege without requiring changing the process identity settings

Every time you upgrade Oracle Web Cache or apply a patch, the Oracle Web Cache binaries are relinked implicitly. Therefore, you must rerun the setroot command, as specified in the following procedure.

To use the setroot command of webcache_setuser.sh:

  1. From $ORACLE_HOME/webcache/bin, execute:

    webcache_setuser.sh setroot user_ID

    where user_ID is the user that performed installation. See Section 5.10 for further information about the webcache_setuser.sh script.

  2. Log out of the computer, and re-login as the user that installed Oracle Application Server.

  3. Restart Oracle Web Cache using opmnctl. See Section 2.13.1.

5.9.3 Configuring Root Privilege for the Current User

For a configuration in which the current user does not match the configured user settings, change the process identity of the Oracle Web Cache processes and use the setidentity command of webcache_setuser.sh to provide Oracle Web Cache with root privilege:

  1. Change the process identity of the Oracle Web Cache processes.

    Oracle recommends running Oracle Web Cache using a restricted user. See Section 5.9.1 for instructions on setting the group ID and user ID to establish process identity.

  2. Use the webcache_setuser.sh script as follows to run Oracle Web Cache as a different user and add set-user ID permission to the webcached executable:

    webcache_setuser.sh setidentity user_ID

    where user_ID is the user ID you specified in Step 2. See Section 5.10 for further information about the webcache_setuser.sh script.

  3. Log out of the computer, and re-login as the user you configured in Step 2.

  4. Restart Oracle Web Cache using opmnctl. See Section 2.13.1.

5.9.4 Reverting Permissions Back to Installation State

You can revert permissions back to the installation state with the revert command of webcache_setuser.sh. It is necessary to revert permissions if you used the setidentity command and plan to install a patch release. Otherwise, you cannot write to files in the $ORACLE_HOME/webcache directory. After the patch installation is complete, you can choose to change the process identity again with the setidentity command.

To revert file permissions:

  1. Use the webcache_setuser.sh script as follows to revert file permissions back to the installed state:

    webcache_setuser.sh revert user_ID

    where user_ID is the user that performed installation. See Section 5.10 for further information about the webcache_setuser.sh script.

  2. Log out of the computer, and re-login as the user that installed Oracle Application Server.

  3. Restart Oracle Web Cache using opmnctl. See Section 2.13.1.

5.10 Script for Setting File Permissions on UNIX

For UNIX operating systems, use the webcache_setuser.sh script to set the file permissions according to the mode in which to run Oracle Web Cache. The file webcache_setuser.sh is located in the directory $ORACLE_HOME/webcache/bin.

Prior to running the webcache_setuser.sh script, stop both the cache and admin server processes, using the OPMN utility command:

opmnctl stopproc ias-compononent=WebCache

The following shows the format of the webcache_setuser.sh syntax:

webcache_setuser.sh command user_ID

Table 5-1 describes the commands.

Table 5-1 Commands of the webcache_setuser.sh Script

Command Description

setroot

Sets the ownership of the webcached executable to root, and runs Oracle Web Cache as the user that performed the installation.

setidentity

Changes the ownership of the run time Oracle Web Cache user. This command adds set-user ID permission to the webcached executable.

revert

Reverts the file permissions back to the installation state.

It is necessary to revert permissions if you used the setidentity command and plan to install a patch release. Otherwise, you cannot write to files in the $ORACLE_HOME/webcache directory. After the patch installation is complete, you can choose to change the process identity again with the setidentity command.

The parameter user_ID is the user ID associated with the Oracle Web Cache processes. (By default, that user ID is the ID of the user that performed the installation.) For setroot and revert modes, the user ID must be the ID of the user that performed the installation. The user ID must match the user ID specified in the Process Identity page (Properties > Process Identity) of Oracle Web Cache Manager. See the Section 5.9 for further information about when running the webcache_setuser.sh script is necessary.