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