[keycloak-dev] User SPI cache policies

[Bill Burke]

The cache timeout does not need to be propagated as the user is only 
cached on the machine that requested access to the user.  Its an 
invalidation cache.

i.e.

For the ldap provider, it has a cache policy that every day at 3pm any 
users cached before that time are invalidated.

* Node 1 accesses a user at 12pm.  User is not in cache.  Node 1 caches 
it within invalidation cache with a timeout of 3 hours. 3pm - 12pm = 3 hours

* Node 2 access same user at 1pm.  User is not in its cache. Node 2 
caches it with a timeout of 2 hours.

* Node 1 access user at 4pm.  If Infinispan has not evicted the user 
already and there is a cache hit, Keycloak checks the cache timestamp of 
the user.  It will see that the cache timestamp is older than 3pm and 
invalidate the user across the cluster.


On 11/2/16 3:08 AM, Stian Thorgersen wrote:
> How is the cache timeout propagated to the cluster is there a separate 
> and new replicated cache for that?
>
> On 1 November 2016 at 15:14, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     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
>>>
>>>
>>
>>
>
>