1 p.m.
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(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "Bill Burke" <bburke(a)redhat.com>, keycloak-dev(a)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