Oracle Application Server 10g Security Oracle Application Server Tips by Burleson Consulting

Security is a major concern when deploying an application to the Internet or on an Intranet.  The application has to insure that only authorized users gain access and that the application only returns information that the user has privileges to see.  Likewise, the application server needs to secure the authentication information from unauthorized disclosure.  Oracle Application Server 10g implements security features in each component from the Web Cache to the back-end database.

When a user requests content (such as an employees pay records), the application must insure that the user can access this information, possibly by verifying a user password.  When the content is returned, the application needs to provide some method to re-identify the user.  The application can constantly ask for the users password or return a cookie/URL parameter that is returned with each request to verify a users identity.  If the company has a suite of applications, the user must be validated by each application before gaining access.  Again, each application can request the users password (causing him to constantly re-enter his password) or the first application can return an identity object (cookie, etc) that is validated once and as the user moves from application to application, the cookie acts as his identity.  This is the basis of Oracles Single Sign-On.  A user signs on once and is automatically validated as he moves from application to application within the system.  Of course this capability requires that some secure directory knows the user and verifies his privileges.  This is the job of the Oracle Internet Directory.  Before going further, we should point out that a user may not be a person, such as a customer or employee, it may be another application or system. 

In the next section we will discuss the separate application server components and their security features.  We will then discuss the Oracle Internet Directory (OID) and Single Sign-On (SSO).  Finally we will discuss configuration and maintenance of OID and SSO.

Web Cache

As discussed in detail in Chapter 5, the Oracle Web Cache uses caching rules and content invalidation to ensure that it serves the correct content to the correct user.  However, it is up to the application to correctly implement these rules.  When the application server serves a page containing personal content, Web Cache stores the content and the cookie/URL parameter with the content and will only re-serve that content to a request that returns the cookie/URL parameter.  If the users browser does not accept or return the cookie, Web Cache will submit the request to the origin server because it cant identify the requester.  The initial authentication of the user is the responsibility of the origin server.

Oracle HTTP Server

The Oracle HTTP Server (OHS), discussed in Chapter 4, is built on the industry standard Apache web server.  OHS is responsible for accepting a request and either sending the requested information or passing the request (via mod_oc4j) to the application for processing.  Since OHSs main function is to serve static content, it performs basic rule based authentication to determine what content to serve.  These rules are defined in the Directory Container sections of the httpd.conf file or the .htaccess files.  OHS uses the HTTP header information sent with the request to determine if the requester has access to the static information and either serves the content or returns an error message.  In this way, OHS implements security based on the identity of users, IP address or hostname.  If the request is for dynamic content, OHS passes the request to one of its modules for processing.  In the Oracle Application Server 10g, this module will be mod_oc4j if the request is a JSP page, servlet or a J2EE application.  Mod_oc4j will pass the request to an Oracle Container For Java (OC4J) instance for processing.

Later in this chapter we will introduce mod_osso that is used by OHS to interface with Oracles Single Sign-On application.

OHS insures the security of exchanged data through its implementation of Secure Socket Layers and Public Key Infrastructure (PKI).  When Oracle Application Server 10g is installed, a Secure Socket Layer (SSL) virtual host connection is installed in OHS.  To use the secure connection log onto the server using the SSL port (identified in the ports list of the tiers Enterprise Manager web page) using the https:// URL identifier.

https://appsvr.proxitec.com/4446

The SSL implementation in the users browser interacts with SSL in OHS to provide a secure connection.  The two SSL implementations negotiate the encryption scheme  used to encrypt the connection.  OHS implements an Oracle module called mod_ossl to provide the SSL features.  Mod_ossl is a plug-in to Oracle HTTP Server that enables the server to use SSL. It is very similar to the OpenSSL module, mod_ssl. However, in contrast to the OpenSSL module, mod_ossl is based on the Oracle implementation of SSL, which supports SSL, version 3, and is based on Certicom and RSA Security technology.

One of the most common encryption suites that SSL implements is PKI.  In short, the PKI methodology is to create two keys, the public key is used to encrypt data, the private is required to decrypt data encrypted by the public key.  Even though the data was encrypted using the public key, it cannot be decrypted using the public key.  To see how this works, a user browser provides a public key to one party that it uses to encrypt data and send it back.  The private key (retained by the sender) is the only key that can decrypt data encrypted with the public key.  To exchange information both ways, each party must have two keys, a private key and a public key.  They must exchange public keys.  Each party encrypts data with the other partys public key and decrypts data with their own private key.  In this way, all data exchanged is encrypted and secure.  However, because there is a significant overhead to using a two key system, most SSL implementations use PKI to securely exchange a single encryption  key and then encrypts/decrypts all data using the single key.  These keys are only valid for a session and each session will generate different keys.  Since the keys are constantly changing, any given key will have changed long before someone could break the encryption.

In earlier versions of Oracles application server, the SSL virtual host was configured in the httpd.conf file.  In 10g, it is configured in an included file called ssl.conf.  The ssl.conf file contains the directives to create the virtual host and all the default directives for any other virtual host that implements SSL. 

As a developer, OHSs implementation of SSL is important because it removes the requirement that you implement some type of encryption to insure communication is secure.  Once you insure that the user is accessing the application server using SSL (https:\\) you can send data through OHS and it will insure that the data is encrypted.

This is an excerpt from "Oracle 10g Application Server Administration Handbook" by Don Burleson and John Garmany.