| 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 |
Caching information and cloning play key roles when you performance tune your Oracle Access Manager environment. This chapter contains the following topics:
Instead of using the command line or the installation GUI to install a Oracle Access Manager component, you can automatically install a component by cloning the configuration of an already installed component. Cloning creates a copy of a component on a remote system using an already-installed component as a template.
Synchronizing allows you to harmonize two installations of the same Oracle Access Manager component when one is more up-to-date than the other. Synchronization can be used to upgrade or repair installations on similar platforms.
See the Oracle Access Manager Installation Guide for more information on cloning and synchronizing.
A cache is in-memory storage that keeps a copy of recently used information. Oracle Access Manager retrieves information that is used frequently from a cache instead of the directory. This allows information to be retrieved quickly. Oracle Access Manager uses several caches to improve performance.
The Identity and Access Systems contain different caches. The Oracle Access Manager system caches configuration settings and group information. The Access System caches information on password policies, policy domains, user credentials, and authentication schemes.
Some operations performed in the Oracle Access Manager impact the evaluation of access policies in the Access System. For example, if you deactivate a user in the Identity System, that change must be reflected in the Access System so the user does not have access to the resources that the Access System protects.
The optimum number of elements in a cache is a balance between:
The number of elements required to be in the cache. This depends on the information being cached and system usage.
The RAM available for caching.
The higher the number of elements in a cache, the greater the probability of finding the requested information and improving performance.
In a worst case scenario, if the cache uses a lot of memory and the machine on which the component runs does not have enough RAM, the operating system could spend too much time swapping pages in and out of memory. This would decrease performance.
The minimum cache size for optimal performance would be:
N = XR
where:
N = the number of entries in the cache. X = the number of new sessions per second. R = the average length of a session in seconds.
For example, if:
X = 100 sessions per second, and R = 600 seconds per session, then N = 60,000 number of entries in the cache
The default cache size for Oracle Access Manager components is sufficient for most installations.
The rest of this section discusses the following topics:
Identity Servers can communicate with one another. They do so primarily for cache flush requests. When a cache is updated on one server, that server tells the other servers to update their caches. The Identity Server has several caches. Each can receive a cache flush request if data is modified:
Configuration Data: Object classes, attributes, tabs, and panels. The Oracle Access Manager-specific data (OSD) cache is flushed automatically. In addition, you can request a cache flush as described in "To clear the OSD cache".
Group Objects: Automatic when you modify a group, or you can explicitly request a cache flush as described in "Caching Group Objects".
DNs of User Objects: This is the name cache. It is flushed automatically.
Read and Write Privileges for Attributes: Automatic cache flush.
Delegated Identity Administration and Auditing: Automatic cache flush.
Workflow Definitions and participants: Automatic cache flush.
Basic Configuration Data Entered in Setup: Configuration base (configuration DN) and searchbase. Automatic cache flush.
User-Defined Portal Inserts: Invoked explicitly through a URL, as described in the Oracle Access Manager Customization Guide.
To configure asynchronous cache flush for the Identity Servers
Edit the following file:
identity_server_installdir/oblix/apps/common/bin/globalparams.xml
Configure the oisClientTimeoutThreshold parameter in this file.
The default value for this parameter is 60 seconds. Absence of this parameter or a value of -1 indicates synchronous cache flushing.
Perform these steps for each Identity Server.
The cache timeout specifies how long an element is held in the cache. When the time expires, the element is removed from the cache and must be retrieved from the directory.
If the information changes, but the cache does not, the Oracle Access Manager component uses outdated information until the information expires from the cache. Updating caches when you change the information is one way to avoid this problem. If updating caches is not possible, such as when a user's information is changed through other software, then configuring a reasonable timeout for the cache is another solution.
A shorter timeout means information about the user is more recent, but the Identity Server and the Access Server must fetch data more often from the directory. This may reduce performance. Setting a long timeout means out-of-date information could remain in the cache for a longer period of time.
Note:
In general, setting a lower cache timeout value means the data is more recent. However, a cache timeout value of 0 means the cache never expires.Oracle Access Manager caches configuration information for specific data such as object classes, attributes, panels, and tabs used by Oracle Access Manager applications. This information is automatically cached during startup.
You must be a Master Administrator to view, reload, or clear the OSD cache.
To view the OSD cache contents
Launch the Identity System Console.
Click the System Configuration tab and select View Server Settings.
In the View Server Settings page, click Cache.
In the Cache page, click View Cache Contents.
The cached OSD information is displayed.
To load the OSD cache
Launch the Identity System Console.
Click the System Configuration tab and select View Server Settings.
In the View Server Settings page, click Cache.
In the Cache page, click Load memory cache.
The latest information is loaded into the cache.
To update existing information, you must first clear the cache and then reload the information.
To clear the OSD cache
Launch the Identity System Console.
Click the System Configuration tab and select View Server Settings.
In the View Server Settings page, click Cache.
In the Cache page, click Clear memory cache.
The cache is cleared.
The following sections provide more details on caching system information:
The Identity System provides a cache for group objects to boost performance for all group functions, especially those involving computation of parent (isMemberOf) groups, and children or nested groups.
A group is cached only when Oracle Access Manager makes its first request for that group. Subsequent requests for the group are directed to the cache. When you modify a group, it is removed (flushed) from the cache along with any parent, child, or nested groups. In a multi-server configuration, when a group is modified on one Identity Server, all other Identity Servers are notified so that they remove the group and all its dependent groups from their caches. When Oracle Access Manager receives another request for the modified group, it re-stores the group in the cache. This ensures that the cache has the most recent information for the group.
When you search for a group, Oracle Access Manager searches the directory, not the cache.
You manage the group cache using the groupdbparams.xml configuration file.
To configure group cache parameters
Navigate to the file groupdbparams.xml located in:
IdentityServer_install_dir \identity\oblix\data\common
where IdentityServer_install_dir is the directory where the Identity Server is installed.
Configure values for the parameters in the groupdbparams.xml file that control the cache-related functions described in Table 5-1.
Table 5-1 Parameters in groupdbparams.xml
| Parameter | Description |
|---|---|
|
GroupCacheTimeout |
The time period (in seconds) for which the object is valid. By default, the Group Cache never times out. Default = 0. |
|
GroupCacheMax NumElements |
The maximum number of group objects that can be stored in the cache. Default = 10000. If the cache is at its maximum size, objects that are not accessed often are replaced by those that are more frequently accessed. Consider the memory limitations of your system before setting the value for this parameter. |
|
GroupCacheDisabled |
Indicates whether the cache can be used or not. Default = false. A value of false indicates that the cache can be used. A value of true indicates that the cache cannot be used. If a cache is disabled, all reads of group objects will go to the directory. |
|
GroupCacheRead FromMaster |
Forces reads of groups so that the cache can do reads from the master replica in a replicated environment. This ensures that the cache does not contain old information in case a read from a consumer replica occurs before the consumer replica has received the updated information from the master replica. Default = false If value = true, it indicates that the cache should read from the master replica. |
On occasion, it may be necessary to remove a group from the cache to maintain cache integrity. For example, you may have to remove a group that has been modified using an application other than Oracle Access Manager to ensure that the updated group is read when the cache receives a read request for the group.
A Master Identity Administrator can clear the group cache through the Identity System Console, or with an Identity XML function named flushGroupCache. See the IdentityXML chapter in the Oracle Access Manager Developer Guide for more information.
To clear group caches from the Identity System Console
Launch the Identity System Console.
Click the Group Manager Configuration tab.
In the Group Manager Configuration page, click Group Cache.
In the Group Cache page, click the Clear group cache link.
The group cache is cleared and a message appears confirming whether or not the operation was successful.
If a user is deactivated in Oracle Access Manager, you can deny that user access to protected resources. Because the Identity Server does not automatically flush the Access Server credential mapping cache when a user is deactivated, you must manually turn off the credential mapping cache.
When the cache is turned off, the credential mapping plug-in communicates directly with the LDAP directory whenever it must map a user to a user profile (DN). Otherwise, the plug-in uses the cached credentials for the user.
By default, the credential mapping cache is enabled.
To disable use of this cache, set the obEnableCredentialCache parameter to false in the credential_mapping plug-in. If you deactivate a user who is logged in, the user will still have access to resources based on policy information and prior authentication. However, if obEnableCredentialCache is set to false, when the user's session token expires or the user logs out, the user will not be allowed access to a protected resource the next time the user is authenticated.
Table 5-2 shows the possible values for the parameter.
Table 5-2 Parameters for obEnableCredentialCache
| Value | Meaning |
|---|---|
|
no value |
Credential mapping cache turned on |
|
true |
Credential mapping cache turned on |
|
false |
Credential mapping cache turned off |
Here is an example of the credential_mapping authentication plug-in with the credential mapping cache turned off:
credential_mapping obMappingBase="%domain%",obMappingFilter=" (&(&(objectclass=user)(samaccountname=%userid%)) (|(!(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))", obdomain="domain",obEnableCredentialCache="false"
To set the obEnableCredentialCache parameter
In the Access System Console, Access System Configuration, Authentication Management.
Select the authentication scheme you want to modify, then click Modify.
Click the Plugins tab.
Add the obEnableCredentialCache="false" parameter to the credential_mapping plug-in.
The Access System caches information on password policies, policy domains, user credentials, and authentication schemes.
Figure 5-1 illustrates how caching works in the Access System. It is not necessarily a deployment recommendation.
You can specify the maximum number of elements in a cache. The Access System ensures that the total number of elements in a cache never exceeds the maximum specified for that cache.
For example, suppose you have set the Access Server's user cache to contain a maximum of 100,000 elements. If a user is added to the system when the cache is full, the Access System removes the user element that has not been used in the longest time and adds information about the new user to the cache.
Note:
WebGate and Access client configurations are cached in the Access Server. To reduce off-time network traffic between WebGate and Access Server and between Access Server and LDAP directory server, you can change the default configuration cache timeout. For details about reducing network traffic between components, see the Oracle Access Manager Access Administration Guide.The Access Server caches information that includes data on policy domains, policies, users, host identifiers, and password policies. When information is updated for any of these, ensure that the Update Cache box is selected to immediately update the Access Server caches.
An Access Server's policy cache contains information about policy domains, policies, authentication, authorization, audit rules, and actions.
An Access Server caches policy information for efficient runtime lookup. If policy information is not in the cache, the Access Server must obtain it from the directory. Obtaining data from the directory is slow when compared to the AccessGate obtaining information from the Access Server, so preferably all policy information should be cached.
When policy information is changed through Policy Manager or the Access System Console, Access Server caches can immediately be updated by selecting Update Cache. Policy cache timeout becomes important when this feature is not used. Cache timeout should be set to how quickly the policy information needs to be updated when Update Cache is not or cannot be used. The default policy cache timeout is two hours.
If the Access Server machine has sufficient memory to hold all the configured policy information, the maximum elements should be set according to whatever is the maximum of following:
Total number of policy domains
Total number of authentication rules, default or otherwise
Total number of authorization rules, default or otherwise
Total number of audit rules, default or otherwise
This configuration works for a typical deployment.
An Access Server's user cache includes information about:
User Profile, which is required both in actions and rule-based access evaluation
User's group-membership status, such as whether a user is member of a group or not
The Access Server caches a user's profile information and group membership information. The profile information includes both the information required in actions and the information required for authorization. For example, if the authorization rule for a policy allows access to anyone whose userLevel attribute is set to greater than 3, Access Server caches will include the userLevel attribute.
Similarly, an Access Server caches information about whether or not a user is a member of a group.
User and group information can be updated through the Identity Server or other applications. As user and group information changes, the Oracle Access Manager caches become out of date. For this reason, user cache timeout is crucial.
The timeout of the user cache should be proportional to the average time interval in which part of User Profile--those relevant to Access System--changes. Relevant parts of a user profile are:
Attributes returned to AccessGate in actions
Attributes used to control access
Attributes used in dynamic group-membership definitions that may in turn be used to control access
The maximum elements should be equal to the number of different users that may access the system in the Access Server user cache timeout period of time.
You can configure the Identity Server to notify the Access Server automatically when user or group information changes. The Access Server's caches are then automatically flushed and updated with new information.
The following topics provide more details on caching:
The following procedure describes how to turn off this cache.
To turn off the user cache
Launch the Access System Console.
Navigate to Access System Configuration, then click Access Server Configuration.
The Access Server Configuration page appears. The name, host, and port of each configured Access Server are listed on this page.
Click the link of the Access Server you want to modify.
On the Details for Access Server page, click Modify.
The Modify Access Server page appears.
Set the value for Maximum Elements in User Cache to -1.
The Identity System and the Access System use different user and group caches. An administrator may perform any of the following operations:
Deactivating a user
Changing user attributes
Deleting a group
Changing a password policy
Changing redirect URLs
After any of the above operations take place, the directory server is updated with the new information. However, the Access Server may be unaware of these changes. For example, if you deactivate a user in Oracle Access Manager, that change should be reflected in the Access System so the user does not have access to its protected resources. To ensure that the Access Server is informed of changes in the Identity System, you can manually flush the Access Server's user cache. Or, you can configure the Identity Server to notify the Access Server of changes to user and group information. The Access Server caches are then automatically flushed and replaced with the latest information.
Note:
The user cache is not automatically flushed when changes are made to group membership through a dynamic filter or through static membership.To flush the Access Server cache automatically
Navigate to IdentityServer_install_dir/identity/oblix/data/common/basedbparams.xml file
where IdentityServer_install_dir is the directory where the Identity Server is installed.
In the basedbparams.xml file, locate the doAccessServerFlush parameter and set it to true.
Restart the Identity Server.
Add a dummy AccessGate using the configureAccessGate command line tool, as follows:
configureAccessGate -i IdentityServer_install_dir/identity/AccessServerSDK -t AccessGate
Confirm that the Access Management Service is turned on for all AccessGates that use this Access Server:
From the Access System Console, click Access System Configuration, AccessGate Configuration, All, Go, click a link for the appropriate AccessGate, Modify.
Set the Access Management Service to On, if needed.
Confirm that the Access Management Service for the Access Server is turned on:
From the Access System Console, click Access System Configuration, Access Server Configuration, click a link for the appropriate Access Server, Modify.
Set the Access Management Service to On, if needed.
Restart the Access Server.
Run the configureAccessGate command for the Identity Server's AccessGate, and check the file ObAccessClient.xml to be sure that the port number contains the listen port that you configured for the AccessGate during installation.
If you choose not to implement automatic cache flushing for the Access Server, the Access Server's caches will contain outdated information until the cache timeout occurs. You can, however, manually flush the Access Server's user and password policy caches in the Access System Console. You can flush stored information on a specific password policy or on all password policies from the Access Server cache. You can also flush cached information on all redirect URLs.
To flush the Access Server's user cache manually
Launch the Access System Console.
Navigate to Access System Configuration, User Access Configuration and click Flush User Cache.
To flush a specific user's profile and group information, click Select User.
The Selector page appears.
To search for a user, enter the name and click Go.
The search results are listed under Selector.
Click Add to select a user, or to select all listed users, click Add All.
The user name is listed under Selected.
Click Done to leave the screen.
The selected user's name appears on the Flush User Cache screen.
Click Flush Cache.
A dialog box requesting confirmation appears.
Click OK to remove the user's cached information; click Cancel if you do not want to remove the user's cached information.
To flush the password policy cache manually
Launch the Access System Console.
Navigate to Access System Configuration, Common Information Configuration and then click Flush Password Policy Cache.
If you changed any information for a password policy, select that policy from the list under Flush All Cached Information for a Specified Password Policy, then click Flush Cache.
For information about the order of password policy evaluation, see the Oracle Access Manager Identity and Common Administration Guide.
To flush all of the password policies, or if you deleted a password policy from the Identity System, then click Flush Cache to delete cached information for all password policies.
If you changed any of the redirect URLs on the Password Policy Management screen, click Flush Redirect URL.
For information about configuring the password redirect URLs, see the Oracle Access Manager Identity and Common Administration Guide.
Click OK to confirm your decision.
When you change data using the Policy Manager, it modifies data in the directory and notifies the Access Server to flush its cache. The Access Server flushes its cache and reads the updated information from the directory server.
In a replicated directory environment, modified data is passed from the master directory server to replicated directory servers. There is a time lag before the modified data is reflected in the replicated directory servers. If the Policy Manager communicates with the master directory server and the Access Server communicates with a replicated directory server, the Access Server may flush its cache and read data before the modified data is reflected in the replicated server. As a result, the Access Server may cache old data. Thus, in a replicated environment, policy evaluation by the Access Server can be incorrect if it is based on old data. Figure 5-2 illustrates a replicated environment.
Process overview: Replication
The Policy Manager modifies data in the master directory server.
The Policy Manager sends a signal to the Access Server to flush its cache.
The Access Server flushes its cache and reads data from the replicated directory server.
Modified data is replicated from the master directory server to the replicated directory server.
To ensure that policy evaluation is accurate and that the Access Server reads the latest data, use the splTimeout parameter. The splTimeout parameter enables you to specify a timeout on the element being modified. It allows for the time lag between replication from the master directory server to the replicated directory server. The splTimeout parameter takes precedence over the cache timeouts specified in the Access Server Configuration page of the Access System Console.
The splTimeout value is specified in seconds.
If you do not specify a value for the splTimeout parameter, the Access Server flushes its cache and reads the data as soon as it receives a flush signal from the Policy Manager. The splTimeout parameter is in the file located in:
AccessServer_install_dir/access/oblix/apps/common/bin/globalparams.xml
where AccessServer_install_dir is the directory where the Access Server is installed.
When you configure an AccessGate, you can specify the maximum number of elements in the cache as well as the cache timeout.
Each AccessGate caches the following information:
Details about an authentication scheme, such as:
How to challenge a user for credentials
Level of the scheme.
For information about creating authentication schemes and their levels, see the Oracle Access Manager Access Administration Guide.
Redirection URL, if any
Protection information about every resource--including the authentication scheme, URL, and operation--that is passed to the AccessGate, such as:
The authentication scheme key
The protected resource's URL
Whether the resource is protected in the system or not
If it is protected, the authentication method required for the resource.
Details about an authorization scheme, such as:
The LDAP user attribute
The parameters specified in the authorization rules of the policy domain
When you configure or modify an authentication or authorization scheme, select Update Cache to update the AccessGate cache immediately with the updated scheme.
The number of URLs for which information is cached can be configured for each AccessGate. With out-of-the-box configuration, URL elements timeout every 30 minutes. When you make any policy changes that may change a URL's protection status or authentication method, select Update Cache to update the AccessGate cache immediately. This means the AccessGate's cache timeout period need not be short.
Assuming the system has sufficient memory, the maximum number of URLs cached should be at least equal to the number of distinct URLs processed by AccessGate in the amount of time specified in the Cache Timeout field.
For example http://www.myserver.com and http://myserver are treated as distinct URLs. If information about a URL is not in the cache, AccessGate makes a request to the Access Server. Fetching information from the Access Server takes longer than fetching information from a local cache, but not significantly longer.
