15
Security Tips

These hints come from the Security Best Practices document, available from Oracle Technology Network (http://otn.oracle.com). Check the OTN Web site for updates.

HTTPS

Oracle HTTP Server (OHS) has several features that provide security to an application without requiring you to modify the application. You should evaluate and leverage these features before coding similar features yourself. HTTP security features include:

• Authentication -- OHS can authenticate users and pass the authenticated user-id to an application in a standard manner (REMOTE_USER). It also supports single sign-on, thus reusing existing login mechanisms.

• Authorization -- OHS has directives that can allow access to your application only if the end user is authenticated and authorized. Again, no code change is required.

• Encryption -- OHS can provide transparent SSL communication to end customers without any code change on the application.

Other suggestions for securing HTTPS:

• Configure Oracle Application Server to fail attempts to use weak encryption. You can configure Oracle Application Server to use only specified encryption ciphers for HTTPS connections. For instance, your application could reject connections from non-128-bit client-side SSL libraries. This ability is especially useful for banks and other financial institutions because it provides server-side control of the encryption strength for each connection.

• Use HTTPS to HTTP appliances for accelerating HTTP over SSL. Use HTTPS everywhere you need to. However, the huge performance overhead of HTTPS forces a trade-off in some situations.

  For a relatively low cost, HTTPS-to-HTTP appliances can change throughput on a 500MHz UNIX machine from 20-30 transactions per second to 6000 transactions per second, making this trade-off decision easier.

  Moreover, these appliances provide much better solutions than adding mathematics or cryptography cards to UNIX, Windows, or Linux boxes.

  Ensure that sequential HTTPS transfers are requested through the same Web server. Expect 40 to 50 milliseconds of CPU time to initiate SSL sessions on a 500 MHz machine. Most of this CPU time is spent in the key exchange logic, where the bulk encryption key is exchanged. Caching the bulk encryption will significantly reduces CPU overhead on subsequent accesses, provided that the accesses are routed to the same Web server.

• Keep secure pages and pages not requiring security on separate servers. Although it may be easier to place all pages for an application on one HTTPS server, this strategy has enormous performance costs. Reserve your HTTPS server for pages needing SSL, and put the pages not needing SSL on an HTTP server.

  If secure pages are composed of many GIF, JPEG, or other files to be displayed on the same screen, it is probably not worth the effort to segregate secure from nonsecure static content. The SSL key exchange (a major consumer of CPU cycles) is likely to be called exactly once in any case, and the overhead of bulk encryption is not that high.

Overall Security

• When assigning privileges to modules, use the lowest levels that are adequate to perform the modules' function(s). Using low-level privileges provides "fault containment": if security is compromised, it is contained within a small area of the network and cannot invade the entire intranet.

• Tune the SSLSessionCacheTimeout directive if you are using SSL. The Apache server in OracleAS caches a client's SSL session information by default. With session caching, only the first connection to the server incurs high latency.

  In a simple test to connect and disconnect to an SSL-enabled server, the elapsed time for 5 connections was 11.4 seconds without SSL session caching; with session caching enabled, the elapsed time was 1.9 seconds.

  The default SSLSessionCacheTimeout is 300 seconds. Note that the duration of an SSL session is unrelated to the use of HTTP persistent connections. You can change the SSLSessionCacheTimeout directive in httpd.conf file to meet your application needs.

JAAS

• Migrate your user management from principals.xml to the JAAS Provider. In earlier releases of OracleAS, the J2EE application server component stored all user information in a file called principals.xml (including storing passwords in cleartext). The OracleAS JAAS Provider provides a similar simple security model as a default, without storing passwords in cleartext. The JAAS Provider also offers tight integration with OracleAS Infrastructure (including SSO and OID) out of the box.

• Avoid writing custom user managers; instead, extend the JAAS Provider, SSO, and OID. The Oracle Application Server Containers for J2EE (OC4J) container continues to supply several methods and levels of extending security providers. Although you can extend the UserManager class to build a custom user manager, leveraging the rich functionality provided by the JAAS Provider, SSO, and OID gives you more time to focus on actual business logic instead of infrastructure code. Both SSO and OID provide APIs to integrate with external authentication servers and directories respectively.

• Use SSO as the authentication mechanism with the JAAS Provider. The JAAS Provider allows different authentication options. However, we strongly recommend leveraging the SSO server whenever possible because:
  • It is the default mechanism for most OracleAS components, such as Portal, Forms, Reports, Wireless, and so on.

  • It is easy to set up in a declarative fashion and does not require any custom programming.

  • It provides seamless PKI integration.

• Use the JAAS Provider's declarative features to reduce programming. Because most of the features in the OracleAS JAAS Provider are controlled declaratively, particularly in the area of authentication, developers can postpone setup until deployment time. This not only reduces the programming tasks for integrating a JAAS based application, it allows the deployer to use environment-specific security models for that application.

• Use the fine-grained access control offered by the JAAS Provider and the Java permission model. Unlike the "coarse-grained" J2EE authorization model as it exists today, the JAAS Provider integrated with OC4J allows any protected resource to be modeled using Java permissions. The Java permission model (and associated Permission class) is extensible and allows a flexible way to define fine-grained access control.

• Use OID as the central repository for the JAAS Provider in production environments. Although the JAAS Provider supports a flat-file XML-based repository useful for development and testing environments, it should be configured to use OID for production environments. OID provides LDAP standard features for modeling administrative metadata and is built on the Oracle database platform, inheriting all the database properties of scalability, reliability, manageability, and performance.

• Take advantage of the authorization features of the JAAS Provider. In addition to the authorization functionality defined in the JAAS 1.0 specification, the OracleAS JAAS Provider supports:
  • Hierarchical, role-based access control (RBAC)

  • The ability to partition security policy by subscriber (that is, each user community)

  These extensions provide a more scalable and manageable framework for security policies covering a large user population.