Oracle® Application Server Best Practices Guide
10g Release 2 (10.1.2)
This chapter describes security and management best practices for Oracle Application Server. It includes the following topics:
This section describes general best practices for security and management. It includes the following topics:
The following are recommended for using HTTPS with Oracle Application Server:
Configure Oracle Application Server to fail attempts that use weak encryption. You can configure Oracle Application Server to use only specific encryption ciphers for HTTPS connections. Connections from all old Web browsers that have not upgraded the client-side Secure Sockets Layer (SSL) library to 128-bit can be rejected. This functionality 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. Huge performance overhead of HTTPS forces a trade-off in some situations. Use of HTTPS to HTTP appliances can change throughput from 20 to 30 transactions for each second on a 500 MHz Unix to 6000 transactions for each second for a relatively low cost, making this trade-off decision easier. This solution is better than math and crypto cards, which can be added to UNIX, Windows NT, and Linux computers.
Ensure that sequential HTTPS transfers are requested through the same Web server. Expect 40/50 milliseconds CPU time for initiating SSL sessions on a 500 MHz computer. Most of this CPU time is spent in the key exchange logic, where the bulk encryption key is exchanged. Caching the bulk encryption key will significantly reduce CPU overhead on subsequent access, provided that the access is routed to the same Web server.
Keep secure pages and pages not requiring security on separate servers. While it may be easier to place all pages for an application on one HTTPS server, the resulting performance cost is very high. Reserve your HTTPS server for pages that require SSL. Put pages that do not require SSL on an HTTP server.
If secure pages are composed of many GIF, JPEG, or other files that would be displayed on the same screen, it is probably not worth the effort to segregate secure from non-secure 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
When assigning privileges to modules, use the lowest levels adequate to perform the modules functions. This assignment is essentially fault containment, that is, if security is compromised, it is contained within a small area of the network and cannot invade the entire intranet.
Make sure that cookies have proper expiration dates. Permanent cookies should have relatively short expiration dates of about three months or less. This configuration will avoid cluttering client Web browsers, which may cause errors if the Web browser cannot transmit all the valid cookies. Set non-permanent cookies to expire when the relevant application exits.
Make sure that information in cookies contains Method Authentication. Use authentication to ensure that cookie data has not been changed since the application set the data. This authentication helps ensure that the cookie cannot be modified and deceive the application. Also, this helps prevent application failures if the cookie is inadvertently corrupted.
Make sure that the size and varieties of cookies are kept low. There is a finite number and aggregate size of cookies that Web browsers support. If this is exceeded, then the Web browsers will not send all the relevant cookies leading to application failures. Also, very large cookies can result in performance degradation.
Carefully use cookie domain name facilities. Use of cookie domains should ensure that the domain is the smallest possible. Making the domain
oracle.com, for instance, would mean that any host in
oracle.com would get the cookie. With hundreds of applications on different parts of
oracle.com, a domain of
oracle.com for each of them results in attempts to send hundreds of cookies for each HTTP input operation.
Use the following as guidelines for system setup:
Apply all relevant security patches. Check MetaLink (
http://metalink.oracle.com) and OTN (
http://www.oracle.com/technology/index.html) for current security alerts. Many of these patches address publicly announced security issues.
When deploying software, change all default passwords and close accounts used for samples and examples.
Remove unused services from all hosts. Examples of unused services are FTP, SNMP, NFS, BOOTP, and NEWS. HTTP or WebDAV may be good alternatives.
Limit the number of people with root and administrative privileges.
In UNIX, disable the "r" commands if you do not need them. For example,
Ensure that certificate organization unit plus issuer fields uniquely identify the organization across the Internet. One way to accomplish this would be to include the Dun and Bradstreet or IRS identification as identification for the issuer and the organizational unit within the certificate.
Ensure that certificate issuer plus distinguished name uniquely identify the user. If the combination of issuer and distinguished name is used as identification, there is no duplication risk.
Include expiring certificates in tests of applications using certificates. Expiration is an important consideration for a number of reasons. Unlike most username/password-based systems, certificates expire automatically. With longer duration certificates, fewer re-issues are required, but revocation lists become larger.
In systems where certificates replace traditional usernames/passwords, expiring certificate situations may result in unexpected bugs. Careful consideration of the effects of expiration is required and new policies will have to be developed because most application and infrastructure developers have not worked in systems where authorization might change during transactions.
Use certificate re-issues to update certificate information. Because certificates expire, infrastructure for updating expired certificates will be required. Take advantage of the re-issue to update organizational unit or other fields. In cases of mergers, acquisitions, or status changes of individual certificate holders, consider re-issuing even when the certificate has not yet expired. But pay attention to key management. If the certificate for a particular person is updated before it expires, for example, put the old certificate on the revocation list.
Audit certificate revocations. Revocation audit trails can help you reconstruct the past when necessary. An important example is replay of a transaction to ensure the same results on the replay as during the original processing. If the certificate of a transaction participant was revoked between the original and the replay, failures may occur. These errors may not have occurred when the original transaction was processed. For these cases, view the audit trail to simulated authentication at the time when the transaction was initially processed.
It is quite common for viruses or known attacks to resurface in slightly altered shape or form. Thus, just because a threat has been apparently eliminated does not mean it will not resurface. Use the following as guidelines to minimize the recurrence of the threat:
Ensure that programs are reviewed against double encoding attacks. There area many cases where special characters, such as
| are encoded to prevent cross-site scripting attacks or for other reasons. For example,
< might be substituted for
>. In a double encoding, the attacker might encode the
& so that later decoding might involve the inadvertent processing of a
| character as part of a script. Prevention of this attack, unfortunately, can only be provided by careful program review. You can use some utilities to filter escape characters that might result in double-encoding problems in later processing.
Ensure that programs are reviewed against buffer overflow for received data.
Ensure that programs are reviewed against cross-site scripting attacks. This attack typically tricks HTML and XML processing through input from Web browsers (or processes that act like Web browsers) to invoke scripting engines inappropriately. However, it is not limited to the Web technologies, and you should evaluate all code for this.
Place servers providing Internet services behind an exterior firewall of the stateful inspection type. Stateful inspection means that the firewall keeps track of various sessions by protocol and ensures that illegal protocol transitions are disallowed through the firewall. This configuration blocks the types of intrusion that exploit illegal protocol transitions.
Set exterior firewall rules to allow Internet-initiated traffic only through specific IP and PORT addresses where SMTP, POP3, IMAP, or HTTP services are running. Some protocols, such as IIOP, leave ports open without receiving processes. Port and IP combinations that are not assigned to running programs should not be permitted.
Set interior firewall rules to allow messages through to the intranet only if they originate from servers residing on the perimeter network. All incoming messages must first be processed in the perimeter network.
Send outgoing messages through proxies on the perimeter network.
Do not store the information of record on bastion hosts. Bastion hosts are fortified servers on the perimeter network. Segment information and processing such that the bastion hosts provide initial protocol server processing and generally do not contain information of a sensitive nature. The database of record and all sensitive processing should reside on the intranet.
Disallow all traffic types unless specifically allowed. allow only the traffic required by Oracle Application Server for better security. For example, HTTP, AJP, OCI, LDAP.
Oracle HTTP Server has several features that provide security to an application without requiring the application to be modified. Leverage or evaluate these features before programming similar functionality as those features into the application. Specifically:
Authentication: Oracle HTTP Server can authenticate users and pass the authenticated user-id to an application in a standard manner. It also supports single sign-on, thus reusing existing login mechanisms.
Leverage these three features before designing any application-specific security mechanisms.
Oracle recommends that all DMZ attached devices be connected by switched, not bussed connections. Furthermore, devices such as the Cisco 11000 series devices, which can provide IP, port, and protocol rules between each pair of connected devices are preferred.
Application servers should exist in the DMZ. In this architecture OracleAS Web Cache only forwards requests to computers containing Web servers. Web servers only forward requests to application servers or through PL/SQL to database servers. The application servers only forward inward requests to the database or, perhaps, special message processing processors in the intranet. This configuration provides excellent fault containment because a compromised Web server must somehow compromise an application server before the database can be attacked.
You can use Secure Sockets Layer (SSL) encryption to secure both LDAP and HTTP traffic that passes between the various components of the Oracle Application Server. To ensure that all LDAP queries being sent to Oracle Internet Directory are SSL-encrypted, you need to configure your Oracle Internet Directory instance to run with a configuration set that supports only SSL-encrypted LDAP connections. The default mode installed with Oracle Application Server allows a given Oracle Internet Directory instance to be configured to listen on both SSL and non-SSL ports.
SSL encryption is unrelated to the installation or use of HTTPS, which allows users to access Oracle Application Server components over HTTP while using SSL to encrypt Web client packets.
See Also:Oracle Internet Directory Administrator's Guide for more details on configuring Oracle Internet Directory instances with SSL
The Apache server in Oracle Application Server caches a client 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 five connections was approximately 11.4 seconds without SSL session caching as opposed to approximately 1.9 seconds when session caching was enabled.
SSLSessionCacheTimeout is 300 seconds. Note that the duration of a 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.
Consult the Oracle Application Server Enterprise Deployment Guide and the Oracle Identity Management Concepts and Deployment Planning Guide documents when planning out the final target topology. Identify the steps in installing and configuring the various Oracle Application Server components consistent with the options of the Oracle Universal Installer, rather than approaching the desired topology on an adhoc basis.
Oracle Application Server provides an implementation of OracleAS JAAS Provider for J2EE applications that is fully integrated with J2EE declarative security. This implementation allows J2EE applications to take advantage of the JAAS constructs, such as principal-based security and pluggable login modules. Optionally, the OracleAS JAAS Provider implementation allows J2EE applications running on OC4J to leverage the central security services of Oracle Identity Management.
The OC4J container continues to provide several methods and levels of extending security providers. You can extend the
UserManager class to build a custom user manager that enables you to leverage the functionality provided by the OracleAS JAAS Provider. Both OracleAS Single Sign-On and Oracle Internet Directory provide APIs to integrate with external authentication servers and directories respectively, thus allowing developers more time to focus on actual business logic instead of infrastructure code.
It is the default mechanism for most Oracle Application Server components such as OracleAS Portal, OracleAS Forms Services, OracleAS Reports Services, and OracleAS Wireless.
It is easy to setup in a declarative fashion and does not require any custom programming.
It provides a seamless way for PKI integration.
For environments where OracleAS Single Sign-On is not available, and custom authentication is required, one should use JAAS-compliant
LoginModules to extend OC4J authentication. When using
LoginModules, it is important to only use application relevant principals (roles) associated with the authenticated subject to preserve least privilege.
Unlike the coarse-grained J2EE authorization model as it exists today, the OracleAS 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.
For example, you can write a servlet with
Subject.doPrivileged to control code that executes sensitive operations.
Although the OracleAS JAAS Provider supports a flat-file XML-based repository useful for development and testing environments, configure it to use Oracle Internet Directory for production environments. Oracle Internet Directory provides LDAP standard features for modeling administrative metadata and is built on the Oracle database platform inheriting all of the database properties of scalability, reliability, manageability, and performance. To optimize performance, adjust the caching configurations appropriate for your environment.
Simple J2EE applications using HTTP Basic authentication do not support the concept of logout, relying instead on the user to close the Web browser. When using other forms of authentication, including OracleAS Single Sign-On, it is important to plan out various logout and timeout flows. OC4J has an adjustable HTTP session inactivity parameter that is set to 20 minutes by default. If J2EE applications are leveraging OracleAS Single Sign-On and want to support full logout functionality, write them with the appropriate logout dynamic directives.
Single sign-on failure is catastrophic, since it means no single sign-on protected application can be accessed. Two recommendations for high availability of OracleAS Single Sign-On are:
Carefully consider inclusion of any other types of processing on the single sign-on servers since this can make instability more likely.
Consider deploying multiple single sign-on servers fronted by load balancing hardware to protect against failures in single sign-on listeners. In this case, the address of the load balancer is used as the single sign-on address and the single sign-on listener configuration information is replicated. Oracle also recommends that the database be a RAC configured for additional improvements in availability.
See Also:Whitepaper Expose your Intranet Portal to the Outside World in a Secured Manner available from the Oracle Technology Network at
Use OracleAS Single Sign-On as the primary point of security. This component provides benefits from an administrative point of view and is a major convenience to application customers. Also, OracleAS Single Sign-On is well integrated with the rest of Oracle Application Server Infrastructure and can, with Oracle Internet Directory and other means, be integrated with non-Oracle application and infrastructure. Also, as single sign-on becomes a single point for authentication, opportunities to attack the multiple authentication entities of sites today are reduced.
OracleAS Single Sign-On single authenticated user for all applications allows better control for more uniform authorization.
In order to deploy an effective single sign-on solution, the user population must be centralized in a directory, preferably an LDAP-based directory, such as Oracle Internet Directory. Having users represented in multiple systems, such as in multiple Microsoft Windows NT domains, makes setting up the infrastructure for a common identity more difficult. In addition, clearly defining and automating the user provisioning process makes managing the single sign-on environment much easier.
OracleAS Single Sign-On provides the infrastructure to validate credentials and allows for various different authentication mechanisms, such as username, password, and X.509 certificates. Moreover, since these mechanisms can be shared across different applications and Web sites, end users do not have to create a new username, password for each different corporate application.
The OracleAS Single Sign-On server simplifies user interaction by providing a mechanism to have a single username and password, which can be used by multiple partner applications. With this ease of use, comes the caution that the single sign-on server should always be accessed in the correct fashion. A breach of the common password can now put all partner applications at risk. Therefore, always configure the single sign-on server to allow connections in SSL mode only. This configuration protects the end user's credentials going across the wire. Applications where security and data confidentiality are important should also be protected by SSL. From a performance perspective, use of SSL hardware accelerators is recommended.
The OracleAS Single Sign-On server provides a standard login screen. This login page is serviced from the single sign-on server, which typically is installed on a different computer from the one the end user is trying to access. Thus, it is critical that before the end user enters their login and password, that a valid single sign-on screen is observed. This screen prevents users from unknowingly providing their username or password to inappropriate servers.
Most users do not log out of Internet applications and this issue creates problems at two levels:
A security risk. Another person accessing the work station can now reuse the cookie. Also, since the session remains valid until it times out, a hacker from another computer has a longer time window to guess the session ID or cookie value.
The system resources on the server associated with the cookie are not released until the session is ended or invalidated.
For application developers and administrators, configure single sign-on session duration and inactivity timeouts appropriately. For example, configure one-hour inactivity timeouts for sensitive applications.
Additionally, Oracle also recommends the following documentation for deployment of Oracle Internet Directory:
bulkload.sh utility checks standard LDIF formatted files for schema violations and duplicates, and generates SQL*Loader intermediate files for fast loading into the database tables underlying Oracle Internet Directory. Use the
bulkload.sh utility whenever there is an initial bootstrap required. For example, when setting up synchronization with Microsoft Active Directory or other LDAP directory servers.
Oracle recommends passing the LDIF file output from third-party LDAP directories into
bulkload.sh -check mode, which will alert you to any problems with your existing LDAP schema.
Most third-party LDAP directories (including Oracle Internet Directory) support output to LDIF without any operational attributes (which typically cannot be loaded into another vendor's directory). If you are loading data into Oracle Internet Directory from another directory, which does not support this, you will have to manually remove any operational attributes prior to sending the LDIF file to
bulkload.sh -generate mode.
If your input LDIF file is from another Oracle Internet Directory instance, then you must use the
-restore option to
bulkload.sh to preserve these operational attributes as is during the bulkload.
Oracle Internet Directory supports both multimaster and fan-out styles of directory replication.
For high availability, consider placing an Oracle Internet Directory multimaster replication group behind a network load balancer to provide a single IP address to your LDAP client applications. If a replicated node becomes unavailable, you can configure the load balancer to re-route requests automatically to an available server.
Additionally, each Oracle Internet Directory node can run on Oracle Application Server RAC, further improving availability through increased database uptime and data availability.
See Also:Chapter 3, "Oracle Internet Directory Management Planning," in the Oracle Identity Management Concepts and Deployment Planning Guide for more details about configuring Oracle Internet Directory for high availability
SSL is considered the Internet standard protocol for highly secure transportation of data. In addition to the strong PKI authentication using digital certificates, SSL also provides multiple data integrity and data encryption layers to protect your communication channels. SSL provides multiple cipher suites with varieties of encryption algorithms for many security levels.
Oracle Internet Directory supports three SSL authentication modes:
In this mode, SSL cipher suites use the Diffie-Hellman algorithm to generate a session key for client or server at run time. The session key will be used to encrypt the communication channel. No server or user SSL wallet is necessary. In this mode, the channel will be encrypted using a Diffie-Hellman key.
This mode essentially uses certificates for authentication. The client needs to verify the server certificate. This mode is most commonly used in the Internet environment since any client that needs to communicate with aa SSL server does not require a certificate. A client can use their user and password identification to authenticate itself to the server. The username and password are protected by SSL encryption when being transferred on the wire.
In this mode, both client and server use RSA certificates to authenticate each other. First, the client authenticates the server by validating its certificate. In return, the server also requires the client to send its certificate to prove its authenticity.
In addition to choosing an authentication mode, you should choose appropriate security algorithms.
Depending on your Oracle Application Server enterprise topology, you may want to consider backing up Oracle Internet Directory as part of backing up your entire application server environment.
You can monitor and audit Oracle Internet Directory in one of three ways:
The Oracle Enterprise Manager LDAP page provides a very simple way to monitor the LDAP service and determine if it is up and running under its associated load.
You can also check the log files of various LDAP processes to ensure there are no errors showing up.
LDAP audit log service provides more granular information such as security violation information or sensitive events. You can further customize the audit log to specific directory operations and events.
Oracle recommends that you perform, at the very least, a weekly review of the audit and error logs. System administrators can do a more regular review with Enterprise Manager to provide better availability.
While it is possible to install Oracle Application Server as an Oracle Internet Directory super user, Oracle recommends that this not be done, as it imparts more privileges than required.
To install Oracle Application Server, a user needs to be a member and owner of the Oracle Application Server administrator's group.
When installing Oracle Application Server, the directory administrator should add the installation user as a member and owner of the administrator's group. The administrator should then remove the member as the owner once the installation has completed.
Oracle Internet Directory administrators should change the default access control policies to better control user administration as required.
Oracle Internet Directory administrators should adjust the default access control and password policies using Oracle Directory Manager, in accordance with specific administrative policies for directory access and passwords. This adjustment includes both value and state parameters.
This section includes the following topics:
Use Oracle Directory Integration and Provisioning to build connectivity between Oracle Internet Directory and third-party directories. This feature provides seamless integration with other Oracle products. It enables the Oracle products to work in the presence of third-party directories in the enterprise and also provides sharing with the same identities in other directories.
You can join or unify the different identities for the same enterprise user from multiple LDAP directories into a single global identity in Oracle Internet Directory using Oracle Directory Integration and Provisioning. Oracle Directory Integration and Provisioning facilitates a true single sign-on environment in an enterprise using Oracle Internet Directory and Oracle Application Server Single Sign-On.
Oracle Internet Directory supports representation of multiple applications and multiple realms or administration Contexts in the Oracle Internet Directory. You can provision various enterprise applications for a single or multiple realms. There are automated tools to create new realms and to provision applications for various realms. These tools setup the various levels of access required by the application to manage the realm.
Synchronize user definitions from third-party identity management systems with the Oracle Directory Integration and Provisioning into the appropriate realms to create an enterprise view of all relevant user namespaces and their defined services.
When configuring Oracle Directory Integration and Provisioning, specify only the containers and attributes, which are required in the connected directory or in Oracle Internet Directory. You can use LDAP filters as part of mapping configuration profiles to screen out unwanted attribute data and keep synchronization simple.
Set each connector and its associated mapping configuration file to an appropriate scheduling interval. No connector needs to fire at the same time or at the same interval as any another, as they are completely independent of one another.
When synchronizing external users and groups into Oracle Internet Directory for use with Oracle Application Server, be sure to establish connectors to the appropriate Identity Management Realm
cn=groups container. Oracle Directory Integration and Provisioning will then provision all inbound user entries with the Oracle-specific attributes needed to enable users to interact with their deployed Oracle applications.
A synchronization Profile has to be disabled before altering any status attributes through the Oracle Directory Manager. After the change, it needs to be enabled once again.
If you use Oracle Human Resources as the source of truth for employee data in your enterprise, then you must synchronize between it and Oracle Internet Directory. Since the
Last Successful Execution Time connector profile attribute is used to fetch the desired changes from connected directories at a given time, set it initially to some date in the past. Then enable the profile. Note this technique will potentially cause all entries in the connected directory to be synchronized all at once into Oracle Internet Directory. If this is not the desired effect, use the
bulkload.sh technique for bootstrapping Oracle Internet Directory, and then set the last change number appropriately to begin synchronizing incrementally from the connected directory instead.
It is a good idea to synchronize user data from connected directories to the public
cn=users container within an Oracle Internet Directory Identity Management realm. This way, all users are immediately accessible to OracleAS Single Sign-On and Oracle Delegated Administration Services, such as the Self-Service Console.Synchronize the nickname attribute from the connected directory or derived from some attribute that is unique in the connected directory, so that the user can use this identifier with OracleAS Single Sign-On.Since the
Last Successful Execution Time connector needs appropriate privilege to read and write to the cn=users container under the Identity Management Realm, add the profile distinguished name (DN) to the groups
DASDeleteUserGroup for that realm.
Rather than creating users and assigning them to groups as separate steps, consider incorporating the group assignment step during user creation. To do this:
Log in to the Oracle Internet Directory Self-Service Console as a Oracle Delegated Administration Services privileged user (
orcladmin or designate).
Select the Configuration tab.
Select User Entry > Add Role.
Search for and select any commonly-subscribed group entries.
Now, whenever you or any other Oracle Delegated Administration Services privileged user performs a Create User sequence, the list of specified groups will appear in the next-to-last step, in a section called Roles Assignment. Simply click whichever checkboxes are relevant to the newly-created user, and that user will automatically be made a member of all the groups you specify.
In Oracle Application Server, you no longer need to run
oidctl to start and stop Oracle Internet Directory processes. OPMN stores the proper sequences and controls these services.
Prior to configuring Windows Native Authentication, be sure to first configure the Active Directory Connector and bootstrap the appropriate
cn=groups containers within your desired Oracle Identity Management Realm. Do not configure the External Authentication Plug-in for Active Directory if your goal is to enable Windows Native Authentication
Users that forget their OracleAS Single Sign-On passwords can reset them on their own by using the Oracle Internet Directory Self-Service Console. You must authenticate yourself in one of the following ways:
If, while previously changing their password, a user specified a password hint question, then the Confirm Additional Personal Information window will prompt the user for the correct answer to the reminder question when attempting a password reset.
Users who have not previously set a password hint will be presented with the Confirm Additional Personal Information window. This window prompts the user for other personal data, as configured by your administrator.