| Oracle® Access Manager Deployment Guide 10g (10.1.4.3) Part Number E12490-01 |
|
|
View PDF |
| Oracle® Access Manager Deployment Guide 10g (10.1.4.3) Part Number E12490-01 |
|
|
View PDF |
A clone is a copy of a component created on a remote system using an already-installed component as a template. The in-memory storage that keeps a copy of recently used information is known as a cache. This chapter contains the following topics:
Configuring Synchronous Cache Flush Requests between Multiple Access Servers
Error Handling for Message Channel Initialization During Cache Flush
A clone is a copy of a component created on a remote system using an already-installed component as a template. This is accomplished by cloning the configuration of an already installed component the configuration of an already installed component instead of using the command line or the installation GUI to install a Oracle Access Manager 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.
Oracle Access Manager retrieves frequently used information from a cache rather than accessing information in the directory server. Caching allows faster information retrieval. To improve performance, Oracle Access Manager uses several different caches for different types of information.
The Oracle Access Manager system (OSD) caches include configuration settings and group information. The Identity and Access Systems contain different caches, as described in "About Identity System Caches and Cache Flushing".
The rest of this section discusses the following topics:
Caching can have an impact on Oracle Access Manager performance due to a number of factors including the number of elements in the cache and the cache timeout.
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 computer 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:
The default cache size for Oracle Access Manager components is sufficient for most installations.
The cache timeout also plays a role in performance during cache flush operations.
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 time period.
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.Table 5-1 identifies the cache timeouts that can be specified for the Identity System.
Table 5-1 Timeout Parameters for Caches for the Identity System
| Identity System Timeout Parameter | Description |
|---|---|
|
GroupCacheTimeout |
Set the period for which the group object is valid, as described in "Managing the Group Objects Cache". |
|
oisClientTimeoutThreshold |
Set the time period for Identity Server cache flush, as described in "Configuring Cache Flush for Identity Servers". |
Table 5-2 identifies the cache timeouts that can be specified for the Access System.
Table 5-2 Timeout Parameters for Caches for the Access System
| Access System Timeout Parameter | Description |
|---|---|
|
Time To Live |
Use this to set the timeout of the cached password on a scheme-by-scheme basis, as described in "Configuring Password Validation by the Access Server". |
|
Group Query Cache timeout |
Previously, this timeout was not configurable, and you could not flush this cache. The cache was cleared only when the cache timeout limit is reached or when you restarted the Access Servers. Today, however, this can be configured as described in "Configuring the Access Server Group Cache Timeout and Maximum Elements". |
|
Policy Cache Timeout |
The Policy Cache Timeout value can be:
|
|
User Cache Timeout |
The User Cache Timeout value can be:
|
|
WebGate Cache Timeout |
The WebGate Cache Timeout value can be:
|
|
Cache timeout for WebGate and Access client configurations |
There are two ways to reduce off-time network traffic between both the WebGate and Access Server, and the Access Server and the LDAP directory server:
|
Identity Servers can communicate with one another and 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 System has several caches. Each can receive a cache flush request if data is modified, as described in Table 5-3. The Identity System and the Access System use different user and group caches. See the Access System caches in Table 5-6.
Table 5-3 Identity System Caches and Cache Flush Operations
| Identity System Cache | Description | Cache Flush |
|---|---|---|
|
Configuration Data Also known as system data or Oracle Access Manager-specific data (OSD) |
Includes object classes, attributes, tabs, and panels. |
Automatic when configuration data is modified Alternatively, you can clear the cache as described in "Managing Identity System Caches". |
|
Basic Configuration Data Entered in Setup |
Contains the configuration base (configuration DN) and searchbase. |
Automatic when basic configuration data is modified |
|
Group Objects |
Contains group details specified in the Group Manager. |
Automatic when a group is modified Alternatively, you can explicitly request a cache flush as described in "Managing the Group Objects Cache". |
|
Name Cache also known as UidInfoCache |
Contains the DNs of user and group objects. Is flushed whenever DNs itself or attribute like name, flags get modified objects |
Automatic when the DNs or attribute flags (name, for example) are modified |
|
Access control cache |
Contains resource operations, searchbase, and the like |
Automatic when ACL or searchbase is modified |
|
Auditing Cache |
Contains information about master audit policies, message format, and so on |
Automatic when a change occurs in master audit policies, message format, and so on |
|
Workflow Cache |
Contains workflow definitions and participants |
Automatic when a workflow is modified |
|
User-Defined Portal Inserts |
Contains portal insert backurls, images used for buttons, and mouseover text |
Invoked explicitly through a URL, as described in the Oracle Access Manager Customization Guide. |
For details about managing Identity System caches, see "Managing Identity System Caches".
The Access System caches information on password policies, policy domains, user credentials, and authentication schemes. Some operations performed in 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. For more information, see "About Access System Caches".
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.
The following topics provide details:
You must be a Master Administrator to view, reload, or clear the OSD cache. The following topics provide more details on managing the system cache:
You must be a Master Administrator to view 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.
This procedure describes how to clear the OSD cache. You must clear the OSD cache before you reload it to update existing information. You must be a Master Administrator to clear the OSD cache.
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 procedure describes how to load the OSD cache. You must be a Master Administrator to reload the OSD cache.
Note:
You must first clear the cache and then reload the information.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.
This section includes the following topics:
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
Go 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-4.
Table 5-4 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 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 entire group cache through the Identity System Console, as described in the following procedure. Alternatively, a Master Identity Administrator can clear the group cache with an Identity XML function named flushGroupCache. For details about this method, see the IdentityXML chapter in the Oracle Access Manager Developer Guide.
To clear group caches from the Identity System Console
From the Identity System Console, click the Group Manager Configuration tab.
On the Group Manager Configuration page, click Group Cache.
On 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.
Identity Server cache flush is accomplished with the oisClientTimeoutThreshold parameter in the globalparams.xml file. By default, cache flush for Identity Servers is synchronous and occurs every 60 seconds. However, you can set the parameter to flush the Identity Server cache asynchronously, as shown in Table 5-5.
Table 5-5 oisClientTimeoutThreshold Values in globalparams.xml
| Value | Description |
|---|---|
|
60 |
By default, cache flush for Identity Servers is synchronous and occurs every 60 seconds |
|
-1 |
Triggers asynchronous Identity Server cache flushing |
|
No value |
Triggers asynchronous Identity Server cache flushing |
|
No parameter at all |
Triggers asynchronous Identity Server cache flushing |
In synchronous mode, the Identity Server sends a cache flush request and waits for a response. In asynchronous mode, the Identity Server does not wait for a response.
To configure cache flush for Identity Servers
Locate the following file:
IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xml
Set the oisClientTimeoutThreshold parameter using the guidelines in Table 5-5.
Save the file.
Repeat these steps for each Identity Server.
If your deployment does not include the Access System, you can skip this section.
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.
The following topics provide more information about Access System caches:
Performance Improvements Using Asynchronous vs. Synchronous Cache Flush Mode
Performance Improvements Using Mixed-Mode Communication for Cache Flush Operations
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.As seen in Table 5-6, the Access System caches data on policy domains, policies, users, host identifiers, and password policies. When information is updated for any of these, and the Update Cache box is checked, the Access Server caches are updated immediately.
Table 5-6 Access System Caches and Cache Flush Operations
| Access System Caches | Description | Cache Flush |
|---|---|---|
|
Access Server Cache |
||
|
Policy cache |
Contains information for policy domains, policies, authentication rules, authorization rules, audit rules, actions associated with rules, policy conditions for rules, and authentication schemes. For more information, see "Tuning the Policy Cache". |
Automatic when any policy configuration changes and Update Cache is selected |
|
Access Server user data cache |
Contains information from the user profile that is required in both actions and rule-based access evaluation.Also included in this cache is the user's group-membership status (whether a user is member of a group or not, for example). For more information, see "User Cache Tuning" |
When OIS notifies AAA |
|
URL Prefix Cache |
If a URL prefix is added to a policy domain or policy, it is updated if Update Cache is selected. For more information, see "Tuning the URL Prefix Cache" |
Automatic if Update Cache is selected. |
|
Host identifier cache |
Contains host identifiers |
Automatic if Update Cache is selected. |
|
Password policies cache |
Contains password policies |
Automatic if Update Cache is selected. |
|
WebGate Cache |
Contains authentication scheme details, such as how to challenge a user for credentials and the Level of the scheme. Redirection URL, if any Protection information about every resource--including the authentication scheme, URL, and operation--that is passed to the AccessGate, such as:
Details about an authorization scheme, such as:
|
Cache flush depends upon the value set for the WebGate cache timeout. For more information, see "AccessGate Cache Configuration" |
The following topics provide additional information:
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.
Cache Timeout: 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 the update cache 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. This is an important parameter because it ensures that after some time span the changes are saved in case any unwanted internal or external event occurs.
Maximum Elements: If the Access Server host has sufficient memory to hold all the configured policy information, the maximum elements should be set according to the maximum of the 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 the:
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 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. Parts of a user profile that are relevant to the Access System include:
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 time period.
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. To configure the Identity Server to notify the Access Server when user information changes, you can set the doAccessServerFlush parameter in the Identity Server's basedbparams.xml file: IdentityServer_install_dir/identity/oblix/data/common. This is currently supported only for user information, not for groups. For more information, see the parameters chapter of the Oracle Access Manager Customization Guide.
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
An Access Administrator uses the Policy Manager to modify 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, add the splTimeout parameter. This parameter enables you to specify a timeout (in seconds) 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.
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 located in the globalparams.xml file in:
AccessServer_install_dir/access/oblix/apps/common/bin/globalparams.xml
where AccessServer_install_dir is the directory where the Access Server is installed.
To ensure policy evaluation is accurate in a replicated environment
On the computer hosting the primary Access Server, locate the globalparams.xml file. For example:
AccessServer_install_dir/access/oblix/apps/common/bin/globalparams.xml
Open the file and add the splTimeout parameter. For example:
<SimpleList>
<NameValPair
ParamName="splTimeout"
Value="400"></NameValPair>
</SimpleList>
Save the file.
Restart the Access Server.
Repeat this procedure for each Access Server in your deployment.
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.
Access Server and system performance are enhanced by caching information, which eliminates the need to read information in the directory server for each request. When relevant information is updated and "Update Cache" is enabled, the Identity Server sends a cache flush request to the primary Access Server through the Access Manager SDK. The primary Access Server in turn sends the same cache flush request to all Access Servers directing them to flush the corresponding entry from their cache.
Flush user cache
Flush password policy
Flush password redirect URLs
Flush lost password management policy
Previous releases of Oracle Access Manager used a synchronous mode for cache flush requests from Identity Servers to Access Servers. With synchronous mode the Identity Server sends a cache flush request to the primary Access Server and the Identity Server does not proceed until it receives a response.
Note:
A similar situation occurs when the Policy Manager sends a cache flush request to the Access Server. For example, if a policy is enabled or disabled within the Policy Manager, this generates a cache flush request to the Access Server.However, any delay in the system causes a delay for the user. Further, if the response is not received within the set OISTimeoutThreshold, WebPass resends the request to the Identity Server which starts the cache flush cycle anew. If WebPass keeps resending the same requests to the Identity Server this could lead to a no-response situation for the end user.
Oracle Access Manager 10g (10.1.4.3) provides an asynchronous cache flush option to help streamline performance and avoid delays associated with synchronous cache flush operations on the Access System. The flow of information is the same whether you use the synchronous or asynchronous method. With the asynchronous method, however, the thread does not wait for a response from the Access Server before notifying the Identity Server. Instead, the request arrives at the Access Server and a response is sent immediately to the Identity Server.
You can use either the synchronous or asynchronous cache flush method by setting the value of syncOperationMode in the AccessGate configuration in the Access System Console. For more information about using the asynchronous cache flush method, see "Configuring Asynchronous Access System Cache Flush".
You can further enhance performance during Access System cache flush operations using a mixed-security mode for communication between Oracle Access Manager components, as described next.
This section provides the following topics:
When installing and configuring Oracle Access Manager, specific transport security guidelines must be observed. The transport security guidelines within the chapter on preparing for installation in the Oracle Access Manager Installation Guide correctly state that:
Transport security between all Identity System components (Identity Servers and WebPass instances) must match: either all open, all Simple mode, or all Cert mode.
Transport security between all Access System components (Policy Managers, Access Servers, and associated WebGates) must match: either all open, all Simple mode, or all Cert mode.
When cache flushing is enabled on the Identity Server, the Identity Server communicates with the Access Server. In this case, the transport security mode between all Oracle Access Manager components must be the same.
Oracle Access Manager 10g (10.1.4.2.0) provided a method that enabled you to use Open mode communication for cache flush requests between the Identity and Access Server while retaining Simple or Cert mode for all other requests. This type of configuration is known as mixed security mode (or mixed transport security mode) communication.
Oracle Access Manager 10g (10.1.4.3) provides a streamlined method to implement mixed-mode communication for cache flush requests.
Note:
Cache flush requests do not contain sensitive data. During cache flush operations, only the LDAP configuration is read. As a result, Open mode communication is appropriate for cache flush requests. With mixed security mode communication, all except cache flush requests use Simple or Cert mode for secure communications.With user or group modifications, the user or group DN is sent through the cache flush request. For policy modifications, the cache flush request contains the policy identifier.
For details about configuring mixed-mode communications, see "Enhancing Performance by Configuring Mixed-Mode Communication for Access Server Cache Flush Operations".
When you install and configure an Identity Server, the Access Manager SDK is also deployed automatically. The Access Manager SDK is responsible for sending cache flush requests to the Access Server after user and group profiles are modified through Identity XML. In this case, an XML request is sent to the Identity Server through WebPass. If Access Server cache flush is enabled when the Identity Server processes the request, the Identity Server sends a cache flush request to the Access Server through the Access Manager SDK and the cache is flushed.
To enable Access Server cache flush, you must set the doAccessServerFlush parameter to true in the IdentityServer_install_dir/identity/ oblix/data/common/basedbparams.xml file. This enables the Access Manager SDK to send requests to flush the Access Server cache. When you do this, Access Server caches are automatically flushed and replaced with the latest information. This is a best practice to ensure that all components have up-to-date information. For details, see "Automatically Flushing Access Server Caches".
However, even though the automatic cache flush is a best practice, it can cause performance issues if you have multiple Access Servers that use a secure communication mode. Performance issues can occur when:
There are frequent cache flush requests when the Identity System performs IdentityXML operations to modify a user or group profile.
There is an SSL handshake for each request to each Access Server that is configured in Simple or Cert transport security mode.
The SSL handshakes that are required in a secure multi-server environment can impede performance.
Using the latest Oracle Access Manager procedures, you can prevent bottlenecks and preserve system performance while enabling automatic cache flush and secure communications. For more information, see "Configuring Asynchronous Access System Cache Flush".
Asynchronous cache flush operations enable the Identity System to contact the Access Server in asynchronous mode through the Access Manager SDK when there are changes to user and group information. For more information, see "Configuring Asynchronous Access System Cache Flush".
If your deployment does not include the Access System, you can skip this section.
This section provides the following procedures and information:
The following procedure describes how to turn off the Access Server user cache. You must be a Master Access Administrator to perform this task.
Turning off this cache reduces memory consumption. However it could also result in decreased efficiency in some cases. For example, when requests to the Access Server are frequent.
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.
Save your changes.
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. Alternatively, 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. For automatic Access Server cache flush, you must set the doAccessServerFlush parameter in the Identity Server's basedbparams.xml file as described in Table 5-7.
Table 5-7 doAccessServerFlush parameter in basedbparams.xml
| Value | Description |
|---|---|
|
true |
Enables automatic Access Server cache flush. |
|
false |
Disables automatic Access Server cache flush. Note: This is the default. |
|
No value |
The default value, false, is presumed. Disables automatic Access Server cache flush. |
|
No parameter |
The default value, false, is presumed. Disables automatic Access Server cache flush. |
Note:
The user cache is not automatically flushed when changes are made to group membership through a dynamic filter or through static membership. Also, when you deactivate a user you must also disable the credential mapping cache. For details, see "Managing the Credential Mapping Cache"The Access Management Service must be On when Access Manager SDK-complied code is used to connect to the Access Server. Features like automatic cache flush use the SDK that is bundled with the Identity Server. For automatic cache flushing, ensure that the Access Management Service is On in the configuration profiles of associated AccessGates and Access Servers. The Access Management Service should be Off if only WebGates are associated with an Access Server.
Note:
TheUserMgmtNodeEnabled parameter in the Access Server globalparams.xml file controls the enabling and disabling of a feature that manages WebGate memory growth. This feature is intended for Access Systems that maintain a very high number of cache flush operations per second. For more information on this parameter, see the chapter on parameters in the Oracle Access Manager Customization Guide.Synchronizing Changes in the Directory Server: Any modification in a user profile or policy information is updated in the directory server. A global sequence number is updated in the directory server to track the latest changes. Before a cache flush, the Access Server checks for the number. However, if your environment includes more than one directory server, it is possible that the number for corresponding entries could be out of sync. For more information, see information on managing sync records in the Oracle Access Manager Access Administration Guide.
To flush the Access Server cache automatically when relevant changes occur
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.
<NameValPair ParamName="doAccessServerFlush" Value="true"/>
Confirm that the Access Management Service is On for AccessGates associated with this Access Server:
From the Access System Console, click Access System Configuration, AccessGate Configuration, All, and click Go.
From the resulting list, click a link for the appropriate AccessGate, and then click Modify.
Set the Access Management Service to On, if needed, and then click Save.
Confirm that the Access Management Service for associated Access Servers is On:
From the Access System Console, click Access System Configuration, Access Server Configuration.
From the resulting list, click a link for the appropriate Access Server, and then click Modify.
Set the Access Management Service to On, if needed, and then click Save.
Restart the Identity Server.
Restart the Access Server.
Add a dummy AccessGate using the configureAccessGate command line tool, as follows:
configureAccessGate -i IdentityServer_install_dir/identity/AccessServerSDK -t AccessGate
Check the ObAccessClient.xml file to confirm that the port number contains the listen port that you configured for the AccessGate during installation:
IdentityServer_install_dir/AccessServerSDK/oblix/lib/ObAccessClient.xml
If you implemented automatic cache flushing for the Access Server, you can skip this topic.
If you did not implement automatic cache flushing for the Access Server, these caches contain outdated information until the cache timeout occurs. However, you can 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.
The following topics provide details:
You perform this task when you have multiple Access Servers and, due to an error or a crash, these servers get out of sync. You must be a Master Access Administrator to perform this task.
To flush the Access Server's user cache manually
Launch the Access System Console.
Go 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.
You perform this task when you have multiple Access Servers and, due to an error or a crash, these servers get out of sync. You must be a Master Access Administrator to perform this task.
To flush the password policy cache manually
From the Access System Console, click 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.
By default, the credential mapping cache is enabled. In this state, the plug-in uses the cached credentials for the user.
When a user is deactivated, the Identity Server does not automatically flush the Access Server credential mapping cache. To deny a deactivated user access to protected resources you must manually disable 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).
If you deactivate a user who is logged in, the user still has access to resources based on policy information and prior authentication. However, if you disable the credential mapping cache, when the user's session token expires or she logs out, she is not allowed access to a protected resource the next time she is authenticated.
To disable use of the credential mapping cache, you set the obEnableCredentialCache parameter to false in the credential_mapping plug-in. Table 5-8 shows the possible values for the parameter.
Table 5-8 Parameters for obEnableCredentialCache in the credential_mapping Plug-in
| Value | Meaning |
|---|---|
|
no value |
Credential mapping cache turned on |
|
true |
Credential mapping cache turned on |
|
false |
Credential mapping cache turned off |
The following example shows 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.
Oracle Access Manager 10g (10.1.4.3) provides a new function that enables you to set a wait period for sockets during synchronous cache flush requests between multiple Access Servers. This section includes the following topics:
If syncOperationMode cache flush mode is not configured, by default all cache flush requests are asynchronous. For more information about using the asynchronous cache flush method, see "Configuring Asynchronous Access System Cache Flush".
Note:
The Access Server is used to illustrate the information in this topic. However, this topic applies equally to Policy Manager and Access Manager SDK communication and Access Server and WebGate communication.Message channels are used to manage TCP/IP communication between a WebGate and Access Server (or Policy Manager and Access Manager SDK). The Access Server also uses message channels to communicate with other Access Servers for cache flush requests.
Message channels use sockets for TCP/IP communication. Sockets are the end points of TCP/IP communication that are encompassed in a message channel. Two types of wait periods can be specified for sockets during cache flush operations:
Indefinite wait period
Earlier releases of Oracle Access Manager used an indefinite wait period for cache flush requests between the WebGate and Access Server. (a socket waits an infinite amount of time for I/O completion). In this case, the primary Access Server waits indefinitely to receive a response from peer Access Servers. If an Access Server hangs, other Access Servers are not sent the cache flush request. With synchronous cache flush request processing, the Identity Server would also hang until the response was received.
Limited wait period
You can configure a specified time period for I/O completion. If the expected operation is not completed within the specified time, an error is reported and the request is sent to other Access Servers. With synchronous requests, WebPass and Policy Manager does not hang if one Access Server hangs.
Note:
If an Access Server hangs, the cache flush request is sent to other Access Servers and an error is logged.Oracle recommends defining a specific wait period for synchronous cache flush requests based on your environment. By default, the Access Server and Policy Manager wait indefinitely. You can limit this period by setting a positive integer value for the CacheFlushTimeOut parameter in the globalparams.xml file of the respective component (Access Server or Policy Manager). Values are specified in seconds, and then converted into milliseconds.
Note:
TheCacheFlushTimeOut parameter should be tuned based on your deployment environment.Table 5-9 describes this parameter and possible values.
Table 5-9 CacheFlushTimeOut parameter in globalparams.xml
| Value | Description |
|---|---|
|
Positive integer (10, for example) |
The number of seconds to wait for a response from a peer Access Server. Note: If specified, this timeout value is multiplied by 1000 (converted to milliseconds) and assigned to the Access Server client object. |
|
Negative integer (-10, for example) |
Presume the default. Note: A value of less than zero is the same as no value or no parameter. |
|
No value |
Presume the default. |
|
No parameter |
Presume an indefinite wait period. This is the default. |
With a wait period specified, the following WARNING level log message occurs in the primary Access Server log file:
Cache Flush failed. Failed AAA server list= (List of Access Servers that are down)
For more information, see:
Configuring Synchronous Cache Flush Requests Between Multiple Access Servers with a Wait Period for steps to configure the wait period for cache flush operations
Error Handling for Message Channel Initialization During Cache Flush for details about error handling when a closed socket is encountered
The CacheFlushTimeOut parameter should be tuned based on your deployment environment. You must be a Master Access Administrator to perform this task.
For synchronous cache flush requests originating from the Access Manager SDK, you must add the CacheFlushTimeOut parameter to the globalparams.xml file for each Access Server.
For synchronous cache flush requests originating from the Policy Manager, you must add the CacheFlushTimeOut parameter to the Policy Manager's globalparams.xml file.
To set a time period to wait for cache flush requests
On the computer hosting the primary Access Server, locate the globalparams.xml file. For example:
AccessServer_install_dir/access/oblix/apps/common/bin/globalparams.xml
Open the file and add the CacheFlushTimeOut parameter under the UserMgmtNodeEnabled section. For example:
<SimpleList>
<NameValPair
ParamName="UserMgmtNodeEnabled"
Value="False"></NameValPair>
</SimpleList>
<SimpleList>
<NameValPair
ParamName="CcheFlushTimeout"
Value="10"></NameValPair>
</SimpleList>
Save the file.
Restart the Access Server.
Repeat this procedure for each Access Server in your deployment.
Repeat this procedure for cache flush requests originating from the Policy Manager by editing the Policy Manager's globalparams.xml file.
Message channels are used to manage TCP/IP communication between WebGate and Access Server, and between Access Servers for cache flush requests. The message channel runs as a separate thread. The message channel initializes itself through a handshake with the peer Access Server. When the handshake is completed, a message is sent to the Access Server. This applies to all requests when a message channel is used with a set time period.
If an Access Server hangs during a cache flush operation, message channel initialization fails and the socket is closed. Components cannot read over a closed socket.
In earlier releases of Oracle Access Manager, operations persisted over a closed socket even if when message channel initialization failed. This resulted in socket errors. However, Oracle Access Manager 10g (10.1.4.3) enhances the network layer shared by WebGate and Access Server. As a result, errors that might occur as a result of message channel initialization failure due to a closed socket are avoided. Today, the message channel stops sending and receiving messages and a WARNING level log message is recorded.:
Warning Level Error message: "Error performing socket operations"
Web Gates and Access Servers are now are resilient if an Access Server hangs during a cache flush request, even when synchronous cache flush requests with a specified time period.
Two methods are provided that enable you to enhance system performance by configuring mixed-mode communication between the Identity Server and Access Server during cache flush operations. This section provides the following topics:
Method 1: Manual Access Server Configuration for Open Mode Cache Flush Requests
Logging and Cache Flush Operations Using Mixed Mode Communication
This topic contains the following discussions:
Configuring Access Servers Manually for Mixed Mode Transport Security
Modifying WebGates After Manually Enabling Mixed Security Modes With Method 1
One method that enables you to use Simple or Cert transport security for all requests except cache flush requests was made available starting with Oracle Access Manager 10g (10.1.4.2.0). This method was described in the Oracle Access Manager Patchset Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems.
To enhance performance and simplify the routing of requests among components, you can designate a single Access Server to handle all cache flush requests. When a particular Access Server is designated to receive a cache flush request, it sends the same cache flush request to all remaining Access Servers on receipt of the request. You can ensure that Open mode communication is used when the dedicated Access Server sends cache flush requests and you can retain Simple or Cert mode for other types of requests.
Despite changing the security mode to Open for cache flush requests, as long as you initially configure the Access Servers in Simple or Cert mode, the Access Manager SDK or WebGate still communicates with the Access Servers in Simple or Cert mode. This enables you to preserve security for most operations.
The ability to configure an Access Server to use Open mode for some operations and a secure mode for other operations is known as a mixed security mode.
The following task overview describes how to configure your environment to handle cache flush requests using Open mode while retaining secure communication for other types of requests.
Task overview: Manually configuring Access Servers for Open mode cache flush requests while maintain secure communication for other requests
Install Access Servers in Simple or Cert mode (or upgrade your deployment and configure all Access Servers to use Simple or Cert mode).
See Oracle Access Manager Installation Guide or the Oracle Access Manager Upgrade Guide for instructions.
Designate one Access Server or a cluster of Access Servers to handle all cache flush requests using related items in the Access Server Configuration pages.
You can designate one Access Server for all flush requests from the Identity side by listing only one primary server for the AccessGate serving the Access Manager SDK. From the AccessGate Configuration page, choose a name and click Modify. From the Details for AccessGate page, click List All Access Servers and confirm that there is only one for the AccessGate. For more information about Access Server and AccessGate configuration, see the Oracle Access Manager Access Administration Guide.
Note:
For cache flush requests from the Policy Manager, you cannot designate a particular Access Server to receive the request. Policy Manager sends cache flush requests to all available Access Servers it locates through the LDAP directory server.Configure WebGates and AccessGates to communicate with their respective Access Servers using Simple or Cert mode.
Convert all of the Access Servers to mixed transportation security mode either method 1 or method 2.
Review the following topics, and perform tasks when needed:
The following important conditions apply when you choose method 1 and enable mixed security mode communication manually.
After you configured mixed security mode communication, you might receive the following message when you view a list of Access Servers associated with a particular WebGate:
"Not Responding Transport security mismatch".
You can safely ignore this message. However, there is a second condition.
After configuring mixed security mode manually using method 1, you must follow a specific method to modify an AccessGate or WebGate. Otherwise, WebGate could not contact the Access Server when running the configurewebgate or configureaccessgate tool. Specifically, when you attempted to modify an AccessGate or WebGate, all previous Preferred HTTP Host settings were removed. To avoid this issue after configuring Access Servers using method 1, perform the task in "Modifying WebGates After Manually Enabling Mixed Security Modes With Method 1".
The following procedure describes how to configure Access Servers to use Open transport security for cache flush requests, and SSL or Cert transport security for all other requests. This is useful when you have implemented automatic cache flush in an environment that primarily uses secure communication, as described in the chapter on caching in the Oracle Access Manager Deployment Guide.
Note:
Your deployment must be 10g (10.1.4.2.0) or later.You start this procedure by ensuring that every Access Server is configured to use either Simple or Cert mode for communication and that all WebGates or AccessGates communicate with all Access Servers in Simple or Cert mode. You then configure all Access Servers to use Open transport security mode and restart them. After restarting Access Servers, they retain the certificates required for secure communications and continue to send and receive most information using Simple or Cert mode. However, these Access Servers now use Open mode for cache flush requests.
To configure Access Servers manually to use mixed security mode: method 1
Ensure that your deployment is configured for secure communications (either Simple or Cert mode) according to transport security guidelines in the "Preparing to Install" chapter of the Oracle Access Manager Installation Guide.
Transport Security: either Simple or Cert
For details, see the Oracle Access Manager Access Administration Guide.
Run the configurewebgate or configureaccessgate tool to configure all WebGates (and AccessGates) to communicate with all Access Servers in the same secure mode.
For details, see the Oracle Access Manager Access Administration Guide.
From the Access System Console, modify every Access Server configuration to change the mode from Simple or Cert to Open. For example:
Transport Security: Open
Restart the Access Servers to enable them to use Open mode for cache flush requests.
Repeat Steps 3 and 4 for all Access Servers.
To modify an AccessGate or WebGate after performing steps 1-5, see "Modifying WebGates After Manually Enabling Mixed Security Modes With Method 1".
Use the following procedure to avoid issues described in "Caveats and Conditions for Method 1".
To modify an AccessGate or WebGate after manually enabling mixed transport security mode using method 1
Before modifying the AccessGate or WebGate, from the Access System Console reconfigure all Access Servers to use a secure transport security mode.
Transport Security: either Simple or Cert
Modify the AccessGate or WebGate as needed.
From the Access System Console, reconfigure all Access Servers to use Open mode for transport security.
Transport Security: Open
Restart the Access Servers.
While Method 1 remains valid, 10g (10.1.4.3) provides a new method to enable mixed mode communication. This new method streamlines your effort and avoids some of the issues associated with Method 1.
The following topics describe Method 2:
Oracle Access Manager 10g (10.1.4.3) provides automatic mixed mode communication with the setAccessFlushInOpenMode parameter in the globalparams.xml of the Access Server and Policy Manager (to flush the policy cache in Open mode).
If the parameter is absent from the file, or if it is set to "true", a cache flush message channel is created in Open mode to improve performance for cache flush requests. Otherwise, the configured transport security of the Access Server or Policy Manager are used, as follows:
Table 5-10 setAccessFlushInOpenMode for Automatic Mixed-Mode Communication
| Status | Description |
|---|---|
|
No parameter |
Parameter is consider to be " |
|
True |
Open mode is used for all Access Server cache flush requests. This is the default. |
|
False |
The transport security mode specified in the Access Server Configuration page (or during Policy Manager setup) is used for cache flush and all other requests. |
Task overview: Enabling automatic mixed mode communication for Access System cache flush operations
Confirm that your 10g (10.1.4.3) deployment is configured for secure communications (either Simple or Cert mode) according to transport security guidelines in the "Preparing to Install" chapter of the Oracle Access Manager Installation Guide.
Transport Security: either Simple or Cert
For details about setting transport security, see the Oracle Access Manager Access Administration Guide.
Automatic Mixed Mode: Leave the globalparams.xml file as is. Automatic mixed mode communication for Access Server and Policy Manager cache flush operations is enabled by default.
Disable Automatic Mixed Mode Security: In the globalparams.xml file for the component, set setAccessFlushInOpenMode to "false", as described in "Using Method 2 for Automatic Mixed Mode Security with Access System Cache Flush Requests".
By default, automatic mixed mode security for Access System cache flush operations is enabled in 10g (10.1.4.3).
Note:
To disable automatic mixed mode and use the configured transport security, setsetAccessFlushInOpenMode to "false".To enable or disable automatic mixed mode security for Access System cache flush requests
Ensure that your deployment is configured for secure communications with Simple or Cert mode according to the transport security guidelines in the "Preparing to Install" chapter of the Oracle Access Manager Installation Guide.
Automatic Mixed Mode Security: Take no action.
Disable Automatic Mixed Mode Security (optional): For each Access Server and Policy Manager perform the following steps.
On the computer hosting the Access Server, locate the globalparams.xml file in the following directory path:
component_install_dir\access\oblix\apps\common\bin\globalparams.xml
At the end of the file, add the setAccessFlushInOpenMode parameter with a value of false. For example:
<SimpleList>
<NameValPair
ParamName="UserMgmtNodeEnabled"
Value="False"></NameValPair>
</SimpleList>
<SimpleList>
<NameValPair
ParamName="setAccessFlushInOpenMode"
Value="False"></NameValPair>
</SimpleList>
</CompoundList>
Restart the Access Sever so that the modified value takes effect (parameters in this file are read only once, when the Access Server is started).
Repeat for all Access Servers.
Repeat for all Policy Managers.
This topic includes the following discussions:
The Oracle Access Manager logging feature enables you to analyze system performance and health, and to troubleshoot issues. You set up logging by editing a configuration file that is stored with each instance of a component. To set up logging for Access Servers, locate and edit the following file for each Access Server instance:
AccessServer_install_dir\access\oblix\config\oblog_config.xml
Important:
Do not change the default path or name of the log configuration file.The configuration file contains XML statements that you can edit using a text editor. Each default, the log configuration file contains comments and samples that you can use when creating your own configuration.
You can send log output to a system log or a file using the LOG_WRITER parameter:
A log file resides under the root installation directory of the component.
The system file of the host for the component.
If more than one component resides on the same host, all components send data to the system log file on that host.
You can send logs of a particular level, or logs of different levels, to more than one type of log writer. For instance, you can send Fatal data to the system log, and send Debug data to a file. Or, you can send Fatal data to both the system log and a file.
A complete definition for your log output includes a LOG_WRITER value and a LOGLEVEL. This complete definition is known as a log-handler. An example is shown here:
<!--Write all Debug logs to the system logger. -->
<ValNameList xmlns="http://www.oblix.com" ListName="LogDebug3Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_DEBUG3" />
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
LOGLEVEL_DEBUG3 records a large amount of data that is useful for debugging a performance-sensitive function. Using LOGLEVEL_DEBUG3 and flushing a cache by modifying user or policy information records a message in the output file. If the cache flush request between Access Servers was sent in Open mode with other requests using the configured mode (also known as mixed mode), each Access Server log file includes the following message:
Cache flush request to all AAA servers will be in open mode
If this message is not present in the Access Server log, then mixed mode was not used for the cache flush request. Instead, the configured transport security mode for that Access Server was used.
When you save changes to the log configuration file, they are picked up every 60 seconds automatically. For more information, see the chapter on logging in the Oracle Access Manager Identity and Common Administration Guide.
You use the following procedure to enable cache flush logging to capture mixed mode communication methods.
To enable logging for cache flush operations
Locate the Access Server log configuration file, as follows:
AccessServer_install_dir\access\oblix\config\oblog_config.xml
Open the file with a text editor and set the LOGLEVEL_ to DEBUG3:
<!--Write all Debug logs to the system logger. -->
<ValNameList xmlns="http://www.oblix.com" ListName="LogDebug3Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_DEBUG3" />
Define the LOG_WRITER output location. For example:
<ValNameList xmlns="http://www.oblix.com" ListName="LogDebug2Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_DEBUG3" />
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
Save the file.
Test logging by modifying user or policy information, as usual.
Check the log output for the message that indicates mixed mode communication.
Cache flush request to all AAA servers will be in open mode
If your deployment does not include an Access System, you can skip this section.
You must be a Master Access Administrator to perform tasks in this section. This section includes the following topics:.
Oracle Access Manager 10g (10.1.4.3) provides new parameters to enable asynchronous cache flush operations between the Identity Server and Access Server. The following Access Server caches are flushed:
Flush user cache
Flush password policy
Flush password redirect URLs
Flush lost password management policy
The syncOperationMode" parameter value in the AccessGate Configuration determines whether you have synchronous or asynchronous cache flush operations, as shown in Table 5-11. By default, this parameter value is false.
Table 5-11 syncOperationMode parameter in the AccessGate Configuration
| Value | Description |
|---|---|
|
true |
Enables synchronous Access Server cache flush. |
|
false |
Enables asynchronous cache flush operations; disable synchronous Access Server cache flush. This is the default. |
|
No value |
Presumes the default, false. Enables asynchronous cache flush operations; disable synchronous Access Server cache flush. |
|
No parameter |
Presumes the default, false. Enables asynchronous cache flush operations; disable synchronous Access Server cache flush. |
You must be a Master Access Administrator to perform this task. This task is performed for Access Server and Access Manager SDK communication
To enable asynchronous cache flush operations between the Identity and Access Servers
From the Access System Console, click Access System Configuration, AccessGate Configuration
Click All, click Go, then click a link for the appropriate AccessGate and click Modify.
In the section for User-Defined Parameters, enter the following parameter and value:
Parameters: syncOperationMode
Value: true
Click Save.
|
 Copyright © 2000, 2009, Oracle. All rights reserved. Legal Notices |
|