Oracle Web Cache Security Model

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:

■ Section 5.1, "Introduction to Security in Oracle Web Cache"

■ Section 5.2, "Configuring Password Security"

■ Section 5.3, "Configuring Access Control"

■ Section 5.4, "Configuring Oracle Web Cache for HTTPS Requests"

■ Section 5.5, "Additional HTTPS Configuration"

■ Section 5.6, "Configuring HTTP Request Header Size"

■ Section 5.7, "Ensuring That ClientIP Headers Are Valid"

■ Section 5.8, "Configuring Support for Caching Secured Content"

■ Section 5.9, "Running webcached with Root Privilege"

■ Section 5.10, "Script for Setting File Permissions on UNIX"

5.1 Introduction to Security in Oracle Web Cache

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

■ Section 5.1.1, "Oracle Web Cache Security Model"

■ Section 5.1.2, "Resources Protected"

■ Section 5.1.3, "Authorization and Access Enforcement"

■ Section 5.1.4, "Leveraging Oracle Identity Management Infrastructure"

5.1.1 Oracle Web Cache Security Model

Oracle Web Cache provides the following security-related features:

■ Section 5.1.1.1, "Restricted Administration"

■ Section 5.1.1.2, "Secure Sockets Layer (SSL)"

■ Section 5.1.1.3, "SSL Acceleration"

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

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:

■ Section 5.1.1.2.1, "Certificate Authority"

■ Section 5.1.1.2.2, "Certificate"

■ Section 5.1.1.2.3, "Wallet"

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.

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

Application

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.