[keycloak-dev] User SPI cache policies

[Stian Thorgersen]

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
>>>
>>
>>
>>
>
>