[keycloak-dev] sticky sessions, clustering, and authentication

[Bill Burke]

On 6/4/2015 8:09 AM, Marek Posolda wrote:
>> Only solution without sticky sessions are distributed caches (shards).
>> If Google can make it scale to their level it shouldn't be a problem
>> for us either.
> I didn't mean sticky sessions here, but UserSessions/ClientSessions.
> Just trying to compare the performance of replication vs. distribution.
> For large clusters (5+ nodes) distribution is only choice for sure,
> replicating each item to 5 nodes doesn't scale...
>
> However for smaller clusters like 2 nodes, the replication may be better
> choice than distribution though. With distribution, if you really have
> network call per "session.sessions().getClientSession()" you may end
> with 10 network calls per request or so.
>>
>> What we do maybe need to optimize is how many calls there are. For
>> example atm I think we call once to get client session and another for
>> user session.
> +1, maybe we can try to see if ClientSession/UserSession can be saved in
> KeycloakContext.
>

Just hitting the login screen causes a replication/distribution for 
infinispan, db insert for mongo/jpa.  There's no way around that because 
our authentication layer is decoupled from the login protocol (saml, 
oidc) and we need to store protocol specific metadata for use after 
authentication is complete.

Another thought is to store AuthenticationSession into a 
signed/encrypted cookie or a query parameter so you could avoid sticky 
sessions.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com