[keycloak-dev] sticky sessions for UserSession

[Bill Burke]

True.

On 9/23/2014 9:16 AM, Stian Thorgersen wrote:
> 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
>>
> _______________________________________________
> 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