[keycloak-dev] sticky sessions for UserSession

[Stian Thorgersen]

Another issue with sticky sessions is that it would be difficult to implement queries (retrieve all user sessions and client sessions), remove expired sessions, etc..

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 23 September, 2014 12:29:21 PM
> Subject: Re: [keycloak-dev] sticky sessions for UserSession
> 
> 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
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>