WAS v8.5 > Secure applications > Authorizing access to resources > OAuth > OAuth 2.0 services

Dynamic cache objects for OAuth

WebSphere Application Server OAuth support provides two options for OAuth token and client persistence: in-memory and database.

For in-memory clients and tokens, the clients are persisted to the file system and tokens remain in memory. MBean interfaces are available to add or remove clients, which synchronize changes in a cluster and persist the changes to the file system. Tokens are managed using dynamic cache objects or local in-memory hashmaps if no dynamic cache is specified.

In the database implementation, dynamic cache objects are also used to back the database persistence for both the client table and the token table.

Typically the cache that backs the database is a weak hashmap based on a least-recently-used policy. Data in the caches are used if found, which avoids database queries for commonly used data and increases performance. If no dynamic cache is specified for the database, a local in-memory hashmap is used instead.

For OAuth environments that are not clustered, dynamic cache configuration is not required.


Defaults

Dynamic cache objects are highly configurable and tunable to maximize performance. By default, the OAuth service creates dynamic cache instances with reasonable default values in most environments.

The settings for the default dynamic caches for the in-memory caches are:

cache.instance.0=/services/cache/OAuth20MemTokenCache
cache.instance.0.cacheSize=1000
cache.instance.0.enableDiskOffload=true
cache.instance.0.flushToDiskOnStop=true
cache.instance.0.useListenerContext=false
cache.instance.0.enableCacheReplication=true
cache.instance.0.replicationDomain=DynaCacheCluster

cache.instance.1=/services/cache/OAuth20MemTokenOwnerCache
cache.instance.1.cacheSize=1000
cache.instance.1.enableDiskOffload=true
cache.instance.1.flushToDiskOnStop=true
cache.instance.1.useListenerContext=false
cache.instance.1.enableCacheReplication=true
cache.instance.1.replicationDomain=DynaCacheCluster

The settings for the default dynamic caches for the database caches are:

cache.instance.2=/services/cache/OAuth20DBTokenCache
cache.instance.2.cacheSize=1000
cache.instance.2.enableDiskOffload=false
cache.instance.2.flushToDiskOnStop=false
cache.instance.2.useListenerContext=false
cache.instance.2.enableCacheReplication=true
cache.instance.2.replicationDomain=DynaCacheCluster

cache.instance.3=/services/cache/OAuth20DBClientCache
cache.instance.3.cacheSize=1000
cache.instance.3.enableDiskOffload=false
cache.instance.3.flushToDiskOnStop=false
cache.instance.3.useListenerContext=false
cache.instance.3.enableCacheReplication=true
cache.instance.3.replicationDomain=DynaCacheCluster

In order for these caches to be correctly used in a cluster, the cluster nodes must be configured to use a replication domain named DynaCacheCluster. No additional configuration is required beyond setting the replication domain.


Advanced configuration

Only one replication domain can be specified per node. Any cluster nodes that already have a replication domain configured require advanced configuration to create dynamic cache objects for the existing replication domain. Environments that use tuned dynamic cache objects, for example to expand the cache size, must also use the advanced configuration.

To configure custom dynamic cache objects, two steps are needed:

  1. Create the dynamic cache instances in the WAS environment. See the existing documentation on dynamic cache objects for specifics on particular options. The default values shown previously can be used to get started. The replication domain name is especially important, since it must match the replication domain for environments that have a replication domain already configured.

  2. Modify the OAuth provider configuration settings for the JNDI names of the new dynamic cache objects.

    1. If using the in-memory persistence, the parameter names are:

        oauth20.token.cache.jndi.tokens
      and

        oauth20.token.cache.jndi.users

    2. If using the database persistence the parameter names are:

        oauth20.db.token.cache.jndi.tokens
      and

        oauth20.db.token.cache.jndi.clients

If the dynamic cache objects are improperly configured, they are replaced with local in-memory hashmaps. The hashmaps provide a performance boost, but the data is not replicated across nodes in a cluster. This becomes important for cache invalidation. For example, users that revoke their OAuth tokens in an improperly configured environment can still have access using their OAuth tokens on other nodes, until the token expires.

Environments that do not allow token revocation, or environments that can accommodate token inconsistency for the duration of the token lifespan, also have the option of disabling dynamic caching or cache invalidation. Disabling dynamic caching results in further increased performance at the cost of the longer access window.


+

Search Tips   |   Advanced Search