| Oracle® Access Manager Deployment Guide 10g (10.1.4.2.0) Part Number E10353-01 |
|
|
View PDF |
| Oracle® Access Manager Deployment Guide 10g (10.1.4.2.0) Part Number E10353-01 |
|
|
View PDF |
Once you have installed and configured Oracle Access Manager, you want to be sure to get the best possible performance out of the product.
This chapter provides information for experienced Oracle Access Manager administrators on how to optimize Oracle Access Manager performance. This chapter includes the following topics:
For general deployment recommendations, see Chapter 1. For details about Policy Manager tuning factors for Apache Web servers, see the Oracle Access Manager Installation Guide.
Oracle Access Manager stores its data in a Lightweight Directory Access Protocol (LDAP) directory. When diagnosing problems that appear to be due to Oracle Access Manager, you may want to check the performance of the directory. Additionally, many performance issues can be resolved by avoiding trips to the directory, especially for write operations.
The following sections discuss these topics:
Changing the Number of Access Server-to-Directory Server Connections
Increasing Connections to the Directory in the Identity System
If directory performance is slow, it will affect the performance of the Access Server or Identity Server. See your directory vendor's documentation for details. For Oracle Internet Directory, see the chapter on performance optimization in the Oracle Internet Directory Administrator's Guide for details.
The Identity Server and the Access Server open a configurable number of connections to LDAP servers. If you perform a large number of time-consuming searches of user profiles, you can increase the database connection pool size to improve performance.
You configure the connection pool size in the Identity System Console or Access System Console. You specify the details for connections used for accessing configuration data and policy data in configuration files, not through the System Console. At startup, a number of connections are opened based on an Initial Connections setting. As needed, more connections are opened until the Maximum Connections setting is reached. Connections remain open until the Identity or Access Server shuts down or the directory server stops responding.
The number of connections that the Identity or Access Server opens to the directory is different from the number of connections that you specify in the Identity System Console or Access System Console. This is because certain connection details are picked up from configuration files. Connections are specified in the following files:
Connections for accessing configuration data: Three database configuration files reside in Oracle_Access_Manager_install_dir/oblix/config/ldap. The setting for the number of connections applies to each of the configuration files. The default value is 1, which means at any time at least three connections are open.
Connections for accessing policy information: Four locator files are used to manage policy definitions. These locators reside in Identity_Server_install_dir/oblix/config/ldap. The setting for the number of connections to be opened is on a per-locator-file basis. The default value is 1, which means at any time at least four connections are open.
Connections for database profiles that are created during setup: During product setup, Oracle Access Manager automatically creates one or two database profiles, depending on if the configuration base and search base are the same or disjoint. Each database profile has one instance and the number of connections is set to 1. If the database profile supports authentication operations, a separate connection pool is used for authentication operations. For example, if a database profile has one database instance and the number of connections is set to 1, two connections may be opened—one for authentication and one for other LDAP operations.
To illustrate the difference between the configured and actual number of connections, suppose that you have performed product setup without configuring disjoint domains. In this case, nine connections are opened by default:
One each, for a total of three, for the configuration data.
One each, for a total of four, for policy data
One each, for a total of two, for a database profile with one database instance and one configured connection.
As another example, suppose that you configure two database profiles, each with one database instance and an Initial Connections setting of three, and a Maximum Connections setting of five. All database instances apply to the same directory, and configuration and user data are stored in the same directory. Authentication operations are supported. In this example, the minimum connections opened to the directory is 19, as follows:
One each, for a total of three, for configuration data.
One each, for a total of four, for policy data
Three each, for a total of twelve, applies to the two database profiles.
Each database profile will have six connections, since there will be two connection pools with three connections each. There will be one pool for authentication requests and another for other operations.
In this scenario, if you set the maximum number of connections to 27, the number of connections to the directory will range from 19 to 27.
The following procedure explains how to configure the number of LDAP connections.
To increase the connection pool size for user data
Navigate to Identity System Console, System Configuration, Directory Profiles.
Click the name of a user data directory server instance in the Configure LDAP Directory Server Profiles list on the Configure Profiles page.
Click the name of a directory server instance in the Database Instances list of the Modify Directory Server Profiles page.
On the Modify Database Instance page, modify the two parameters below:
Maximum Connections: Increases the number of available connections in the pool. The default value is 1. No upper limit is enforced; you can experiment with this setting to find a suitable value.
Initial Connections: Specifies how many connections are opened at database initialization. The default value is 1. There is no upper limit.
As described in the Oracle Access Manager Identity and Common Administration Guide, by default each workflow step generates a ticket and Oracle Access Manager writes the ticket to the directory.
One way to avoid unnecessary directory write operations is to minimize the number of steps in a workflow. Another way to avoid unnecessary directory write operations is to change Oracle Access Manager default behavior of creating tickets for every step in a workflow.
Tickets are of little value when:
The information in a step has little value for the next step.
A participant triggers the workflow but there are no participants for other steps.
Oracle recommends that you monitor the number of workflow tickets that are stored in the directory server, and periodically delete old tickets manually or using a script-based utility.
Workflow Example
Suppose you create a workflow consisting of the following steps:
Initiate: The user initiates a self-registration.
External action: The request is passed to an external process.
Enable: The workflow is enabled.
If no one participates in steps 2 and 3, the workflow may not require a ticket.
The WFInstanceNotRequired flag determines whether every workflow step generates a ticket. This flag is set to false by default, which means all workflow instances are written to the directory. When set to true, workflow instances are only written to the directory server when:
A user action is required.
Any errors are encountered (for example, the commit action fails).
Any subflows are triggered.
If workflows do not require any other input or approval steps, it is a good idea to set the WFInstanceNotRequired flag to true.enable Setting the WFInstanceNotRequired flag to true reduces the directory size and speeds up the workflow process. This parameter prevents the generation and storage of workflow tracking data that can generate overhead for the directory server. The disadvantage of setting this flag to true is that, because the instances are not being stored, you will not able to see all of the workflows that were executed from the Oracle Access Manager Workflow Monitor.
To avoid creating tickets for every workflow step
Set the WFInstanceNotRequired flag to true in the following file:
IdentityServer_install_dir/identity/oblix/data/common/workflowdbparams.xml
Restart the Identity Server.
For more information, see the chapter on configuring the User, Group, and Organization Manager in theOracle Access Manager Identity and Common Administration Guide.
Indexing improves search performance in the directory, although at the cost of slower database modification and creation operations and disk space. Oracle Access Manager automatically indexes key attributes when you run the setup program. The index files are specific to your directory server type, and are stored in:
IdentityServer_install_dir/identity/oblix/data/common
where IdentityServer_install_dir is the directory where the Identity Server is installed.
Index types include the following:
An equality index improves searches for directory entries that contain a specific attribute value.
A presence index improves searches for directory entries that contain a specific attribute.
A substring index improves searches for entries that contain specific text strings.
You can enhance performance if you index attributes that are read during various operations. These include:
Attributes used in searches that are triggered indirectly by user interaction.
Attributes used in searches that are explicitly invoked by users.
Attributes used in mapping filters for authentication schemes.
Attributes in filters for dynamic member definitions in Group Manager.
Your directory documentation describes how to index attributes.
Oracle Access Manager provides an index file fragment showing how Oracle Access Manager-specific attributes can be indexed for each supported directory server. For example, the Oracle Access Manager attributes that can be indexed to improve performance in a directory managed by Sun (formerly iPlanet) directory server are listed in the file:
IdentityServer_install_dir/identity/oblix/data/common/iPlanet5_oblix_index_add.ldif
An example of an index entry in this file is:
index obclass pres,eq,sub
This means that the attribute obclass can be indexed for presence (pres), equality (eq), or substring (sub) .
Note:
The iPlanet5_oblix_index_add.ldif file needs to be loaded to the directory server using ldapmodify.Carefully weigh the benefits of indexing directory attributes for search operations against the performance hit incurred when these attributes are modified. When an attribute value is modified, indexes for that attribute may need to be rebuilt by the directory server. However, this is accomplished varies by directory server.
Be sure to read the manufacturer's guidelines for indexing. Avoid over-indexing attributes.
After you deactivate a significant number of users, Oracle Access Manager performance can start to degrade. If you experience this problem but want to maintain all deactivated users in the directory, use an equality index for the following attributes:
ObIndirectManager
ObUniqueMemberstr
An equality index allows you to search efficiently for entries containing a specific attribute value.
If it takes a long time to delete a workflow, index any attributes that the system checks during a delete operation. Performance issues with the delete workflow function usually result from attributes that need to be indexed.
Index the following attributes using the types of equality, presence, and substring:
ObWorkflowID
ObContainerID
ObWFStepID
ObWFTargetID
ObIsWorkflowProvisioned
ObLocationDN
OblixGID
Manager
Secretary
An equality index type improves searches for directory entries that contain a specific attribute value. A presence index type improves searches for entries that contain a specific attribute. A substring index type improves searches for entries that contain specific strings.
For example, if you search for an attribute with a substring index type as follows:
cn=*lane
The search would match common names containing these strings:
John Lane Jane Tulane
If you conducted this search:
telephonenumber= *123*
The search would return all entries with telephone numbers that contain 123.
The following attributes are used for group expansion and could be indexed to improve performance:
Any attribute configured with the obSDynamicMember semantic type
The obGroupExpandedDynamic attribute of the oblixAdvancedGroup object class
All user attributes used in the dynamic filters of the groups to be expanded.
You can limit the performance impact of searches by forcing users to use a minimum number of characters for a search. This is controlled through the searchStringMinimumLength parameter. The default value for this parameter is 0.
To set a minimum number of search characters
Locate seachStringMinimumLength in:
IdentityServer_install_dir/identity/oblix/apps/common/bin/ oblixappparams.xml
Set its value to the minimum number of characters for a search.
For instance, if you set it to 6, users could not search for "Smith" because it has only 5 characters. The constraint only applies to the longest search string supplied by the user. For example, if the search is on both surname and job title, and the user enters "manager" for job title, the longest string ("manager") has 7 characters, the search is allowed. A value of 0 turns off checking.
The searchStringMinimumLength constraint is enforced for searches that are conducted using the Oracle Access Manager user interface and for clients using other interfaces to Oracle Access Manager (for example, Identity XML clients).
To enforce a per-attribute minimum number of characters
Set the searchStringMinimumLength to 0 in the catalog.
In the JavaScript code, find the function validateSearchAndSubmit() in the file misc.js.
Modify the JavaScript code to handle the per-attribute checking you require.
Note:
This technique does not enforce the constraint on users of Identity XML clients.As with other parameters, you can set searchStringMinimumLength to one value in the global oblixappparams.xml catalog, and to a different value in one or more of the application-specific catalogs. For example, to override the global value and set searchStringMinimumLength to a different value for User Manager, specify the parameter and its value for User Manager only in:
IdentityServer_install_dir/identity/oblix/apps/userservcenter/bin/ userservcenterparams.xml
By default, each Access Server opens only one connection to a primary directory server and one connection to a failover directory server (if failover is configured). This may not be optimal for systems with heavy loads.
To configure additional Access Server-to-directory server connections for Oracle Access Manager configuration and policy data, use the command line tool configureAAAServer. The Oracle Access Manager Access Administration Guide provides information on this tool. In environments with very high loads (perhaps 1,000 hits/second on the Access Server), creating twenty connections has significantly improved performance.
Note:
If your directory is running on a low-powered system, the directory itself may be the limiting factor. In this case, increasing the number of connections may have little benefit. If the machine running the directory is the problem, increase the number of directory server instances and configure load balancing among them.To prevent the Oblix tree from getting too large, periodically delete or archive workflows. Deleting a workflow instance removes the directory entries associated with that instance. Archiving a workflow instance keeps a record of the instance in an LDIF file and deletes the instance from the directory.
The frequency for archiving or deleting depends on how frequently your workflows are used.
Archived workflows are stored in LDIF format. The default archive file is:
IdentityServer_install_dir/identity/oblix/data/common/wfinstance.ldif
Multiple archive operations add information to this file. You can change the archive file by changing entries in the following files:
User Manager
IdentityServer_install_dir/identity/oblix/apps/userservcenter/bin/usc_wf_params.xml
Group Manager
IdentityServer_install_dir/identity/oblix/apps/groupservcenter/gsc_wf_params.xml
Org Manager
IdentityServer_install_dir/identity/oblix/apps/objservcenter/osc_wf_params.xml
The entry to change is similar to the following:
<NameValPair ParamName="archiveFileName" Value="wfinstance.ldif"/>
To delete or archive a workflow
In User, Group, or Organization Manager, click Requests.
Click Monitor Requests.
For subflows, if the first step has not been processed, the Date Processed field will be empty.
In the Search fields, select your search criteria
Click Go.
The results appear below the search fields.
Click individual check boxes or the Select All button.
Click Next or Previous as necessary to see other results.
Click the Delete or the Archive button.
By default, administrators can view all attributes in the directory so that they can perform initial setup of Oracle Access Manager. Because end users only have read permissions for specific attributes, there is a difference in performance for an administrator and an end user.
The parameter BypassAccessControlForDirAdmin controls whether the Master Identity Administrator or a delegated administrator is permitted to view all attributes in the directory. By default, the value of the parameter BypassAccessControlForDirAdmin is set to true. You can set the BypassAccessControlForDirAdmin parameter to false in the following file:
IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xml
If the BypassAccessControlForDirAdmin flag is set to false, performance is the same for non-administrative and administrative users. This is because attribute read and write permissions are applied to the administrative users.
The following is an example of the parameter entry:
<SimpleList> <NameValPair ParamName="BypassAccessControlForDirAdmin" Value="true"> </NameValPair> </SimpleList>
Searchbase configuration can affect Oracle Access Manager performance. Guidelines for searchbase configuration include:
Set the searchbase for the user object class at a point in the people branch where all users can be found, for example, the root.
Minimize the number of searchbases that you configure per user, group, or organization object class.
It is more efficient to configure attribute access controls to the class attribute of the user object than it is to limit user access by setting multiple search bases.
Use the default searchbase filter objectclass=* whenever possible.
Instead of defining searchbase filters, configure read and write permissions for attributes.
Avoid configuring searchbases using substitution syntax.
Avoid search bases or ACLs that contain substring searches, for example "...(...=*something*)..."
Configure workflow rules and roles to control the user's ability to view and modify attribute values.
For more information, see the chapter on making schema data available to the Identity System in the Oracle Access Manager Identity and Common Administration Guide.
When configuring a searchbase, if you add a filter and enter a filter other than the default (objectclass=*), the Resource Filter Search scope takes effect. The Resource Filter Search scope has no effect unless you define a filter.
The default searchbase filter (objectclass=*) instructs Oracle Access Manager to apply the user's search criteria to the entire section of the directory tree that has been selected as the searchbase. If you specify other criteria, for example, (telephone=408*), Oracle Access Manager retrieves all users who satisfy that criteria, then applies your search criteria to the subset specified by the filter instead of to the entire tree.
This can degrade performance, especially if the filter retrieves a large number of entries. For example, if you specify (objectclass=wwmOrgPerson) in the filter, Oracle Access Manager may recover all users (assuming all users satisfy this filter) under the specified tree before applying your search criteria. This can seriously degrade performance. You do not have to specify (objectclass=wwmOrgPerson) because the searchbase is already set for that object class. In general, setting read and write privileges for attributes is a better way of controlling user access than setting a searchbase filter. To optimize directory performance, avoid defining complex filters for the searchbase. In the case of searchbases for a tab, only objects of the class which that tab applies to are searched. There is no need to mention (objectclass=*) explicitly.
If you must enter a filter, you can limit the performance impact by setting the resourceSearchFilter scope parameter to 1.
The larger the number of entries that a search actually or potentially returns, the longer the search takes. For an interactive application such as Oracle Access Manager, large result sets may be unmanageable for the end user.
Your directory may allow you to limit the time that the directory server spends on a search, the size of the result, or both.
The LDAP Database Instance Maximum Connections is the maximum number of connections allowed from the Identity Server to the directory servers. This value defaults to 1, but you may see a performance improvement by setting this value to more than 1. (With a SQL profile, the default is 5.)
There is no optimal value for the maximum connections. There are variables to consider such as directory configuration and hardware. You may want to consider setting the maximum directory connections no higher than the number of threads set for a Identity Server. For example, if the Identity Server is configured with only 20 threads, there is no benefit in having more than 20 connections because no Identity worker threads can take advantage of the additional connections.
You may want to increase the maximum connections by increments of 5, and monitor your system performance. If performance is worse, decrease the number of connections. The Initial Connections and the Maximum Connections settings work together. When an Identity Server starts, it opens the number of connections to the directory as specified in the Directory Profile Initial Connections. Those connections are then pooled and used by the Identity Server.
Note:
Additional connections can introduce overhead that in turn can hurt performance. For example, if you restart the directory server, the Identity Server has to reconnect the configured number of connections.This section describes modifications that can be made to the directory content to affect Oracle Access Manager operation. For a discussion of the tools needed to make these changes, see .
A search of the Policy Manager for policy domain names or policy names returns a default set of columns in a default order. You can display different columns or change the order of columns. While this does not affect performance in terms of response times, it may improve your satisfaction with the results returned from a search.
To modify results for a policy or policy domain name search
Locate the DN, for example:
obname=SDSearchColumnList, obapp=WRSC, o=Oblix, o=Company, c=US2
Under this DN, find the current column list.
The column list consists of the values for obsearchresultcolumns.
Possible values for a search of policy names are:
WRORname: Policy Name
AuthentPolicyName: Authentication Rule Name
AuthorPolicyName: Authorization Rule Name
AdminPolicyName: Auditing Rule Name
URLPrefix: URL for the domain controlled by the policy
Possible values for a search of policy domain names are:
SDName: Policy Domain Name
AuthentPolicyName: Authentication Rule Name
AuthorPolicyName: Authorization Rule Name
AdminPolicyName: Auditing Rule Name
AbsPathPattern: Path to the controlled domain
For example, the following is an LDIF extract that shows the policy name, authentication rule name, authorization rule name, and URL for the domain controlled by the policy:
dn: obname=SDSearchColumnList, obapp=WRSC, o=Oblix, o=Company, c=US objectclass: top objectclass: OblixWRSSearchResultColumns obname: SDSearchColumnList obSearchResultColumns: WRORName obSearchResultColumns: AuthentPolicyName obSearchResultColumns: AuthorPolicyName obSearchResultColumns: URLPrefix
To change the order or content of the displayed search results, modify this information and store it back to the directory.
Using Directory Manager as the bind DN bypasses search limits such as look through limit, size limit, and time limit. Large searches can tie up the directory server and increase the amount of processing that is required by the Identity Server.
You can create another user to use as a bind DN.
Note:
This procedure illustrates the technique for Sun (formerly Netscape and iPlanet) directories. Consult your directory server's administration manual for instructions on how to create a directory user with the appropriate permissions.Create your new user, for example orcladmin. Use the LDAP directory to give the user permissions to act as an administrator for Oracle Access Manager. For the searchbase, configuration base, and all branches underneath them, this user needs the following permissions:
Read
Write
Add
Delete
Search
Compare
Selfwrite
To change bind DN permissions
From the Sun LDAP Server Admin Console, navigate to the directory server instance and open it.
Choose the Directory tab, then locate and right-click the branch for which you want to set permissions.
For example:
for o=Company, c=US, you would find the Company node and right-click to get a menu.
Choose Set Access Permissions in the menu.
Add a new access permission, or edit the one already in place.
There should be two lines when you are done. The first is a default deny for everyone, the second is the allow statement.
Choose Allow, then search users and groups to find the new administrative user.
Set the rights for this user.
If you make this change after installing Oracle Access Manager, change the bind DN for the Identity Server to match the value you created in the directory.
Caching avoids the latency of unnecessary lookups or calculations. If they keep the results of recent requests close to the consumer, producers can respond quickly by returning cached results rather than recalculating them. The cost of a cache is usually extra RAM or disk space.
A directory that manages large entries will likely hit a maximum cache size limit first, while a directory of small entries might hit the maximum number of entries limit first. If you only care about one of these two criteria, set the other to an unrealistically large number, or match their limits by setting the maximum cache size first, then dividing that number by the size of each entry to get the number you should use for maximum entries in cache.
Every time a change is made to a user entry in Oracle Access Manager, a directory entry called ObSyncRecord is created. This directory entry enables the user cache for different Oracle Access Manager Servers to stay in sync. If many updates are made to user entries over a short time interval, the number of ObSyncRecord entries that are written can cause a directory performance issue.
You may want to delete ObSyncRecord entries at a regular interval. If you do this, you may want to check each entry before deleting it to ensure that the entry has been in the directory for a time period that is greater than the cache-flush interval.
The following performance tuning considerations apply to deployments that use Microsoft Active Directory:
Pointing Directly to a Domain Controller to Avoid Potential Data Inconsistency Problems
Using LDAP Over SSL Rather than ADSI to Connect to Microsoft Active Directory
Fine Tuning Appropriate Active Directory Configuration Parameters to Optimize Performance
For performance tuning recommendations, see Chapter 3. For details about installing Microsoft Active Directory with Oracle Access Manager, see the Oracle Access Manager Installation Guide. When configuring Microsoft Active Directory for Oracle Access Manager, see theOracle Access Manager Identity and Common Administration Guide.
When 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.
When 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.
When deploying Oracle Access Manager in a Microsoft Active Directory environment, it is important that the configuration parameters in Active Directory be set appropriately, so that overall Oracle Access Manager performance is optimized. Table 2-1 lists the most relevant Active Directory configuration parameters.
Table 3-1 Active Directory Configuration Parameters
| Active Directory Configuration Parameter | Description | Default Value | Impact for Oracle Access Manager |
|---|---|---|---|
|
MaxActiveQueries |
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 MaxPoolThreads value. MaxPoolThreads is a per-processor control, while MaxActiveQueries defines an absolute number. Starting with Windows Server 2003, MaxActiveQueries is no longer enforced. Additionally, MaxActiveQueries does not appear in the Windows Server 2003 version of Ntdsutil.exe. |
20 |
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. |
|
MaxConnections |
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. |
|
MaxConnIdleTime |
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. |
|
MaxPageSize |
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 MaxPageSize value. To summarize, MaxPageSize controls the number of objects that are returned in a single search result. |
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 configuration data:
|
|
MaxPoolThreads |
The maximum number of threadsper-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- process or |
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. |
Directory applications use LDAP as a standard tool to create, modify, and report data stored in the directory. Tools are available to allow easy manipulation of this data. This section introduces these tools. More detail is available from the manufacturer of your server application.
The structure of a directory, and the data contained within it, is represented by the content of an LDAP Data Interchange Format (LDIF) file. The file can be output, the formatted result of a request made to the directory by an LDAP reporting tool, such as LDAPSEARCH. It can also be input, data that is intended for insertion to the directory, either as entirely new data, or as an update to existing data, using an updating tool such as LDAPMODIFY.
The following is an example, part of an LDIF file taken from a Oracle Access Manager Demo Directory:
dn: cn=John Kramer, ou=Sales, o=Company, c=US objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: companyOrgPerson cn: John Kramer sn: Kramer telephonenumber: 415-555-5269 facsimiletelephonenumber: 415-333-1005 title: Account Manager departmentnumber: 1204 employeetype: Fulltime employeenumber: 521-321-4560 givenname: John . . Reporting Directory Content with LDAPSEARCH
LDAPSEARCH is one possible tool that can be used to report directory content. There are others, which use a different syntax, but the concepts are the same.
LDAPSEARCH can be used in either a command line or interactive mode. The command line approach is preferable, as it allows users to provide the text of the report request by means of a input file. It is easy to verify the content of this file before making the request. You can correct errors by changing a few characters in the file rather than retyping the full request, which would be necessary in the interactive mode.
The command-line format for LDAPSEARCH is:
ldapsearch params filter attr_list
Note:
Each of the three categories shown between <> is optional; if all are omitted, LDAPSEARCH drops into interactive mode, which is not discussed here.The categories are as follows:
<params>: Parameters tell LDAPSEARCH how to operate. One of them, -f, is used to specify a filter file. If instead the search filter is provided on the command line, all parameters must be stated before the filter is stated.
<filter>: The filter instructs LDAPSEARCH to provide a subset of the data that would otherwise be provided. For example, a filter could require that only names beginning with N be reported. A filter provided on the command line must be enclosed in quotes.
<attr_list>: The attributelist, if included on the command line, overrides the default attribute listing. The default list shows all attributes belonging to the directory entry, except operational attributes. If you wish to see only some of these attributes listed, provide their names in the command line, following the filter, and separated by spaces. If you want to see operational attributes, provide their names in the command line. If you follow the operational attributes with a * you get the default list of attributes as well.
Parameters are always provided in the form:
-p pdata
where p is the parameter, preceded by a dash, and pdata is the information (data) required for the parameter, if any. If the data contains one or more spaces, it must be enclosed in double quotes:
-p "pdata with spaces"
Following is a list of commonly used parameters. See the reference document for your version of LDAPSEARCH, or use the parameter /? to see them listed:
-A: Retrieve the attribute names only, not the attribute values.
-b: Searchbase, the starting point for the search. The value specified here must be a distinguished name that is in the directory. Data provided for this parameter MUST be in double quotation marks. For example:
-b "cn=Barbara Jensen, ou=Development, o=Oblix.com"
-D: Distinguished name of the server administrator, or other user authorized to search for entries. This parameter is optional if anonymous access is supported by your server. For example:
-D "uid=j.smith, o=Oblix.com"
-f: Specifies the file containing the search filters to be used in the search. For example:
-f filterfile
-h: Host name or IP address of the machine on which the directory server is installed. This entry is optional; if no host name is provided, LDAPSEARCH uses the local host. For example:-h myserver.com
-H: This generates a list of all possible LDAPSEARCH parameters.
-p: Port number that the directory server listens at. For example:
-p 1049
-s: Scope of the search. The data provided for the scope must be one of the following:
base: Search only the entry specified in the -b option.
one: Search only the immediate children of the entry specified in the -b parameter; do not search the actual entry specified in the -b parameter.
sub: Search the entry specified in the -b parameter, and all of its descendants. That is, perform a subtree search starting at the point identified in the -b parameter. This is the default, if the -s parameter is not used.
-S: Designates the attributes to use as sort criteria, controlling the order in which the results are displayed. You can use multiple -S arguments if you want to sort on multiple criteria. The default behavior is not to sort the returned entries. In the following example, the search results are sorted first by surname and then, within surname, by first name:-S sn -S firstname
-w: Password associated with the distinguished name that is specified in the -D option. If you do not specify this parameter, anonymous access is used. For example:-w password
-x: Specifies that the search results are sorted on the server rather than on the client. This is useful if you want to sort according to a matching rule, as with an international search. In general, it is faster to sort on the server than on the client.
-z: Specifies the maximum number of entries to return in response to a search request. For example:-z 1000
To get the surname (sn), common name (cn), and given name for every employee named John in the Sales organization, from the directory server listening at port 392, entirely from the command line, you could provide the following information:
ldapsearch -p 392 -b "ou=sales, o=company, c=US" -s sub "givenname=John" sn cn givenname
Results could be something like:
dn: cn=John Jackson, ou=Sales, o=Company, c=US sn: Jackson cn: John Jackson givenname: John dn: cn=John Kramer, ou=Sales, o=Company, c=US sn: Kramer cn: John Kramer givenname: John
You can get the same results by using a filter file. For example, a file called namejohn containing the filter:
givenname=John
can be used, with the following command line:
ldapsearch -p 392 -b "ou=sales, o=company, c=US" -s sub -f namejohn sn cn givenname
The LDAPMODIFY tool changes or adds directory content. There are other tools, but the concepts are similar. LDAPMODIFY opens a connection to the specified server, using the distinguished name and password you supply, and modifies the entries based on LDIF update statements contained in a specified file. LDAPMODIFY can also be run in interactive mode, a method that is not discussed here.
If schema checking is active when you use LDAPMODIFY, the server performs schema checking for the entire entry before applying it to the directory. If the directory server detects an attribute or object class in the entry that is not known to the schema, then the entire modify operation fails. Also, if a value for a required attribute is not present, the modify operation fails. Failure occurs even if the value for the problem object class or attribute is not being modified.
Note:
Keep schema checking turned on at all times to avoid accidently adding data to the directory that could be unusable or cause schema violations when schema checking is turned back on. Schema checking is controlled at the directory administration server console and is generally on by default.The command line format for LDAPMODIFY is:
ldapmodify <params>
Note:
The params category is optional; if it is omitted, LDAPMODIFY drops into interactive mode, which is not discussed here.<params> These parameters tell LDAPMODIFY how to operate. One of them, -f, can be used to specify a file describing modifications to be made to the directory.
Parameters are always provided in the form:
-p pdata
where p is the parameter, preceded by a dash and followed by a space, and pdata is the information required for the parameter, if any. If the data contains one or more spaces, it must be completely enclosed in double quotes:
-p "pdata with spaces"
Following is a partial list of commonly used parameters. Use the parameter /? to see all of them.
-a: Allows you to add LDIF entries to the directory without requiring the changetype:add LDIF update statement, which is necessary in the interactive mode. This provides a simplified method of adding entries to the directory; in particular, this allows you to directly add a file created by LDAPSEARCH and modified to make changes.
-c: Forces the utility to run in continuous operation mode. Errors are reported, but the utility continues with modifications. Default is to quit after reporting an error.
-D: Distinguished name of the server administrator or other user authorized to change directory entries. This parameter is optional if anonymous access is supported by your server. For example:-D "uid=j.smith, o=Oblix.com"
-f: Provides the name of the file containing the LDIF update statements used to define the directory modifications. For example:-f changestomake.txt
-h: Hostname or IP address of the machine on which the directory server is installed. This entry is optional; if no hostname is provided, LDAPSEARCH uses the local host. For example:-h mozilla
-H: Lists all possible LDAPMODIFY parameters.
-p: Port number that the directory server uses. For example:-p 1049
-w: Password associated with the distinguished name that is specified in the -D option. If you do not specify this parameter, anonymous access is used. For example: -w password
Suppose you want to change the stored given name of John Kramer, as reported under the discussion of LDAPSEARCH. The data reported back was:
dn: cn=John Kramer, ou=Sales, o=Company, c=US sn: Kramer cn: John Kramer givenname: John
This output can be used to derive an input file, ToHarvey, whose content might be:
dn: cn=John Kramer, ou=Sales, o=Company, c=US changetype:modify replace:givenname givenname: Harvey
The command line would then be:
ldapmodify - p 392 -f ToHarvey
If you were to now search the directory with the command line:
ldapsearch -p 392 -b "ou=sales, o=company, c=US" -s sub "givenname=Harvey" sn cn givenname
The response would be:
dn: cn=John Kramer, ou=Sales, o=Company, c=US sn: Kramer cn: John Kramer givenname: Harvey
To improve Identity System performance, you can tune the way the Identity System interoperates with the directory server, and you can ensure that the Identity System servers and plug-ins are configured optimally.
This section discusses the following topics:
As discussed in "Guidelines for Directory Tuning", the directory server plays a major role in overall system performance for Oracle Access Manager. For the Identity System, the types of searches that users conduct in the directory can significantly affect performance.
This section discusses the following topics regarding optimization of Identity System searches in the directory:
When users conduct a search in an Identity System application, the search bar presents a drop-down list with options for matching the search input with a set of results. These options include the following:
That contains
Contains in order
Equals
Less than
Greater than
Begins with
Ends with
Sounds like
The "greater than" and "less than" operations can result in many entries being searched and retrieved. By eliminating these choices, you can improve the performance of search operations. You configure the search operations in a set of parameter files, as described in the following procedures.
In addition to providing a search bar, the Identity System applications also provide a query builder function that enables users to construct search filters. You can eliminate the "greater than" and "less than" choices from the query builder as well as the search bar.
Note:
See the appendix on configuration parameters in the Oracle Access Manager Customization Guide for more information on the parameters discussed in the following procedures.To eliminate the "greater than" and "less than" search operations
To modify the search bar, open each of the following files in a text editor:
Install_dir\identity\oblix\apps\userservcenter\bin\ userservcenterparams.xml
Install_dir\identity\oblix\apps\groupservcenter\bin\ groupservcenterparams.xml
Install_dir\identity\oblix\apps\objservcenter\bin\objservcenterparams.xml
Install_dir\identity\oblix\apps\selector\bin\selectorparams.xml
Where Install_dir is the directory where Oracle Access Manager is installed.
Find the entry for the ObEnhanceSearchList parameter in each of these files.
Edit this entry in each of these files so that it only contains the following parameters:
<ValNameList ListName="ObEnhanceSearchList" >
<NameValPair ParamName="OOS" Value="MOOS"/>
<NameValPair ParamName="OSM" Value="MOSM"/>
<NameValPair ParamName="OEM" Value="MOEM"/>
<NameValPair ParamName="OBW" Value="MOBW"/>
<NameValPair ParamName="OEW" Value="MOEW"/>
</ValNameList>
To modify the query builder, open the following file in a text editor:
Install_dir\identity\oblix\apps\querybuilder\bin\querybuilderparams.xml
Edit the element ObQBOperatorsList to have only the following values:
<ValList ListName="ObQBOperatorsList" >
<ValListMember Value="CND_CON"/>
<ValListMember Value="CND_DNC"/>
<ValListMember Value="CND_EQ"/>
<ValListMember Value="CND_NEQ"/>
<ValListMember Value="CND_PRE"/>
<ValListMember Value="CND_NPR"/>
<ValListMember Value="CND_BW"/>
<ValListMember Value="CND_EW"/>
</ValList>
If you require users to enter a minimum number of characters in a search, fewer entries are searched in the directory. For example, if users must enter at least three characters, a directory search is likely to only involve and return a subset of all possible entries. This, in turn, can improve performance.
To require the user to enter a minimum number of characters in a search field
To specify the minimum number of characters users must enter in the primary search bar, open the following file in a text editor:
Install_dir\identity\oblix\apps\common\bin\oblixappparams.xml
Where Install_dir is the directory where Oracle Access Manager is installed.
Set the value of the searchStringMinimumLength parameter to the minimum length of the string that users can input, as illustrated in the following example:
<NameValPair ParamName="SearchStringMinimumLength" Value="3"/>
To specify the number of characters that users must enter in the search bar on the Group Manager's Manage Group Members page, open the following file in a text editor:
Install_dir\identity\oblix\apps\groupservcenter\bin\ groupservcenterparams.xml
Where Install_dir is the directory where Oracle Access Manager is installed.
Set the value of the groupMemberSearchStringMinimumLength parameter to the minimum length of the string that users can input, as illustrated in the following example:
<NameValPair ParamName="groupMemberSearchStringMinimumLength" Value="3"/>
You can set a limit on the number of elements that can be returned as the result of a search in an Identity System application. This limits the effect that a search can have on performance.
You can configure the maximum number of search results that are returned from the directory server on the Size Limit parameter for the directory server instance profile. For example, if you set the value of this parameter to 1,000, a maximum of 1,000 entries can be returned in the search results. The default value of 0 indicates that an unlimited number of results can be returned.
You can specify different size limits for different directory server profiles. For example, you can configure a size limit of 0 (unlimited) for the directory server instances that Identity System administrators use, and you can configure a limit of 1,000 for the directory server profiles that are used by end users.
To restrict the number of entries returned on a search
From the Identity System Console, click System Configuration.
On the System Configuration page click Directory Profiles.
Click the link for the directory server profile to which you want to add a database instance.
The Modify Directory Server Profile page appears.
Scroll down to Database Instances and click the database instance you want to configure.
The Modify Database Instance page appears.
Configure the Size Limit parameter to indicate the maximum number of search results that can be returned from the directory server.
Both the Access Server and Identity Server are multithreaded. Ensure that all Identity Event plug-ins are thread-safe. This recommendation also applies to Identity Event plug-ins.
It is a good practice to use at least two Identity Servers running in a pooled primary configuration. Pooled primary means using multiple Identity Servers that run as primary servers, with one or more WebPass instances connecting to the primary Identity Servers.
You can use separate Identity Servers as secondary servers when using a pooled primary approach. If you have only two servers, a pooled primary configuration is recommended over using one primary and one secondary server. When running a pooled primary configuration, it is best to use identical but separate hardware for the Identity Servers.
Advantages of pooled primary mode
Increased performance through load balancing
Increased availability through multiple servers
Automatic failover
Disadvantages of pooled primary mode
The cost of additional hardware.
If there are no secondary servers, each primary server needs to be sized to handle the total expected load if the other primary servers are unavailable.
Additional system configuration.
Identity Server configuration and stylesheet files must be identical on all servers. This applies to all configurations that use multiple Identity Servers. You should configure all Identity Servers from a file system level, that is, ensure that all directory and file system structures are identical.
On Windows, if the Identity Server causes high memory utilization, the system can crash. You can configure an Identity Server to use 3 GB of virtual address space, if 2 GB addressing is already enabled in the boot.ini file. Identiy Server can now use 3 GB of virtual address space.
By default, the virtual address space of Identity Server is limited to 2 GB. You can configure a /3GB switch in the Boot.ini file to allocate 3 GB of virtual address space to an Identity Server that uses IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header. This switch allows applications to address an additional GB of virtual address space beyond the usual 2 GB limit.
The following example shows how to add the /3GB parameter in the Boot.ini file to enable Identity Server memory tuning:
[boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(2)\WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINNT="????" /3GB
Note that the Boot.ini file typically resides in the system's root directory.
See the following URL for more information:
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
Group size can adversely affect performance. For instance, if you have groups of more than 30,000 users, operations involving these groups may be slow. Similarly, nested groups can result in slow performance during evaluation due to the large number of members in the nested groups.
The following sections discuss guidelines for group usage:
The following are general recommendations for tuning groups in the Identity System:
Oracle Access Manager evaluates dynamic group membership automatically based on a filter and user attributes. In general, this makes dynamic groups easier to manage than static ones. Also, evaluation of dynamic group membership is an inexpensive operation, enabling a dynamic group to be as large as you want without degrading performance.
If other applications only understand static groups, you can expand a group into a static list of members using the Group Manager application in the Identity System. To schedule periodic group expansion, you can also use the expandGroup IdentityXML or a Web service call to add the group expansion function to a cron job. See the Oracle Access Manager Developer Guide for details.
An evaluation of nested groups requires expensive, repeated LDAP queries to determine the attributes of the groups' members.. You may want to turn off nested group evaluation, or use this function selectively.
You can perform nested group evaluation selectively using IdentityXML and its related Web services call viewGroupMembers. This call can contain one of the following parameters:
showStaticUserMembers
showDynamicUserMembers
showNestedUserMembers
See the Oracle Access Manager Developer Guide for details.
Use the following procedure to turn off nested group evaluation for the Identity System.
To turn off nested group evaluation in the Identity System
In the Identity System Console, click Group Manager Configuration.
Click Configure Group Manager Options.
Deselect (uncheck) the options "Allow nested groups in My Groups pages" and "Show nested members of groups in the Manage Members page".
When working with groups in the Identity system, in general it is best to replace large static groups with dynamic groups. If you must use static groups, the following sections contain recommendations for using them:
If you have large static groups, avoid displaying the member attribute on group profile panels, and avoid using the member attribute in search results tables.
Each time a user views a group profile page, Oracle Access Manager performs a number of evaluations to determine what members the user is permitted to view. When thousands of members are involved, it can take a long time to evaluate the user's permission to view each member.
If you remove the member attribute from the group profile panels, you can use the Manage Members page to handle membership operations, for example, search, adding members, deleting members, and so on. 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. For more information on configuring the user, group, and organization manager, see the Oracle Access Manager Identity and Common Administration Guide.
One caveat regarding removing the member attribute from the group profile panels is that the IdentityXML and Web service call modifyGroup cannot be used to update group membership. However, this call is not recommended because of the overhead it introduces. A preferable alternative is to use the following calls:
subscribeToGroup
subscribeUserToGroup
unsubscribeFromGroup
unsubscribeUserFromGroup
These calls do not require the member attribute to be configured on a group profile panel. These calls use the subscription policy for the group. These operations operate on the changed data only, and as a result they are faster operations for large groups than modifyGroup.
Adding a member role to an access control policy adds a large amount of overhead to the evaluation of the policy. This can affect response time in all areas where the policy is used.
For static groups that are particularly large, for example, groups with over 10,000 members, you may find that performance is affected. For situations where a static group has become too large, you have the option of using a different evaluation algorithm for the group.
If you modify the evaluation process for the group, you must make appropriate changes in your Identity System configuration to ensure that members of the group are still searched and evaluated as intended. These changes include the following:
Members of this group and its subgroups are not displayed on the group profile page.
If you search for members of the group, members in any subgroups of this group are not displayed.
As a workaround, users can view the subgroup profile page and perform the search from the profile page of the subgroup.
Subgroups of this group are no longer evaluated in an Identity System policy.
For example, the subgroups and their members are not considered trustees in the following operations:
When evaluating read and write permissions for attributes
When defining a searchbase
When delegating administrative privileges
When adding workgroup participants
As a workaround, you can include the subgroups directly in the policy.
To modify the evaluation of a large static group
Open the following file in an editor:
Identity_Server_installdir\identity\oblix\apps\common\bin\globalparams.xml
In the globalparams.xml file, add the group DN to the LargeStaticGroups parameter.
You can enter values for multiple groups using this parameter. The following is an example:
<ValList xmlns="http://www.oblix.com"
ListName="LargeStaticGroups">
<ValListMember Value="cn=testgroup1,o=mycompany,c=us"></ValListMember>
<ValListMember Value="cn=testgroup2,o=mycompany,c=us"></ValListMember>
</ValList>
Save the file.
Restart the Identity Server.
If you have multiple Identity Servers, repeat this procedure on each server.
The Group Manager is an application in the Identity System. Group size, especially large nested groups, can degrade the performance of operations on the Group Manager application pages. When possible, use dynamic groups instead of nested groups.
Three Group Manager pages can be tuned to optimize performance. The rest of this section discusses the following topics:
You can tune the performance of the My Groups page as follows.
To tune the performance of the My Groups page
In the Identity System Console, navigate to Group Manager Configuration, Group Manager Options.
On this screen are several Boolean flags that you can set by clicking Modify. The Oracle Access Manager Identity and Common Administration Guide describes these settings. As an example of how these flags might influence the performance of your system, consider the setting labeled "Show nested groups". Showing nested groups can be a time-consuming operation, depending on the complexity of the group hierarchy. Setting this option to false limits group display to a simpler format, but can significantly improve the performance of the page.
To improve directory performance, index the following attributes, which are used in the My Groups profile:
Attributes configured with the ObSDynamicMember semantic type
Attributes configured as the ObSStaticMember semantic type
All user attributes used in group dynamic filters
Configure the optional group filter to further qualify results shown in the My Groups profile.
The filter can be used to further qualify results under any searchbase. The filter would most likely be used in a FAT tree scenario where all entries are located under one container. The parameters that control the use of this filter are extra_group_filter and use_extra_group _filter_mygroups, found in the groupdbparams.xml catalog. The extra filter can be any LDAP filter and, in addition, may contain an Oblix rule substitution ($ $). When using a rule substitution, the substituted value comes from the user entry. This provides a means to link the values of attributes in a user entry with those in group entries. For example, a filter such as ou=$ou$ would specify, that in order for a group entry to qualify, the ou of the group must be the same as that for the user.
Replace the default stylesheet, gsc_myprofile.xsl, with gsc_myprofile_simple.xsl.
The default stylesheet for the My Groups page uses DHTML and layers to render the groups in a browseable tree format. If the My Groups page has to show many groups, the browser may take a long time to render the page. The gsc_myprofile_simple.xsl stylesheet has a simpler, non-browseable interface and does not use DHTML and layers as much. Both stylesheets are located in the directories:
IdentityServer_install_dir/identity/oblix/lang/en-us/style0/ (stylesheet template)IdentityServer_install_dir/identity/oblix/shared/ (wrapper stylesheet)
For details about stylesheets and styles, see the Oracle Access Manager Customization Guide.
To use gsc_myprofile_simple.xsl
Change the XML registry settings in the registry file:
IdentityServer_install_dir/identity/oblix/apps/groupservcenter/bin/groupservcenterreg.xml
In this file, change the following line:
<ObStyleSheet name="gsc_myprofile.xsl"/>
to
<ObStyleSheet name="gsc_myprofile_simple.xsl"/>
Then restart the Identity Server and Web server.
You can tune the performance of the View Members page in the following ways:
You can control the behavior of the View Members page using three Identity System Console options.
These options can be turned on and off in the System Configuration, Group Manager Configuration, Group Manager Options page. See the Oracle Access Manager Identity and Common Administration Guide for information on these flags.
You can constrain the search that can be done in the View Members page. Locate the groupMemberSearchStringMinimumLength parameter in the catalog:
IdentityServer_install_dir/identity/oblix/apps/groupservcenter/bin/ groupservcenterparams.xml
This parameter controls the minimum number of characters that the user must type to be able to search for members of a group. Other than being restricted to group membership searches, its usage is identical to that of the searchStringMinimumLength parameter (see "Indexing and Search Constraints" for details).
You can index any user attributes used in group dynamic filters.
The following attributes are used in group expansion and should be indexed to improve performance:
Any attributes configured with the ObSDynamicMember semantic type.
The obgroupexpandeddynamic attribute of the oblixadvancedgroup object class.
All user attributes used in the dynamic filters of the groups to be expanded.
As discussed under see "Tuning the My Groups Page", use the Set Searchbase feature to localize access to sub-domains appropriately.
This may also improve the performance of the Group Expansion page.
The performance of the Group Expansion page may be improved by using the extra group filter feature, discussed under see "Tuning the My Groups Page".
To tune the performance of group operations in the Identity System, you should also ensure that the cache for group IDs can accommodate the number of user entries in the directory. In general, the cache should be able to hold twice the number of entries that reside in the directory.
To tune the number of user entries in the user information cache
Open the following file in an editor:
Identity_Server_Installdir\oblix\apps\common\bin\globalparams.xml
Where Identity_Server_Installdir is the directory where the Identity Server was installed.
In globalparams.xml, set the value of the UidInfoCache.maxNumElems parameter to a value, in kilobytes, that is approximately twice the number of user entries in the directory server.
Workflow performance can be tuned in several ways:
Workflows are also mentioned in the sections on directory tuning and indexing. See "Storing Workflow Tickets in the Directory" and "Indexing and Workflows" for details.
The workflowdbparams.xml file resides in the following location:
IdentityServer_install_dir/identity/oblix/data/common
The following parameters can be tuned to assist with workflow performance. You must restart the Identity Server for changes to these parameters to take effect:
WfDefCacheMaxNoOfElements—This parameter sets the size of the workflow definition cache. Set the value of this parameter to be higher than the number of defined workflows.
WfDefMaxNumStepDefFiltersPerSearch—This parameter controls how many searches the Identity System performs on instance data. If users are participants in a large number of workflow steps, increasing the value of this parameter can reduce the number of times the directory is searched. To experiment with this parameter, increase its value in increments of 20. A higher number reduces searches to the directory, but increases the LDAP filter length. You can monitor the directory CPU utilization to determine an optimum value.
The following guidelines will help you tune workflow search performance:
Check the number of search results that are returned per page. The default is 20. A higher number of results per page may cause slow performance.
If workflow participants are specified as a filter, performance will be slower. See if participants can be specified using a static group.
This section describes ways to tune the performance of the Access Server, including:
By default, when Oracle Access Manager validates a user password as part of the validate_password plug-in, it passes the request to the user directory server. The directory server validates the password and returns the result to Oracle Access Manager. This operation is slow. In an environment with many authentications, it degrades Access Server performance.
You can control whether to use the Access Server or the directory server for password validation on a scheme-by-scheme basis.
Process overview: When using Access Server password validation
The first time a user's password is validated, the Access Server goes to the directory server for validation.
If the password is valid, the Access Server caches an MD5 hash of the password. The Access Server never caches a clear text password.
The next time the user's password needs to be validated, the Access Server creates an MD5 hash of the supplied password and compares it to the hash of the cached password.
If the two hashes match, the user's password is considered valid.
If the two hashes don't match, the Access Server validates the password against the directory. If the directory validates the password, the Access Server hashes it and replaces the old hash in the cache.
To configure an authentication scheme so that the Access Server validates passwords, add the parameter ObCredValidationByAS with a value of true to the validate_password plug-in parameter list. To control the timeout of the cached password on a scheme-by-scheme basis, use the Time To Live parameter. The default value of the Time To Live parameter is 1800 seconds (30 minutes). To control the interval at which the Access Server goes to the directory for password validation, add the parameter obPwdHashTTL with a value equal to the number of seconds required.
The following is an example of the out-of-the-box validate_password plugin:
validate_password obCredentialPassword="password", obAnonUser="cn=anonymous, o=Company, c=US"
The following is an example of validate_password configured to use Access Server password validation with the default Time To Live parameter:
validate_password obCredentialPassword="password", ,obCredValidationByAS="true', obAnonUser="cn=anonymous,o=Company, c=US"
The following is an example of validate_password set to use the Access Server password validation with Time To Live set to 100 seconds:
validate_password obCredentialPassword="password", ,obCredValidationByAS="true" , obAnonUser="cn=anonymous,o=Company, c=US", obPwdHashTTL="100"
The Access Server uses request queues to create a sequence of incoming requests that are processed by worker threads.
You can tune the performance of the Access Server by increasing the number of request queues from the default of 1. Multiple request queues can reduce contention between service threads and message threads. This can be particularly beneficial on multi-processor computers. See "To change the number of request queues" for details. If you change the number of request queues, also change the number of threads per queue as recommended in "Estimating the Required Number of Threads and Queues".
The request queue holds requests from AccessGates until they are processed. By default, there is one request queue.
The Access Server uses three types of threads:
Message threads
Message threads accept new requests from AccessGates and append them to the request queue. The number of message threads is equal to the number of connections opened between the AccessGate and the Access Server.
Service threads
Service threads remove requests from the queue and process them. Each request queue has a fixed number of service threads. The number of service threads is configured in the Access System Console. See the Oracle Access Manager Access Administration Guide for details. By default, there are 60 service threads per request queue. The total number of service threads in an Access Server is equal to the number of request queues times the number of service threads per queue.
Utility threads
These perform housekeeping activities. There are usually between 20-40 utility threads, depending on the number of directory profiles configured for the Access Server, the number of file log writers defined, and so on.
To estimate the total number of threads, take the totals for each type of thread, as follows:
Total message threads
The netstat command enables you to determine the number of connections opened by AccessGates to the Access Server. Multiply this number by the number of message threads. For example, if there are 50 WebGates, each with 3 connections to an Access Server, there are 3 * 50 or 150 message threads.
Total service threads
The number of service threads is configured in the Access System Console. See the Oracle Access Manager Access Administration Guide for details.
Total utility threads
An average of 30 can be considered safe, using the guidelines in the previous paragraphs.
For example, if there are 50 WebGates, each with 3 connections to AccessGates, a value of 60 configured for the number of service threads in the Access System Console, and an estimated 30 utility threads, there are a total of 150 + 60 + 30 or 240 threads.
Having many queues with a relatively small number of threads per queue can cause problems if the requests come primarily on one queue. It may be helpful to configure more than the minimum number of threads per queue. You can control the number of worker threads from the command line or from the Access Server configuration page.
If your Access Server handles more than 800 requests per second, you may need to change the number of request queues. A good rule of thumb:
Set the number of queues equal to the number-of-peak-requests-per-second/800.
Set the number threads per queue to 60/number-of-request-queues.
These recommendations are based on benchmark and performance tests. For example, if the peak request rate for an Access Server is expected to be 2000 requests per second, the number of queues should be 2000/800, or approximately 2. The number of threads per queue should be 60/2 = 30.
Avoid having too few or too many threads per queue. Four threads is adequate for benchmarking, but if the directory server is slow in responding you might need more. The optimal number for the total number of threads may be closer to 100 for a modest improvement in performance on a large, fast system. However, performance is not excessively sensitive to the number.
For example, an environment with 16 queues and 16 threads apiece (256 total threads) produced about 9,000 TPS during a lab test with directory access turned off. An environment with 16 queues and 4 threads apiece (64 total threads) produced about 9,400 TPS on the same configuration. For even the largest deployments, 8 queues should be enough, and 2-4 queues may be sufficient.
To change the number of request queues
When starting the Access Server from the command line, type the following:
aaa_server -i install_dir -Q n
where n is the number of request queues. The number of queues must be an integer to a maximum of 1024.
When using Access Server service on Windows NT or Win2K the -Q option must be specified as a startup parameter to the service. Alternatively, you can modify the following script to include this parameter:
AccessServer_install_dir/access/oblix/apps/common/bin/start_access_server
Restart the Access Server for this parameter to take effect.
When you define access policies for a policy domain, the WebGate by default will query the Access Server every time a user attempts to access resources in that domain. The more broad the policy domain, the more often the Access Server is queried. For example, if you configure root (/) as the policy domain in the Policy Manager, the WebGate will contact the Access Server every time someone tries to access a resource on the entire Web site.
To minimize the number of times the WebGate queries the Access Server, you can configure the DenyOnNotProtected flag. When set to true, DenyOnNotProtected denies access to all resources to which access is not explicitly allowed by a rule or policy. This can limit the number of times the WebGate queries the Access Server, and can improve performance for large or busy policy domains. See the Oracle Access Manager Access Administration Guide for details.
The following guidelines can reduce the risk of introducing instability to the Access Server when using API-Based plug-ins:
Ensure that any API-based plug-ins that are deployed on the Access Server are thread-safe
Both the Access Server and Identity Server are multithreaded. This recommendation also applies to Identity Event plug-ins.
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
Ensure that all authorization and authentication plug-ins take input parameters from the Access Server in order to specify configuration information.
For more information, see "Plug-Ins". For details about Oracle Access Manager APIs and plug-ins, see the Oracle Access Manager Developer Guide.
AccessGate client configuration includes a secret password between the Access Server and the AccessGate to prevent invalid clients from connecting to the Access Server. Oracle recommends that you implement SSL to encrypt the communication between the Access Server and AccessGate 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.
For more information, see the chapter on customizing access control with plug-ins in the Oracle Access Manager Customization Guide.
The way that you configure group-related features in the Access System can affect performance. By default, the Access Server checks for different types of group memberships when evaluating user membership in a group. Directory servers allow the following types of group membership:
Static group membership
In this type of group, each user is explicitly defined as a member.
Dynamic group membership
This type of membership is defined by an LDAP rule. Each user that satisfies this LDAP rule is a member of the group.
Nested group membership
A nested group consists of one or more static groups, dynamic groups, or both.
The Access Server evaluates group membership as follows:
When you create an authorization scheme and assign it to one or more groups of users, for example, when you grant access to account data to all Finance group members.
When you define an authorization or authentication action that contains the obmygroups attribute, the Access Server finds all the groups a user belongs to, and returns the list of groups in a cookie or header.
The following sections provide guidelines for group configuration in the Access System.
Dynamic group membership is evaluated automatically based on a filter and user attributes. In general, this makes dynamic groups easier to manage than static ones. Also, evaluation of dynamic group membership is an inexpensive operation, enabling a dynamic group to be as large as you want without degrading performance.
Use nested groups with caution. Evaluation of nested group memberships is extremely expensive to evaluate. LDAP directory servers must perform repeated queries to determine the values for attributes of members of nested groups. If you are not using nested groups, disabling the nested group membership check will improve performance.
By default, the Access Server checks for static, dynamic and nested group memberships to determine authorizations. You can use the following procedure to turn off nested group evaluation for the Access System.
To turn off nested group evaluation for the Access System
Open the following file in an editor:
Access_Server_Installdir\oblix\apps\common\bin\globalparams.xml
Where Access_Server_Installdir is the directory where the Access Server was installed.
In globalparams.xml, set the value of the TurnOffNestedGroupEvaluation parameter to true.
For more information, see the chapter on configuring user authentication in the Oracle Access Manager Access Administration Guide.
As explained in the Oracle Access Manager Access Administration Guide , you can configure the obmygroups parameter in an authentication or authorization rule. This is useful when integrating the Access System with other applications. This parameter looks up a user's group memberships in the directory. This provides role-based information for the user. The following are examples:
You can define an application as a set of URLs whose access is provided to members of only a few groups in the directory.
You can set the obmygroups parameter to supply group membership information to an application to prevent the application from having to query the directory directly or determine if a group is static, dynamic, or nested.
You can set the obmygroups parameter to enable an application to customize navigation or appearance based on what groups the user belongs to.
Specific menu items and functions can be based on group membership.
When you configure the obmygroups parameter, by default Oracle Access Manager searches for all group objects in the Access System searchbase and builds a user and group relationship cache in the Access Server. This cache is called the Group Query Cache. No Oracle Access Manager ACLs apply to the query. All groups that the user belongs to are supplied, whether or not the user has read permissions for the class attributes for these groups. Oracle Access Manager evaluates the entire Group Query Cache for each resource that is protected by a policy with an action that contains obmygroups. All groups in the cache must be checked to see if the user is in that group. This is an expensive lookup.
The Group Query Cache expires every ten minutes. This timeout is not configurable, and you cannot flush this cache. The cache is cleared only when the cache timeout limit is reached or when you restart the Access Servers.
Use the following guidelines when specifying obmygroups in an authorization action:
Always configure actions that use obmygroups using an LDAP filter, for example:
obmygroups:ldap:///o=company,c=us??sub?(group_type=role)
If you are not using nested groups, turn off evaluation for nested groups.
See "To turn off nested group evaluation for the Access System" for details.
In general, it is best to specify obmygroups in an authentication rule rather than an authorization action.
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.
When you use obmygroups in an authorization rule, limit its use to as few resources (URLs) as practical.
For more information, see the chapter on configuring user authentication in the Oracle Access Manager Access Administration Guide.
Note:
You may find that using an IdentityXML call,userGroupsProfile, is a less resource-intensive method for returning the groups that are associated with a user. See the chapter on configuring IdentityXML parameters in the Oracle Access Manager Developer Guide for detailsYou can tune three groups of Access System caches:
The cache for policy domains and policies
The cache for user data
The cache for URL Prefix
For additional information, see Chapter 5, "Caching and Cloning" .
A policy cache contains information about policy domains, excluding URLs, policy descriptions, and display names. A policy cache element contains the following:
Rules
Actions associated with rules
Filters, groups, and roles associated with rules
Policy conditions for rules
All policy domains
All policies
All authentication schemes
You tune the policy cache by setting the Maximum Elements in Policy Cache and Policy Cache Timeout parameters.
Note:
These parameters are also documented in the Oracle Access Manager Access Administration Guide.To estimate the requirements, calculate the total number of authorization rules in all policy domains and policies. To do this, search the Oblix directory tree using the following filter:
"(objectclass=oblixpolicyrule)"
When determining the number of elements in a policy cache, be sure to account for future growth of the number of rules.
To calculate the memory requirements for the Access Server's policy cache elements, check the memory requirements of the directory used to store the policies.
This value is roughly the value you should provide on the Access Server.
When a policy domain, rule, or policy is created or modified, the administrator has the ability on each screen to Update Cache. When these screens are saved, this forces an immediate flush of the relevant policy cache, ensuring that the change takes effect immediately.
You can have the caches time out on a regular basis as a security precaution or to clean up if the administrator does not press the Update Cache button during a policy change. The Oracle Access Manager Access Administration Guide discusses automatic flushing of the Access System cache.
The tuning parameters available for this are Maximum Elements in User Cache and User Cache Timeout.
The user cache contains all user attributes and values used in audit and HTTP actions. You need to determine the shortest time acceptable for not changing bulk user attribute values. If the value is too large, values that are considered important from a risk-management perspective may not make their way into Oracle Access Manager until the cache is flushed. This can be a problem if the administrator forgets to update the cache after making changes. The administrator, delegated identity administrator, or user may change a user value in the directory and think it has been implemented when, in fact, there will be a delay until the value in the cache is flushed.
On the other hand, avoid setting the timeout or the cache size so small that data is flushed while a user is accessing a site, since this forces another trip to the directory.
To estimate a reasonable interval for updating user values, you can track average session times over a 24-hour period. The User Cache Timeout value can probably be set to this value or slightly higher than this value.
If you know the value for User Cache Timeout, you next measure the number of users who access resources during this time interval.
When you know the maximum number of concurrent users during the time interval, the number represents the maximum number of cache elements. This is because each element contains a user DN and their attributes and values used in the audit logs and HTTP actions.
If you know the user cache timeout and the maximum number of elements in the user cache, you can calculate hardware requirements.
To begin, calculate the requirements per cache element. An element in the user cache refers to all user attributes and their values used in all the rules. The formula for this is:
cache element size = size of DN + size of all attribute values to be cached + 50 bytes for overhead
You can now calculate total memory requirements as follows:
Max. elements in user cache memory requirements = Max. elements x cache element size
The URL prefix cache sets the interval for flushing a URL prefix. If a URL prefix is added to a policy domain or policy, the administrator can click the Update Cache button to force an automatic cache flush. The URL Prefix reload period is an additional safeguard that provides automatic flushing.
Choose a time interval that you feel comfortable with between automatic cache flushes. The default value is 7200 seconds, or two hours.
WebGate caches information on authentication and on whether or not a resource is protected. WebGate cache tuning refers to the total number of unique URLs expected over the timeout interval.
The chances of an authentication scheme changing quickly are very low. The chances of a URL prefix being changed or added are low. If an administrator adds, changes, or deletes a URL prefix, the screens contain an Update Cache button for forcing an immediate cache flush. As a result, the default value for the WebGate cache timeout is zero. This means that the cache is not automatically updated and is flushed only when the administrator clicks the Update Cache button. If you are not comfortable with the default, choose an appropriate interval before the URL is automatically flushed from the cache.
WebGate can cache URLs to avoid trips to the Access Server or directory server when determining if a URL requires protection. The default value for Maximum Elements is 100,000. To estimate an appropriate value for this parameter, examine the number of URLs that the Web server is protecting and the HTTP operations associated with them.
Web browsers place an internal limit of 4096 bytes on URLs. Most URLs are smaller than 4096 bytes. You may want to determine upper limits for the cache and choose the same size or a smaller size than 4096, depending on what you believe is an average URL size.
To calculate memory requirements per cache element:
memory per cache element = URL (4096 bytes) + overhead (128 bytes) = 4224 bytes
To calculate the memory requirements for maximum cache elements:
memory required = 100,000 elements x 4224 bytes/element = 422,400,000 bytes = 422 MB of memory
Memory requirements may be smaller if the maximum number of elements is downsized according to the needs of the Web server that the WebGate is on and the average size of the URLs.
The performance of the overall network, or network latency, is a major factor in the performance of the system. A reduction in network latency will be reflected in the performance of Oracle Access Manager.
It is not necessary, and not even desirable, for you to deploy load balancers between Oracle Access Manager components, even if you use load balancers for other application deployments. Avoid placing load balancers between an Access or Identity Server and any of the following components:
WebGates or AccessGates
WebPass
Directory servers
Oracle Access Manager uses the LDAP protocol to perform update operations, and it provides keep alive, failover, and failback functionality to handle LDAP and network outages, replication, and related activities. The built-in features of Oracle Access Manager are often the same or better than similar features provided by a load balancer.
In some cases, you can negatively affect the performance of Oracle Access Manager by placing a load balancer between its components. For example, a load balancer may terminate a connection that it interprets as idle without triggering a response that Oracle Access Manager can detect and adjust to. This can cause outages.
The following are guidelines for tuning your network:
You can consider adding an SSL accelerator or load balancer outside of the Oracle Access Manager system to improve the performance of your network.
Deploying a load balancer in front of the Web servers or application servers is a best practice for increasing availability and performance of Web-based applications, including Oracle Access Manager. However, load balancers are not recommended between the Oracle Access Manager components themselves.
You may want to set the DenyOnNotProtected flag to True in the WebGate configuration page (or in the WebGateStatic.lst file for pre-10.1.4 versions of Oracle Access Manager).
This reduces trips between the Access Server and the directory. The DenyOnNotProtected flag forces the WebGate check its own cache to determine if a URL is protected.
Reduce the latency between devices in high-traffic parts of the network.
You can place the Identity and Access servers closer to client applications than to the directory. During normal operations there is more traffic between WebGates and Access Servers than between Access Servers and the directory. Similarly, there is more traffic between WebPasses and Identity Servers than between Identity Servers and the directory. These servers have the greatest interaction with the directory at startup. After that time, much of the configuration information that these servers need can be read from their caches. One exception is if the administrators are performing system configuration, for example, if they are defining and testing workflows. In this case, placing the Access and Identity servers in the hosting site can help the response time for the administrators.
Resource-intensive operations include login forms, password management, and plug-ins.
The following are issues to examine to optimize performance.
For performance tuning purposes, you can log the time it takes to process calls to external components. For example, you may want to know what Identity Servers are processing the most requests from the most WebPasses.
Use the information logs to identify components that are processing a heavier load or are taking a particularly long time to service requests. See the chapter on logging in the Oracle Access Manager Identity and Common Administration Guide for details.
Login forms increase the overall load on Web servers. This may mean that you need more Web servers, depending on the size of the server and the form content. Dynamic contents and graphics adversely affect performance. An extremely high number of logins can cause network latency.
Password management causes many directory write operations. When you implement password management, be aware that there are performance implications if you expect it to be used frequently.
Oracle Access Manager plug-ins and .exe files can affect performance. When you develop customizations for Oracle Access Manager, be aware of the impact of these customizations.
To minimize performance impact:
When creating an action for the Identity Event API, because an action incurs overhead, identify all the possible events to attach the action to and choose the least frequently used one that yields the desired result.
Evaluate the sequence in which actions are executed.
For example, suppose that you develop a .exe file to send an email message through the SMTP server when a user performs a particular action. Depending on how you write this program, the Identity Server may be unable to perform further actions until it receives a reply from the SMTP server. If it is the case that the SMTP server is down, there may be a large impact on performance.
When comparing EXEs and LIBs, note that LIB actions execute quickly because they are binary code modules compiled from C or C++ source code. However, their perceived speed depends on the function they perform.
Avoid EXEC-type plug-ins, which spawn external processes.
For example, 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 to balance the system load. Also, consider Identity Event plug-ins that use C/C++ as shared objects (.so files) for performance and stability reasons
Ensure that all Identity Event plug-ins are 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 plug-in functions to minimize runtime image size.
Ensure that the plug-in supports using a configuration file to alter and adapt its operation in case of requirement changes.
For more information about developing plug-ins and using Oracle Access Manager APIs, see the Oracle Access Manager Developer Guide.
