[keycloak-dev] Caching of identity provider links

[Bill Burke]

Some comments on code:

* Why have a special flag in invalidateUser?  Just invalidate the links 
if they exist.  Aggressive eviction isn't a bad thing, is it?

On a side note, cache needs more refactoring, we're reusing the same 
pattern over and over.  Wonder if functions can help.


On 3/22/2016 5:42 AM, Marek Posolda wrote:
> Until now, we don't have support for caching of identityProvider
> (social) links. So every social login or every going to "federated
> identities" tab in account management needs to send DB queries. I was
> looking at fixing it and I've send PR
> https://github.com/keycloak/keycloak/pull/2404 . It turned to be a bit
> tricky because of:
>
> 1) Caching needs to be done on both directions. For social login, you
> need to lookup user by social link. But on the other hand, you also need
> to look all social/identityProvider links of particular user when you go
> to account management etc.
>
> 2) Because of "store token" option, the link may need to be updated in
> DB quite often (in theory even during each social login).
>
> I was thinking that storing links directly on CachedUser doesn't work
> very well, because during each update of social link (which may be often
> because of "store token") the user would need to be fully invalidated
> from cache. Having separate cache entry for each social link also has
> some downsides (many items in cache, need to have separate entry for
> store the all links of user anyway). So I ended up with having the cache
> entry, which contains list of all links of particular user. It needs to
> be updated when any social link is added,removed or updated. This seemed
> to me like good compromise. WDYT?
>
> There are also entries for lookup user by federated identity, so you
> don't need to query DB during social login.
>
> So ATM there are not DB queries during social login or during go to
> "federated identities" . I hope I handled all corner cases and
> invalidations correctly, but if someone want to take look it will be
> good. I don't want to add new regressions atm :-)
>
> Marek
>
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com