| Oracle® Application Server Best Practices Guide 10g (10.1.4.0.1) Part Number B31762-02 |
|
|
View PDF |
| Oracle® Application Server Best Practices Guide 10g (10.1.4.0.1) Part Number B31762-02 |
|
|
View PDF |
This chapter describes best practices for Oracle Access Manager. It contains the following topics:
This section describes general best practices for Oracle Access Manager. It includes the following topics:
Section 2.1.5, "Use LDAP Over SSL Rather than ADSI When Connecting to Microsoft Active Directory"
Section 2.1.7, "Size and Tune the Environment to Support Production Deployment"
Section 2.1.8, "Host Administration Interfaces on Dedicated Web Servers to Protect the Environment"
Section 2.1.9, "Use SSL Transport between Components to Secure the Environment"
Section 2.1.10, "Store Audit Trails in a Database to Maximize the Usability of Audit Data"
Section 2.1.11, "Take Steps to Simplify Management of Your Environment"
Typically, an Oracle Access Manager deployment includes at least four distinct environments:
Development: This is the environment where you perform initial development and configuration, including applying new patches or versions of the software
Integration: This is usually a controlled environment where application integration is tested and verified.
QA (or Pre-Production): This environment should closely resemble production in performance and in failover and redundancy characteristics. You should use this environment to test behaviors that you expect in production or to reproduce production issues when troubleshooting.
Production
Keep the environments distinct to minimize service disruptions in production during rollouts and upgrades. It is a best practice to keep all of the environments at exactly the same patch level of the Oracle Access Manager software to avoid discrepancies and minimize the risk of finding difference in behavior across environments.
Implementation Details
See Also:
Chapter 1, "Capacity Planning," in the Oracle Access Manager Deployment GuideOracle recommends running Oracle Access Manager Access and Identity Servers on independent, dedicated hardware. For example, a typical Oracle Access Manager deployment for up to 15,000 users includes four servers, two running Identity Servers and two running Access Servers. Deploy IP switching technology in front of each pair of Web servers to provide load balancing and failover.
Implementation Details
See Also:
Chapter 1, "Capacity Planning," in the Oracle Access Manager Deployment GuideIf feasible, store the Oracle Access Manager configuration and policy data in a separate directory from the user and group data. This will allow for greater flexibility during upgrade and minimize the impact on the user and group directory. The user and group directory is typically a shared, enterprise directory, so separating the data this will be particularly beneficial when workflow-driven processes generate significant load on the directory. Configuring separate logical directory instances will also ensure that each directory can be tuned and managed independently, improving overall performance.
If directories cannot be separated due to hardware or topology related issues, at minimum you should create a dedicated suffix to hold the Oracle Access Manager configuration and policy data.
Implementation Details
See Also:
Chapter 2, "Performance Tuning," in the Oracle Access Manager Deployment GuideWhen deploying in a Microsoft Active Directory environment, always point directly to a domain controller to avoid potential data inconsistency problems
When using Microsoft Active Directory as the user and group directory, ensure that you point directly to the domain controller and not to the DNS alias. This will avoid problems that are caused by transient inconsistencies. For example, this practice avoids the possibility of dynamic DNS or round robin aliasing diverting connections to servers that are slow, remote, or contain out-of-date data. To implement high availability in an Active Directory environment, configure each of the domain controllers as a directory connection, and then tune the performance for reads and writes from Oracle Access Manager.
This recommendation also applies to Active Directory forests that contain multiple sub-domains. For this you should create separate directory profiles for each sub-domain in addition to the root domain, with each sub-domain pointing at the appropriate domain controller server or servers.
Implementation Details
See Also:
Appendix A, "Deploying with Active Directory," in the Oracle Access Manager Identity and Common Administration GuideWhen deploying Oracle Access Manager on Windows against Microsoft Active Directory, it is important to consider whether using LDAP over SSL is more appropriate than ADSI, as LDAP over SSL typically performs and scales better than ADSI, particularly in environments with high transaction volume. Also, using LDAP over SSL allows Oracle Access Manager (Access Server, Identity Servers, and Policy Manager) to rely on specified Active Directory instances. In contrast, when using ADSI, the specific Active Directory instance that Oracle Access Manager connects to is determined on-the-fly. This instance select may be undesirable if the overall response and performance across all available Active Directory domain controllers varies significantly.
Implementation Details
See Also:
Appendix A, "Deploying with Active Directory," in the Oracle Access Manager Identity and Common Administration GuideWhen deploying in a Microsoft Active Directory environment, it is important that the configuration parameters in Active Directory be set appropriately, so that Oracle Access Manager's overall performance is optimized. Table 2-1 lists the most relevant Active Directory configuration parameters.
Table 2-1 Active Directory Configuration Parameters
| Active Directory Configuration Parameter | Description | Default Value | Impact for Oracle Access Manager |
|---|---|---|---|
|
Specify the maximum number of concurrent LDAP search operations that are permitted to run at the same time on a domain controller. When this limit is reached, the LDAP server returns a "busy" error. Note: This control has an incorrect interaction with the |
20 |
This value should be greater than the total number of service threads in Oracle Access Manager, for all service threads to be able to perform search operations at the same time. The total number of service threads in Oracle Access Manager is the summation of number of threads in Identity and Access servers and the number of threads in the Web server hosting the Policy Manager. |
|
|
Specify the maximum number of simultaneous LDAP connections that a domain controller will accept. If a connection comes in after the domain controller reaches this limit, the domain controller drops another connection. |
5000 |
This value should be greater than or equal to the number of connections that Oracle Access Manager establishes with any Active Directory domain controller. |
|
|
Specify the maximum time, in seconds, that the client can be idle before the LDAP server closes the connection. If a connection is idle for more than this time, the LDAP server returns an LDAP disconnect notification. |
900 seconds |
If the maximum session time is set in Oracle Access Manager, then this value should not slightly higher than it. |
|
|
Specify the value for controlling the maximum number of objects that are returned in a single search result, independent of how large each returned object is. To perform a search where the result might exceed this number of objects, the client must specify the paged search control. This is to group the returned results in groups that are no larger than the |
1,000 |
This value should be greater than the number of entries returned in any search request made by any Oracle Access Manager component. Oracle Access Manager component performs search operations for the following two cases:
If blank, the search is allowed (in general, any search that results in all user entries in the system), then this value should be greater than the number of users in the system. If in general this kind of user searches are restricted or no one does these kinds of requests, then this value should be greater than the highest number of nodes under the following two nodes in Oracle Access Manager's configuration data:
|
|
|
The maximum number of threads- per-processor that a domain controller dedicates to listening for network input or output. This value also determines the maximum number of threads per-processor that can work on LDAP requests at the same time. |
4 threads per-processor |
If the Identity or Access Server run a single processor server, then this value should be greater than the number of connections established by Oracle Access Manager. This way, the domain controller can perform all operations in parallel. |
|
|
The maximum time in seconds that a domain controller will spend on a single search. When this limit is reached, the domain controller returns a |
120 seconds |
This value should be greater than the time limit value specified in database instance of the directory profile, which points to this domain controller. Otherwise, before the time limit specified in database instance itself is reached, Oracle Access Manager may get a |
Implementation Details
See Also:
Appendix A, "Deploying with Active Directory," in the Oracle Access Manager Identity and Common Administration GuideYou should run a thorough, extended load test and benchmark analysis before deploying Oracle Access Manager into production. This will allow you to fine tune and predict the behavior of the overall system.
Based on the performance figures, you can tune performance, for example, by altering cache settings, timeout values, the number of directory connections, and increasing the number of threads on the Identity or Access Servers.
Implementation Details
See Also:
Chapter 2, "Performance Tuning," in the Oracle Access Manager Deployment Guide for details on how to set these parameters based on performance resultsIt is a best practice to dedicate one or two internal-facing, highly-secured Web servers to host the administrative interfaces for Oracle Access Manager. The administrative interfaces consist of the Identity System Console and the Access System Console. This will help protect the authentication and authorization system in the event the application Web servers are compromised.
Implementation Details
See Also:
Chapter 1, "Capacity Planning," in the Oracle Access Manager Deployment GuideIn any production environment, you should secure all transport between Oracle Access Manager components with SSL encryption transport, using either Simple or Certificate Mode. All intranet and extranet communications should be encrypted.
When enabling SSL with Simple or Certificate mode, ensure that the clocks of the servers hosting the WebGates, AccessGates, and WebPass as well as those hosting the Access or Identity Servers are within 1 minute of absolute time difference. This includes ensuring that daylight savings and time zones have no more than a 1-minute difference between the clocks in GMT. Oracle recommends that you use the Network Time Protocol (NTP) for ensuring server clocks are synchronized.
Implementation Details
See Also:
Chapter 8, "Changing Transport Security Modes," in the Oracle Access Manager Identity and Common Administration GuideWhen possible, use a database for recording and storing all Oracle Access Manager audit data. This protects the audit information and makes it easier to generate audit trails and reports.
Implementation Details
See Also:
Chapter 10, "Logging," in the Oracle Access Manager Identity and Common Administration GuideYou can take a number of steps to simplify management of your Oracle Access Manager environment:
Standardize the layout of the file system in all your environments. For example, locate all Oracle Access Manager-specific files in the same directory path across all environments.
When feasible, use the same versions of the Web server and directory server across all environments.
Create a /custom directory and store all custom code in it. The /custom directory should not be in the installation directory of the Oracle Access Manager component. It is important to keep it separate because during re-installation or de-installation of Oracle Access Manager components, all subdirectories are deleted.
Most importantly, document any changes or customizations to the environment.
Implementation Details
See Also:
Chapter 1, "Upgrade Overview and Planning," in the Oracle Access Manager Upgrade GuideThis section describes Access System best practices. It includes the following topics:
Section 2.2.2, "Avoid Using Nested Groups for Authorization to Improve Group Membership Performance"
Section 2.2.4, "Performance Considerations when Using ObMyGroups"
Section 2.2.5, "Consider Deploying WebGates On Reverse Proxies to Simplify Management"
Section 2.2.6, "Design Document Protection Policies to Minimize WebGate Calls to the Access Server"
Section 2.2.7, "Use Best Practices When Configuring Form-based Authentication to Avoid Login Errors"
Section 2.2.8, "Code API-Based Plug-ins to Avoid Access Server crashes"
Section 2.2.9, "Use Best Practices to Secure Access Manager SDK (AccessGate) Clients"
Oracle recommends that you always enable IP validation to mitigate the risk of a cookie reply attack. If exceptions are required, for example, when deploying using a reverse proxy topology, ensure that only allowed IP addresses are included in the exception list. Avoid ever turning off IP validation.
To avoid the risk of cookie reply attacks, you can also deploy content securely over HTTPS. This prevents unauthorized clients from eavesdropping on the ObSSOCookie. Also, specify the parameter ssoCookie:secure for the Challenge Parameter for a Form, Basic, or External challenge method to ensure that the ObSSOCookie set during authentication is sent only through SSL. This prevents the ObSSOCookie from being sent back to a non-secure Web server. This parameter setting requires configuring all protected Web servers for SSL. An SSL Web server will not perform single sign-on with a non-SSL Web server. A browser will not return a secure cookie obtained from an SSL Web server to a non-SSL Web server in the same domain.
Implementation Details
See Also:
Chapter 5, "Configuring User Authentication," in the Oracle Access Manager Access Administration GuideAvoid using nested groups for authorization to improve group membership performance
By default, Access Server checks for static, dynamic and nested group memberships to determine authorizations. Evaluation of nested group memberships is extremely expensive to evaluate. If you are not using nested groups, disabling the nested group membership check will improve performance. You can disable the nested group membership check by setting the TurnOffNestedGroupEvaluation parameter manually to True in the globalparams.xml file.
Implementation Details
See Also:
Chapter 2, "Performance Tuning," in the Oracle Access Manager Deployment GuideGenerally, you should use dynamic groups instead of authorization filters to specify authorization rules. Dynamic groups allow you to separate the management of the filter ("Who is a virtual member of the group?") from the management of the authorization rule. This enables you to delegate the management of the authorized role to a class of administrators that is separate from those who configure the access policies. Additionally, group management allows tracking of changes and approvals for changes, whereas Authorization rule filters do not.
Implementation Details
See Also:
Chapter 5, "Configure User Authentication," in the Oracle Access Manager Access Administration GuideThere are several situations where the use of the special obmygroups action value proves to be a powerful approach for further integrating the Access System with applications to provide role-based information for the logged in user, in particular when the application needs to know which groups the particular user belongs to as this determined which menu items or functions would be presented.
Using ObMyGroups as an authentication or authorization action requires consideration of performance implications that resolving user group membership could have in the system for the LDAP directory and Access Server, and consequentially the Web server and application being accessed.
In general the user/group evaluation is an expensive operation from an Access Server perspective. Oracle strongly recommends that these always be configured with a qualifying LDAP filter. For example, enter obmygroups:ldap:///o=company,c=us??sub?(group_type=role).
Depending on the number of groups being searched, ObMyGroups processing may take a significant amount of time. It is best to specify obmygroups in an authentication rule rather than an authorization action and, if possible, have the action be a cookie so that the data is available to other applications under the same Web server without incurring an additional toll. And when ObMyGroups is used in an authorization rule, limit its use to as few resources (URLs) as practical.
Oracle strongly recommends that a thorough performance test, with the specific use cases relevant to ObMyGroups actions, be designed and executed prior to rollout. This allows you to benchmark, tune, and understand the actual performance and response times involved in your specific environment.
Implementation Details
See Also:
Chapter 5, "Configure User Authentication," in the Oracle Access Manager Access Administration Guide
Chapter 2, "Performance Tuning," in the Oracle Access Manager Deployment Guide
Consider deploying WebGates on reverse proxies to simplify management
There are a number of benefits to deploying WebGates on reverse proxies. These include:
You can protect all Web content from a single logical component by directing all requests through the proxy. This is true even for platforms that are not supported by Oracle Access Manager. If you have different types of Web servers, for example, iPlanet, Apache, and so on, on different platforms, for example, MacOS, Solaris x86, mainframe and so on, all content on these servers can be protected. A reverse proxy can be a workaround for unsupported Web servers, eliminating the need to write custom AccessGates for unsupported Web servers or for platforms where there is no AccessGate support.
You can install a WebGate on only the reverse proxy, rather than on every Web server. This creates a single management point. You can manage the security of all of the Web servers through the reverse proxy without establishing a footprint on the other Web servers.
A reverse proxy provides architectural flexibility. Reverse proxies can enable you to expose the same application on the intranet and the extranet without requiring any changes to the application already deployed.
The main pitfall of using a proxy is the extra work involved in setup. If you deploy the WebGate on a Web server that resides behind a reverse proxy, the following are required:
Ensure that any Web server that uses the reverse proxy for authentication only accept requests from the reverse proxies. You must configure the WebGate deployed on this Web server to not enforce IP validation on requests coming from the reverse proxy server or servers acting as its front end. You must configure the IP addresses of the reverse proxy server or servers in the IP Validation list for the WebGate. Oracle does not recommend turning IP validation off for the WebGate because it can expose a security risk.
Update the virtual hosts that are configured in the Policy Manager so that the Access System intercepts requests that are sent to the reverse proxy.
Prevent people from circumventing the proxy by entering URLs that point directly to the back-end system. You can add Access Control List (ACL) statements in the server to prevent users from bypassing the reverse proxy and directly accessing restricted content. Or, you can configure firewall filters.
Since the proxy processes all user requests, you must deploy enough proxy servers to enable the system to handle the load.
Redirect all existing URLs to the host name and port number of the reverse proxy server. This often requires configuring the reverse proxy to inspect content and rewrite URLs, for example, to prevent any absolute HTML links from resulting in a broken link. This is available in most reverse proxies, and it is functionality that is independent of the Access System. It is a best practice that you configure URL links exposed to the front-ended applications to contain only relative URLs (../../sub-path/resource) rather than absolute URLs (http://hostname.domain:port/path/resource) or pseudo-relative URLs (that is, /path/resource). Absolute URLs can break links on the end user's browser when deployed behind a reverse proxy.
Implementation Details
See Also:
Chapter 3, "Configuring WebGates and Access Servers," in the Oracle Access Manager Access Administration GuideFor example, when specifying policies to protect all the documents on a Web server, there are two approaches that will work:
Protecting all the documents from the root of the document tree, and specifically allowing access to specified documents
Setting the DenyOnNotProtected flag, and specifically allowing access to specified documents
In general, the second approach will provide better performance. When protecting Web documents from the root, the WebGate will always need to contact the Access Server for each request to check if the user is authorized to access the resource. This will place additional load on the Access Server. When using the DenyOnNotProtected flag, the WebGate caches information from Access Server on whether a particular URL is protected by the Access System. As a result, it can simply deny access to subsequent requests for unprotected resources without contacting the Access Server thereby reducing server overhead.
Implementation Details
See Also:
Chapter 3, "Configuring WebGates and Access Servers," in the Oracle Access Manager Identity and Common Administration GuideWhen implementing form-based authentication with Oracle Access Manager, develop code in such a way as to avoid login errors. This includes embedding code to validate input fields in the form to avoid posting the wrong credentials. For example, you can check that user name and password fields are not blank. In addition, use HTML code that prevents content caching, for example:
<meta http-equiv="pragma" content="no-cache">
Implementation Details
See Also:
Appendix A, "Form-Based Authentication," in the Oracle Access Manager Access Administration GuideThe following guidelines can reduce the risk of introducing instability to the Access Server:
Since the Access Server is multithreaded, you should ensure that any API-based plug-ins that are deployed on the Access Server are thread-safe.
Ensure that all authorization and authentication API plug-ins are persistent, and improve performance by implementing connection pooling and caching.
Initialize all global and local variables used in the plug-in functions.
Oracle recommends that all authorization and authentication plug-ins take input parameters from the Access Server in order to specify configuration information.
Implementation Details
See Also:
Chapter 6, "Customizing Access Control with Plug-Ins," in the Oracle Access Manager Customization GuideThe configuration of Access API clients includes a secret password between the Access Server and the AccessGate configuration to prevent invalid clients from connecting to the Access Server. To protect these passwords, you should implement SSL to encrypt the communication between the Access Server and the Access API clients. In addition, treat the single sign-on token (typically the content of the ObSSOCookie) as a password, and do not provide it to external applications.
Implementation Details
See Also:
Chapter 6, "Customizing Access Control with Plug-Ins" in the Oracle Access Manager Customization GuideThis section describes Identity System best practices. It includes the following topics:
Section 2.3.1, "Avoid Searches to Improve Identity Administration Performance"
Section 2.3.4, "Turn Off Tracking to Improve Workflow Performance"
Section 2.3.5, "Periodically Clean Up Workflow Tickets to Improve Directory Performance"
Section 2.3.9, "Always Work from a Copy of The Default Style Sheet"
Section 2.3.10, "Use Caution When Implementing Javascript Code in PresentationXML"
When possible, keep search bases to a minimum. Instead, apply ACLs to the class attribute of the user object. This is known to improve performance. Also, avoid configuring search bases using substitution syntax, as this is known to adversely affect performance. Avoid search bases or ACLs that contain substring searches, for example "...(...=*something*)...". And avoid setting several search bases for each User, Group, or Org object class.
Implementation Details
See Also:
Chapter 3, "Making Schema Data Available to the Identity System," in the Oracle Access Manager Identity and Common Administration GuideFor group management use the Manage Members page. This page optimizes the management of large groups (defined as static groups with 1000 or more members), as opposed to defining the member semantic attribute as part of the group profile page. This will significantly improve performance when managing large groups.
Implementation Details
See Also:
Chapter 4, "Configuring User, Group, and Organization Manager," in the Oracle Access Manager Identity and Common Administration GuideIn general, Oracle Access Manager's timeout values should be configured to be the lowest of all application timeouts. Timeouts are enforced by WebGate or the Web server and not by application. The goal, therefore, is to avoid applications from timing out before Oracle Access Manager and thus having to potentially handle session issues within the applications.
In general, there are a number of considerations in selecting timeout values. For example, applications which are able to regenerate a session from an existing Oracle Access Manager session (or header variable) can timeout earlier than Oracle Access Manager. Oracle Access Manager's Identity System, in fact, is a good example of an application where having a shorter session timeouts than WebGates is recommended. In general, however, these timeout values should be close to each other.
One exception to this rule is for AccessGates, which are typically deployed downstream from a WebGate, for example supporting a BEA WebLogic implementation. In this case it is recommended that the AccessGate have a greater idle timeout than the WebGate to avoid the problem of a fresh browser session being rejected by the downstream AccessGate. For AccessGates, Oracle recommends configuring the idle and maximum timeouts to be the same.
Implementation Details
See Also:
Chapter 3, "Configuring WebGates and Access Servers," in the Oracle Access Manager Access Administration GuideIf workflows do not require any other input or approval steps, it is a good idea to enable the WfInstanceNotRequired parameter. This parameter prevents the generation and storage of workflow tracking data that can generate overhead for the directory server.
Implementation Details
To change this parameter:
Set the WFInstanceNotRequired flag to true in the following file:
install-path/identity/oblix/data/common/workflowdbparams.xml
Restart the Identity Server.
See Also:
Chapter 2, "Performance Tuning," in the Oracle Access Manager Deployment GuideMonitor the number of workflow tickets that are stored in the directory server, and periodically delete old tickets manually or using a script-based utility.
Implementation Details
See Also:
Chapter 2, "Performance Tuning," in the Oracle Access Manager Deployment GuideAvoid EXEC-type plug-ins, which spawn external processes. If you want an Identity Event API plug-in to trigger other events in the Identity Server using IdentityXML, ensure that the request goes to an Identity Server instance other than the one triggering the Event API plug-in. This practice balances the system load. Also, Event API plug-ins using C/C++ as shared objects (.so files) for performance and stability reasons.
The following are other best practices to apply in the development of Identity Event API plug-ins:
All Identity Event API plug-ins must be thread-safe.
Identity Event API plug-ins are not persistent, so you must initialize all global and local variables used in the plug-in functions.
Use a single library for multiple Event API plug-in functions to minimize runtime image size.
The plug-in should support using a configuration file to alter and adapt its operation in case of requirement changes.
Implementation Details
See Also:
Chapter 3, "Identity Event Plug-in API," in the Oracle Access Manager Developer GuideOracle Access Manager Identity combines Extensible Style Language (XSL) stylesheets and Extensible Markup Language (XML) data to dynamically create almost all of the pages presented to its users. This capability, known as PresentationXML, provides developers with design flexibility and avoids the need for static HTML content.
PresentationXML is the recommended approach if your intent is to deal with front-end, user interface issues, for example, look and feel, layout of the tags, enhancing the navigation, and so on. It is not recommended for back-end logic, for example, pre-filling values based on data on a database, computing values based on other input values, communicating with external systems, and so on.
Implementation Details
See Also:
Chapter 2, "Designing the GUI with PresentationXML," in the Oracle Access Manager Customization GuideTo expedite development and testing, use a powerful XML or XSL editor, for example, XMLSpy. These editors provide an integrated development environment (IDE) to simplify and speed up the process of XSL programming.
Implementation Details
See Also:
Section "Setting Up Your Environment to Customize the Style Sheets" in Chapter 2, "Designing the GUI with PresentationXML," of the Oracle Access Manager Customization GuideBefore modifying or using a style sheet, create a new style based on the default (style0) style of Oracle Access Manager. Replicate all related graphics, stylesheets and Javascripts in the Identity Server and WebPass so that the default style remains unchanged.
Implementation Details
See Also:
Chapter 2, "Designing the GUI with PresentationXML," in the Oracle Access Manager Customization GuideWhen the need arises to insert JavaScript code to a front-end page through PresentationXML, the best practice is to encapsulate all of the JavaScript code into a file, then include the file in the XSL file. At deployment time, you must deploy this file on the appropriate WebPass installation directory.
When including JavaScript code in PresentationXML, do not modify the main misc.js file in the WebPass installation directory. This file is used for client-side processing and is common to all Oracle Access Manager components. Any modification can adversely affect all components.
See Also:
Chapter 2, "Designing the GUI with PresentationXML," in the Oracle Access Manager Customization Guide