Of course. Being a bit slow. It's at a specific time, not after an amount
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(a)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
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(a)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...
> 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
> 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(a)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(a)redhat.com> wrote:
>>> On 10/31/16 8:51 AM, Stian Thorgersen wrote:
>>> On 31 October 2016 at 13:49, Bill Burke <bburke(a)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.