Caching

The Shiro development team understands performance is critical in many applications. Caching is a first class feature built into Shiro from day one to ensure that security operations remain as fast as possible.

However, while Caching as a concept is a fundamental part of Shiro, implementing a full Cache mechanism would be outside the core competency of a security framework. To that end, Shiro's cache support is basically an abstraction (wrapper) API that will 'sit' on top of an underlying production Cache mechanism (e.g. Ehcache, OSCache, Terracotta, Coherence, GigaSpaces, JBossCache, etc). This allows a Shiro end-user to configure any cache mechanism they prefer.

Caching API

Shiro has three important cache interfaces:

A CacheManager returns Cache instances and various Shiro components use those Cache instances to cache data as necessary. Any Shiro
component that implements CacheManagerAware will automatically receive a configured CacheManager, where it can be used to acquire Cache instances.

The Shiro SecurityManager implementations and all AuthorizingRealm implementations implement CacheManagerAware. If you set the CacheManager on the SecurityManager, it will in turn set it on the various Realms that implement CacheManagerAware as well (OO delegation). For example, in shiro.ini:

example shiro.ini CacheManger configuration

securityManager.realms = $myRealm1, $myRealm2, ..., $myRealmN
...
cacheManager = my.implementation.of.CacheManager
...
securityManager.cacheManager = $cacheManager
# at this point, the securityManager and all CacheManagerAware
# realms have been set with the cacheManager instance

We have an out-of-the-box EhCacheManager implementation, so you can use that today if you wanted. Otherwise, you can implement your own CacheManager (e.g. with Coherence, etc) and configure it as above, and you'll be good to go.

Authorization Cache Invalidation

Finally note that AuthorizingRealm has a clearCachedAuthorizationInfo method that can be called by subclasses to evict the cached authzInfo for a particular account. It is usually called by custom logic if the corresponding account's authz data has changed (to ensure the next authz check will pick up the new data).