[keycloak-dev] Clustering and user sessions

[Stian Thorgersen]

I think we should do it in stages as we discussed today:

1. Check that clustering works with cache turned off and user sessions persisted to db - we should try using Docker + Fig
2. Add cache invalidation messages + replication of user sessions
3. Secure replication messages - there's no sensitive data being sent so signature should be sufficient
4. Address scalability

Let's have a chat tomorrow about how to split the work and a bit more discussion on how we'll do it. ATM I'm thinking using jgroups directly may be better in the long run than using Infinispan as it will give us a lot more control over what messages are sent. However, I don't know enough details about Infinispan to know what benefits it could give us and if we can get the control we'd like with that.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 September, 2014 4:00:25 PM
> Subject: Re: [keycloak-dev] Clustering and user sessions
> 
> On 17.9.2014 15:52, Stian Thorgersen wrote:
> >> yeah, userId or sessionId will be great as it's random value and you
> >> >have best shard equality. However I am not sure if you have this info.
> >> >As typical scenario might be:
> >> >* User send request to display KC login page
> >> >(/auth/realms/my-realm/tokens/login) - this is anonymous request, so
> >> >front-server can redirect to any random shard group
> > No biggy - doesn't need user knowledge so can be sent to any server
> >
> >> >* Once user confirms login form, front-server would need to recognize to
> >> >which shard he send this request (POST to
> >> >/auth/realms/my-realm/tokens/auth/request/login). Once he do it,
> >> >UserSession will be created on this shard so subsequent requests should
> >> >go there. But at the time of sending POST request, userId is not known
> >> >to front-server. Unless front server are so clever, that they can lookup
> >> >KC database (so in the end, they might need to have access to KC
> >> >services too)
> > Yeah, we would need to be able to somehow lookup userId based on
> > username/email
> >
> yes, so front-servers might be something like proxy-servers with access
> to all keycloak services, but with slightly changed keycloak rest
> endpoints (Their only task would be to find correct shard for sending
> request). This should work.
> 
> Maybe there is some even better solution (adding some info to request to
> preserve something like sticky session), but I don't know yet...
> 
> Marek
>