|
Oracle® Application Server Web Cache Administrator's Guide
10g Release 2 (10.1.2) B14046-05 |
|
 Previous |
 Next |
|
Oracle® Application Server Web Cache Administrator's Guide
10g Release 2 (10.1.2) B14046-05 |
|
|
Previous |
Next |
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:
Configuring OracleAS Web Cache Security
|
See Also:
|
This section describes the OracleAS Web Cache security model. It contains the following topics:
OracleAS Web Cache provides the following security-related features:
|
Note: OracleAS Web Cache does not cache pages that support basic HTTP authentication. These pages result in cache misses. |
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
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 client requests and send HTTPS requests to origin servers. Typically, HTTP requests to origin servers use port 80, and HTTPS requests use port 443.
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. See "Routing Single Sign-On Server Requests" for further information about configuring OracleAS Web Cache with Oracle Application Server Single Sign-On. |
SSL interacts with the following entities:
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.
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 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).
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 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, 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 server-side certificates:
OracleAS Web Cache installs a default certificate that should only be used for testing purposes. OracleAS Web Cache prompts you to obtain a licensed certificate from the CA.
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.
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.
In an ESI cache hierarchy, a provider cache must be able to accept the client-side certificate information in HTTP headers from the subscriber cache. However, with this configuration, the provider caches could inadvertently accept the certificate information in a header from a bogus entity. To prevent this, you must secure the provider caches, by methods such as installing them behind a firewall.
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.
Oracle Application Server 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 Application Server. A future release of Oracle Application Server may support SGC and Global Server IDs.
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. You specify the location of the wallet for each of the OracleAS 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 OracleAS 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 Also:
|
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:
The client initiates a connection to the server by using HTTPS.
SSL performs the handshake between the client and the server to establish a secure connection.
An SSL handshake includes the following actions:
The client and server establish which cipher suites to use.
The server sends its certificate to the client, and the client verifies that the server's certificate was signed by a trusted CA.
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.
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:
|
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:
|
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
Send invalidation requests
Send statistics monitoring requests
Both the Oracle Application Server administrator, ias_admin, and the OracleAS Web Cache administrator, administrator, accounts can use the administrator role. In a cache cluster, the password for all cluster members must be the same. By default, the password is the password you supplied during installation for the administrator username.
The invalidator role is limited to sending invalidation requests. By default, the password is the password you supplied during installation for the administrator username. In a cache cluster, the password for all cluster members must be the same.
You can change the passwords for administrator role or the invalidator role in the Security page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Security) or OracleAS Web Cache Manager (Properties > Security).
|
See Also:
|
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 Security page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Security) or the Process Identity page of OracleAS Web Cache Manager (Properties > Process Identity). By default, the user that performed the installation is the owner of OracleAS Web Cache processes.
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:
|
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 client IP directly to the Oracle HTTP Server, configure the Order directive in the httpd.conf file.
The Oracle Identity Management infrastructure centralizes management of security across the enterprise.
For security reasons, you should not cache content from Oracle Application Server Single Sign-On servers.
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:
|
