WSO2 Identity Server has multiple cache layers which are used to improve performance.
The following configuration block found in the
<IS_HOME>/repository/conf/identity/identity.xml file is used to manage and configure the cache layers.
The code block below shows an example of one such cache layer.
Each cache layer contains the following attributes:
The cache name is used to build the cache instance and is unique to a JVM. This name is used as the unique identifier when the carbon kernel creates the cache object for a specific cache requirement.
This parameter is used to enable the cache usage for a specific cache layer. If this parameter is disabled, it means that the feature will not cache the value and depending on the feature, will either persist it in a database or not store it at all at the server level.
To use the feature mentioned below, apply the 5777 WUM update for WSO2 IS 5.2.0 using the WSO2 Update Manager (WUM).To deploy a WUM update into production, you need to have a paid subscription. If you do not have a paid subscription, you can use this feature with the next version of WSO2 Identity Server when it is released. For more information on updating WSO2 Identity Server using WUM, see Getting Started with WUM.
The default timeout value is 1000s. However if you want to use different timeout values, add the following configuration in the
<IS_HOME>/repository/conf/identity/identity.xml file within <CacheConfig> as the first element.
When a cache entry is added to the cache instance, the start time is recorded and the entry is stored until the time exceeds the timeout value. Once the time reaches the timeout, the cache entry is evicted from the cache.
Set this value to -1 to store the cache entry indefinitely.
The capacity is the count of the cache entry. Note that this value is not related to the size of the cache.
This parameter is used to distribute the cache entry over the cluster through Hazelcast. If it is set to false, the cache object is stored only in the local cache.
Disabling the distributed cache triggers the cache invalidation notification system, which notifies all other nodes in the cluster to invalide their local caches when one node is updating its local cache.
The SessionContextCache object contains details about the authenticated user. This must be shared across the nodes in the cluster because this is the unique representation of the authenticated user.
Until the authentication request is successfully authenticated, all authentication information is stored in the AuthenticationContextCache object, which needs to be shared across all nodes in the cluster. Once the user is authenticated successfully, this object will is removed from the cache and the required information is stored in the SessionContext cache.
The AuthenticationRequestCache object holds all the required details from the authentication request until the authentication flow is completed by the authentication framework. Note that this is not from the inbound protocol validator level. The Authentication Framework wraps the information to the AuthenticationRequestCache object and stores it in the cache.
The AuthenticationResultCache object holds the authentication result that contains the authenticated user details, claim mappings and other authentication specific results, and stores this information in the cache. Once the user gets authenticated through the authentication framework, it stores this object in the cache and reads the response from the inbound protocol handler once the response is built.
The AppInfoCache is a complete representation of the OAuth application information in WSO2 Identity Server. It is unique for the client key and is stored in the cache by wrapping the “OAuthAppDO” object.
The AuthorizationGrantCache manages the user information over tokens. This cache object contains the token, code, and user attributes for the authenticated user with some important information that is needed to access different flows such as id-token building.
The OAuthCache is a general cache implementation which is not specific to one type of cache. This is used for the following cache entries with its own specific cache key.
AccessToken: Access Token Detail Object
AuthorizationCode: Authorization Code Detail Object
ClientKey + Username: ClientCredential
The OAuthScopeCache object holds scope information such as the name and display name for each scope.
Once the request is recieved by the inbound protocol validator, it keeps the requested data by wrapping it in the OAuthSessionDataCache object. This is stored against the sessionDataKey, which is used to manage the browser state.