Chapter 8. Server Cache Configuration

Red Hat Single Sign-On has two types of caches. One type of cache sits in front of the database to decrease load on the DB and to increase overall response times by keeping data in memory. Realm, client, role, and user metadata is kept in this type of cache. This cache is an invalidation cache. Invalidation caches do not use replication. Instead, they only keep copies locally and if the entry is updated an invalidation message is sent to the rest of the cluster and the entry is evicted. This greatly reduces network traffic, makes things efficient, and avoids transmitting sensitive metadata over the ire.

The second type of cache handles managing user sessions, offline tokens, and keeping track of login failures so that the server can detect password phishing and other attacks. The data held in these caches is temporary, in memory only, but is possibly replicated across the cluster.

This chapter discusses some configuration options for these caches for both clustered a non-clustered deployments.

Note: More advanced configuration of these caches can be found in JBoss EAP Configuration Guide

8.1. Eviction and Expiration

There are multiple different caches configured for Red Hat Single Sign-On. There is a realm cache that holds information about secured applications, general security data, and configuration options. This size of this cache is unbounded and does not have a limit on entries. This might scare you a little bit, but the number of entries in this cache is pretty low compared to the user cache. There is also a user cache that contains user metadata. It defaults to a maximum of 10000 entries and uses a least recently used eviction strategy. There are also separate caches for user sessions, offline tokens, and login failures. These caches are unbounded in size as well.

The eviction policy and max entries for these caches can be configured in the standalone.xml, standalone-ha.xml, or domain.xml depending on your operating mode.

non-clustered

<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
   <cache-container name="keycloak" jndi-name="infinispan/Keycloak">
       <local-cache name="realms"/>
       <local-cache name="users">
          <eviction max-entries="10000" strategy="LRU"/>
       </local-cache>
       <local-cache name="sessions"/>
       <local-cache name="offlineSessions"/>
       <local-cache name="loginFailures"/>
       <local-cache name="work"/>
       <local-cache name="realmVersions">
          <transaction mode="BATCH" locking="PESSIMISTIC"/>
       </local-cache>
   </cache-container>

clustered

<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
   <cache-container name="keycloak" jndi-name="infinispan/Keycloak">
       <transport lock-timeout="60000"/>
       <invalidation-cache name="realms" mode="SYNC"/>
       <invalidation-cache name="users" mode="SYNC">
           <eviction max-entries="10000" strategy="LRU"/>
       </invalidation-cache>
       <distributed-cache name="sessions" mode="SYNC" owners="1"/>
       <distributed-cache name="offlineSessions" mode="SYNC" owners="1"/>
       <distributed-cache name="loginFailures" mode="SYNC" owners="1"/>
       <replicated-cache name="work" mode="SYNC"/>
       <local-cache name="realmVersions">
           <transaction mode="BATCH" locking="PESSIMISTIC"/>
       </local-cache>
   </cache-container>

To limit or expand the number of allowed entries simply add, edit, or remove the eviction element from the invalidation-cache or distributed-cache declaration you want to change.

8.2. Replication and Failover

The sessions, offlineSessions and loginFailures caches are the only caches that may perform replication. Entries are not replicated to every single node, but instead one or more nodes is chosen as an owner of that data. If a node is not the owner of a specific cache entry it queries the cluster to obtain it. What this means for failover is that if all the nodes that own a piece of data go down, that data is lost forever. By default, Red Hat Single Sign-On only specifies one owner for data. So if that one node goes down that data is lost. This usually means that users will be logged out and will have to login again.

You can change the number of nodes that replicate a piece of data by change the owners attribute in the distributed-cache declaration.

owners

<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
   <cache-container name="keycloak" jndi-name="infinispan/Keycloak">
       <distributed-cache name="sessions" mode="SYNC" owners="2"/>
...

Here’s we’ve changed it so at least two nodes will replicate one specific user login session.

Tip

The number of owners recommended is really dependent on your deployment. If you do not care if users are logged out when a node goes down, then one owner is good enough and you will avoid replication.

8.3. Disabling Caching

To disable the realm or user cache, you must edit the keycloak-server.json file in your distribution. Where this file lives depends on your operating mode Here’s what the config looks like initially.

    "userCache": {
        "default" : {
            "enabled": true
        }
    },

    "realmCache": {
        "default" : {
            "enabled": true
        }
    },

To disable the cache set the enabled field to false for the cache you want to disable. You must reboot your server for this change to take effect.

8.4. Clearing Caches at Runtime

To clear the realm or user cache, go to the Red Hat Single Sign-On admin console Realm Settings→Cache Config page. On this page you can clear the realm cache or the user cache. This will clear the caches for all realms and not only the selected realm.