4
OracleAS Web Cache Security

The ability to control user access to Web content and to protect your site against people breaking into your system is critical. This chapter describes the architecture and configuration of security for OracleAS Web Cache:

• About OracleAS Web Cache Security

• Configuring OracleAS Web Cache Security

  See Also: The Oracle Application Server 10g Security Guide provides an overview of Oracle Application Server security and its core functionality. The Oracle Identity Management Concepts and Deployment Planning Guide provides guidance for administrators of the Oracle security infrastructure

About OracleAS Web Cache Security

This section describes the OracleAS Web Cache security model.

OracleAS Web Cache Security Model

OracleAS Web Cache provides the following security-related features:

• Restricted Administration

• Secure Sockets Layer (SSL)

• SSL Acceleration

  Note: OracleAS Web Cache does not cache pages that support basic HTTP authentication. These pages result in cache misses.

Restricted Administration

OracleAS 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

Secure Sockets Layer (SSL)

The Secure Sockets Layer (SSL) protocol, developed by Netscape Corporation, is an industry-accepted standard for network transport layer security. SSL provides authentication, encryption, and data integrity, in a public key infrastructure (PKI). By supporting SSL, OracleAS Web Cache is able to cache pages for HTTPS protocol requests.

As shown in Figure 4-1, you can configure OracleAS Web Cache to receive HTTPS browser requests and send HTTPS requests to origin servers.

Figure 4-1 SSL for Secure Connections

Text description of the illustration owcag027.gif

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

OracleAS Web Cache supports both server-side and client-side certificates.

Limitations: For this release, HTTPS support in OracleAS Web Cache does not provide authentication or access control natively. However, you can deploy OracleAS Web Cache with applications that require Oracle Application Server Single Sign-On.

SSL interacts with the following entities:

• Certificate Authority

• Certificate

• Wallet

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 OracleAS 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.

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.

OracleAS 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, OracleAS Web Cache sends the server certificate to the browser during the SSL handshake, then processes the request for the document. If the requested document 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).

  You configure the caches to listen for HTTPS requests.

• 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.

  For client-side certificates, the browser sends the certificate to the cache during the SSL handshake, then the cache processes the request for the document. If the requested document 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, OracleAS Web Cache adds HTTP headers to the request. These headers begin with the string SSL-Client-Cert.

  You configure the caches to listen for HTTPS requests and to require client-side certificates.

  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 client-side certificates are required, but not provided by the client, OracleAS Web Cache returns an error: 403: Forbidden.

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

• OracleAS 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, OracleAS 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.

  See Also: "Task 7: (Optional) Require Client-Side Certificates"

Wallet

A wallet is a transparent 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 OracleAS 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 OracleAS Web Cache, create a wallet on the OracleAS Web Cache server for each supported site. When creating listening ports for OracleAS Web Cache, specify the location of the wallet. One wallet can be shared among all the listening ports, or a separate wallet can be created for each port.

Note that OracleAS Web Cache installs a default wallet with a default certificate, but that these 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 Also: Oracle Application Server 10g Security Guide for further information about Oracle Wallet Manager "Configuring OracleAS Web Cache for HTTPS Requests" for configuration instructions

How SSL Works

To describe how SSL works in an HTTPS connection, the word client is used to describe either a browser or OracleAS Web Cache, and the word server is used to describe either OracleAS Web Cache or an origin server. For example, when a browser is the client, the server can be OracleAS Web Cache or an origin server; when OracleAS 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 initiates a connection to the server by using HTTPS.

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 negotiated cipher suite.

   See Also: "Configuring OracleAS Web Cache for HTTPS Requests" for configuration details

SSL Acceleration

In addition to offboard SSL acceleration solutions, Oracle Application Server now supports nCipher's BHAPI-compliant hardware for deployment on servers running OracleAS 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 offloads 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 Also: "Deploying OracleAS Web Cache with SSL Acceleration Hardware" http://www.ncipher.com for more information about nCipher

Classes of Users and Their Privileges

OracleAS Web Cache provides support for the administrator and invalidator roles. The administrator can perform the following tasks:

• Start, stop, and restart OracleAS Web Cache

• Change configuration settings in OracleAS Web Cache Manager

• Send invalidation requests with OracleAS Web Cache Manager

• Send statistics monitoring requests

Either the OracleAS Web Cache administrator or the Oracle Enterprise Manager ias_admin accounts can use the administrator role. By default, the password is either the password you supplied during the installation, or, if you were not prompted to supply a password, administrator.

The invalidator role is limited to sending invalidation requests. By default, the password for the invalidator user is either the password you supplied during the installation, or, if you were not prompted to supply a password, invalidator.

You can change the passwords for administrator role or the invalidator role in the Security page (Properties > Security) of OracleAS Web Cache Manager.

See Also: "Starting OracleAS Web Cache Manager" for more information on the administrator role and its password. "Invalidation from External Sources" for an explanation of how the administrator and invalidator roles send invalidation requests "Task 2: Modify Security Settings" for instructions on changing the administrator and invalidator passwords

Resources Protected

By default, the user that performed the installation is the owner of OracleAS Web Cache files. These files are readable by user ID and group ID specified in the Process Identity page (Properties > Process Identity). If you change the process identity user, you must manually change the ownership of OracleAS Web Cache files and directories to the new user ID and group ID with the chown command.

See Also: Step 4e of "Task 2: Modify Security Settings" for information about modifying the settings

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. OracleAS Web Cache does not restrict IP address restrictions on a URL basis. If you are using mod_access with OracleAS 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 browser IP directly to the Oracle HTTP Server, configure the Order directive in the httpd.conf file.

See Also: Oracle HTTP Server Administrator's Guide

Leveraging Oracle Identity Management Infrastructure

Oracle Application Server Single Sign-On Servers

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

Oracle Application Server Single Sign-On Partner Applications (mod_osso)

You can configure OracleAS 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 OracleAS Web Cache is load balancing requests for identical Single Sign-On partner applications, configure the Oracle HTTP Servers as a cluster so that together, the applications act as a single partner application. You can then configure OracleAS 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.

See Also: "Routing Single Sign-On Server Requests" for further information about deploying OracleAS Web Cache with Oracle Application Server Single Sign-On "Task 9: Configure Origin Server, Load Balancing, and Failover Settings" for instructions about configuring origin server and stateless load balancing settings "Bind a Session to an Origin Server" for instructions on configuring stateful load balancing settings Oracle Application Server Single Sign-On Administrator's Guide for further information about clustering mod_osso on the Oracle HTTP Servers

Configuring OracleAS Web Cache Security

See: "Configuring OracleAS Web Cache for HTTPS Requests" for information about configuring OracleAS Web Cache for HTTPS requests