You can now define cache policies per UserStorageProvider. * NO_CACHE - don't cache users loaded from this provider * MAX_LIFESPAN - max lifespan of user in cache * EVICT_DAILY - specify a time of day when the cache will be expired every day. * EVICT_WEEKLY - specify a day of the week and time of day when the cache will be expired. Bill _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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.

Should we have the same type of policy support on the KC database? > > Thought about that, but isn't this already configured via infinispan?

On 10/31/16 8:51 AM, Stian Thorgersen wrote: On 31 October 2016 at 13:49, Bill Burke <bburke(a)redhat.com&gt; 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

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&gt; wrote: > > On 10/31/16 8:51 AM, Stian Thorgersen wrote: > > > > On 31 October 2016 at 13:49, Bill Burke <bburke(a)redhat.com&gt; 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 > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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&gt; wrote: > > > On 10/31/16 8:51 AM, Stian Thorgersen wrote: > > > > On 31 October 2016 at 13:49, Bill Burke <bburke(a)redhat.com&gt; 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 >

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(a)redhat.com&gt; 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&gt; wrote: > >> >> >> On 10/31/16 8:51 AM, Stian Thorgersen wrote: >> >> >> >> On 31 October 2016 at 13:49, Bill Burke <bburke(a)redhat.com&gt; 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 >> > > >

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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&gt; wrote: >> >>> >>> >>> On 10/31/16 8:51 AM, Stian Thorgersen wrote: >>> >>> >>> >>> On 31 October 2016 at 13:49, Bill Burke <bburke(a)redhat.com&gt; 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 >>> >> >> >> > >