[keycloak-dev] Running Keycloak in a clustered mode

[Marek Posolda]

On 07/03/18 13:51, Chervine Majeri wrote:
> Hi,
> We're considering attempting the exact same setup, with 2 standalone 
> keycloaks connected to the same backend DB.
>
>     User session is one example. There are some other things, which won't
>
>     work. We never tried to test such setup and I wouldn't do it.
>
> From what I've seen, only what's stored in the cache ends up being 
> different, meaning the HA models really only differ in that they have 
> a distributed cache. Is this correct? Or does it affect the connection 
> to the DB too?
>
> From that assumption, seeing the content of "standalone-ha.xml", I see 
> that it's mostly session related stuff and things like loginFailures 
> that end up in the distributed cache.
> Since we have a session cookie, unique for every session, can we use 
> session stickiness in the reverse-proxy to circumvent most the issues?
The session stickyness is usually not sufficient. The OpenID Connect 
specification uses some "backchannel" requests, which are not sent as 
part of browser session, but they are sent directly between client 
application and Keycloak (For example code-to-token request, Refresh 
token request etc). Those requests won't see sticky session cookie, and 
hence can be directed to the other node, then the one who owns the session.

Only possibility, when everything may work is, if all your clients are 
using keycloak.js adapter (javascript clients run fully inside browser 
and so they can participate in sticky session as backchannel requests 
are sent from browser as well).

There are also some other cases when sticky session is not sufficient. 
For example in scenarios when mail is sent to user (EG. "Forget 
password" functionality) and user clicks on the link, but the link is 
opened in the other browser then the one, who "owns" sticky session 
cookie. Then it may happen that request is served on the other browser 
then the one, who owns the session.

Finally invalidations won't work. Keycloak uses caches to cache some 
data for performance reasons. Those caches are "realms", "users" and 
"keys" . Every cluster node cache the data locally, however when some 
change happens (data are updated), then the node, who did the update, 
must notify other nodes in cluster about the change. If you don't use 
cluster, this won't work and other cluster nodes won't be notified and 
will still see stale data in their caches. In other words, when for 
example you update user "john" on node1, then node2 won't be aware about 
this update and will still see stale (old) data of user "john" in it's 
cache. The only possibilities how to workaround is:
- Disable cache entirely (See our docs for more details)
- Ensure that cache is cleared after every update (This is usually not 
possible to achieve unless you have some special kind of deployment (EG. 
something close to read-only deployment)).

Marek

>
> Obviously the loginFailures feature wouldn't work all that well, but 
> that would be acceptable for my use-case.
>
> Thanks,
> Chervine.