[keycloak-dev] sticky sessions for UserSession

[Stian Thorgersen]

I don't like the idea of introducing a sticky session, also I'd prefer if we could at least provide the illusion of Keycloak being stateless.

Some issues with sticky sessions:

1) Load balancer needs session cookie to make requests from browser sticky
2) Also need to make requests from clients "sticky", either by a cookie or by having clients go to a specific url (latter means exposing internal nodes as well as load balancer)
3) Doesn't increase availability - in that case we still need some replication

An alternative solution is to have the user session provider deal with this. I propose we use Infinispan to provide a clustered and sharded in-memory store for user sessions. This means that Keycloak itself doesn't store user-sessions in-memory, but instead delegates this to Infinspan. It also means that if someone really wants to persist user sessions they still can (using clustered relational db, or a sharded mongodb).

With that in mind the stages involved in developing clustering support would be:

1) Use JPA (or Mongo) stores for everything with no caches
2) Use Docker to easily create a cluster (multiple Keycloak instances and Apache load balancer) for testing
3) Create a cluster testsuite
4) Enable realm cache - using jgroups to send cache invalidation messages (messages are signed with realm key and contain no sensitive data, only id that is invalidated, so doesn't need to be encrypted)
5) Enable user cache - same as 4, but for users
6) Infinispan User Session provider
   6.1) No replication or sharding
   6.2) Replicated for availability
   6.3) Sharded for scalability

This would support any load balancer (where the load balancer is the only externally visible url) and a cluster of Keycloak servers. Any Keycloak server can process any request. In non-clustered config we can use a single in-memory Infinispan cache to retrieve user sessions from (so there's no need to maintain a separate in-mem user session store). For increasing availability we can have multiple Infinispan nodes that replicates all user sessions. Finally, for increased scalability Infinispan would shard on user-session-id.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 23 September, 2014 9:09:21 AM
> Subject: Re: [keycloak-dev] sticky sessions for UserSession
> 
> I think that generally there are 2 main purposes of clustering:
> a) scalability and better performance (ideally n-times better
> performance with n nodes in cluster)
> b) failover
> 
> With in-memory session you will achieve (a), but (b) won't be addressed.
> So if you have 2 keycloak nodes and you kill node-1, then all
> UserSessions on node-1 will be lost and users would need to relogin. IMO
> Sticky sessions are good, but there is still need to replicate sessions
> (at least to 1 additional cluster node) if you want to address failover.
> Or am I just not understand correctly what you meant?
> 
> Marek
> 
> On 22.9.2014 22:14, Bill Burke wrote:
> > Was thinking about clustering.  Sticky sessions combined with in-memory
> > only UserSessions might be best for clustering.  We'll need to change
> > access code processing so that it is a) signed and b) contains the
> > callback URL.  In looking at SAML, it jsut seems we need to have the
> > notion of an HttpSession and the idea of loading this session from a
> > database (or even a clustered cache) doesn't seem very feasible or
> > scalable.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>