[keycloak-dev] User SPI cache policies

Bill Burke bburke at redhat.com
Tue Nov 1 10:14:55 EDT 2016


Your analysis is incorrect for EVICT_DAILY and EVICT_WEEKLY.  With these 
policies, when a user is cached, time until next expiration is 
calculated and the cache timeout for that entry is set in infinispan...

ALSO

When there is a cache hit, the timestamp on the cached user is checked 
to see if it should have expired.  If it has its invalidated (cluster 
wide) and the user is loaded from the DB.  If the clocks on cluster 
nodes are out of sync, then yes, there will possibly be issues.

Its done this way because Infinispan does not guarantee that eviction 
will happen at the indicated timeout.  Also its impossible to test if I 
just relied on Infinispan to evict.

So, in your example, if Node 1 loads user at 2am, Node 2 loads the user 
at 2pm, the eviction time is 3pm, then after 3pm, both node 1 and node 2 
cache for that user are not valid anymore.

Your analysis is correct for MAX_LIFESPAN, but only if a third-party has 
modified the user outside the scope of Keycloak.  This inconsistent 
cache could happen irregardless of the cache policy in that 
external-party scenario.


On 11/1/16 3:04 AM, Stian Thorgersen wrote:
> Another question around the user cache policies. As these are eviction 
> policies would they not just be applicable to one node? For example 
> eviction is daily. Node 1 loads the user at 2am. Node 2 loads the user 
> at 2pm. The user is then changed at 3pm. In this case there's 12 hours 
> where node 1 and node 2 will see different data for the user. Sounds 
> like that could cause all sorts of strange behavior.
>
> On 31 October 2016 at 19:33, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     You need to know the user before you can evict it. username can be
>     obtained differently from multiple different authenticators: 
>     spnego, username/password UI, basic auth, etc..
>
>
>     On 10/31/16 9:41 AM, Stian Thorgersen wrote:
>>     Could we not do it as a special first authenticator in the flow?
>>
>>     On 31 October 2016 at 14:08, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>
>>
>>         On 10/31/16 8:51 AM, Stian Thorgersen wrote:
>>>
>>>
>>>         On 31 October 2016 at 13:49, Bill Burke <bburke at redhat.com
>>>         <mailto:bburke at redhat.com>> wrote:
>>>
>>>
>>>
>>>             On 10/31/16 1:48 AM, Stian Thorgersen wrote:
>>>
>>>                 What about evict on authenticate (load from store
>>>                 when user authenticates)? I think that would be the
>>>                 most useful policy.
>>>
>>>             That would need to be implemented at the authenticator
>>>             level.
>>>
>>>
>>>         Implementation details aside, should we not have it? It
>>>         seems like the most likely time you want to fetch the user
>>>         and especially credentials.
>>         Yeah, its a great idea. Implementation details matter though
>>         as I'm not sure this can be reliably done without coding this
>>         in each top-level authenticator and requiring an
>>         authenticator provider developer to be aware of this policy.
>>
>>         Bill
>>
>>
>
>



More information about the keycloak-dev mailing list