[keycloak-dev] User SPI cache policies

[Stian Thorgersen]

Of course. Being a bit slow. It's at a specific time, not after an amount
of time.

For the MAX_LIFESPAN though is that not a potentially big issue? Especially
if sessions are not sticky?

On 2 November 2016 at 14:46, Bill Burke <bburke at redhat.com> wrote:

> 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> 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> 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> wrote:
>>>
>>>>
>>>>
>>>> On 10/31/16 8:51 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>>
>>>> On 31 October 2016 at 13:49, Bill Burke <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
>>>>
>>>
>>>
>>>
>>
>>
>
>