Access Control Caching
Search Tips
| Advanced Search
This section provides information about cache settings for access control.
Access Control internally uses several caches to increase access control decision times. We can improve access control performance for special scenarios by setting the lifetime and size properties of these caches in the Cache Manager Service. In most cases, WebSphere Portal will run smoothly with the default cache settings. However, if you have a large number of resources or a large number of customized resources, you may want to change the cache settings to see if we can improve performance; see Performance tuning of Portal Access Control for access control performance considerations.
Cache Invalidation Behavior
In most cases, all necessary access control caches are immediately invalidated when a change to the access control configuration is done such as, but not limited to, assigning roles to a user. If using External authorization, it is not possible to permanently synchronize the caches with changes to externally managed roles. For users that already have an authenticated portal session when the change becomes valid, they must wait for a cache timeout or logout and re-login for the changes to become active for that user. Performing a login or logout always enforces the invalidation of all caches related to the current user.
There are three additional cases where the invalidation is not performed immediately and require the user to re-login or to wait for a cache timeout:
- If a role assignment is granted to or revoked from a user group, the change of permissions is not propagated immediately to those members of this group that are currently logged in
- If a role block is set or removed, the resulting change of permissions is not propagated immediately to those users currently logged in
- If nested groups are enabled and group A is added or removed from group B, the permission changes are not propagated immediately to those members of group A that are currently logged in
As in the external case, we can enforce a permissions refresh by performing a logout and re-login for the user. Alternatively, modify the following properties in the file...
/config/services/CacheManagerService.properties
...to influence the caching behavior:
Member Manager Group Caching
Besides the access control caches, we can cache group membership information within the Member Manager component; see Member Manager for information. The Member Manager group cache is invalidated independently from the access control cache, which can cause a delay in the updating the group membership information. There is no explicit invalidation process triggered during login; therefore, changes done to group membership outside of the Member Manager (done directly to the LDAP) will only be visible after a cache timeout. We can only use group caching when you configure Member Manager against an LDAP server using the following parameters in the <ldaprepository> tag, located in the portal_server_root/wmm/wmm.xml file:
- cacheGroups
- This parameter is mandatory to enable group caching. true means the groups cache is enabled; false means it is disabled. If the parameter is not present in the wmm.xml file, group caching is disabled. The groups cache is disabled by default.
Since the groups cache needs to cache all groups in the Member Manager scope, it may cause memory problems if there is a large number of groups. If there are more than 5000 groups in the Member Manager scope, IBM recommends you disable the groups cache.
- groupsCacheTimeout
- This parameter specifies how frequently the groups cache should be refreshed. The value for this parameter is defined in seconds. This is an optional parameter. The default value is 600 seconds. Use "-1" to only refresh the cache when there are changes to groups in the Member Manager.
- groupsCacheSize
- This parameter defines the maximum size for the groups cache. This is an optional parameter. The default value is 10000.
It is not necessary to add this parameter unless you have more than 10000 groups in the Member Manager scope on the LDAP server.
Related information