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

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: "mike cirioli" <mikecirioli at gmail.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, 4 June, 2015 2:40:54 PM
> Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication
> 
> 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.

For a replicate Infinispan cache that's not a problem IMO. At long as it's 1 update per request. I really don't think this is an issue.

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

Cookies won't work if the flow is split between two browsers. For example we have loads of users that had one primary browser they use, but another browsers that opens links in emails. So for example reset password. I can also see us wanting to add support for using email as a second factor auth mechanism.

Query param has issues with the param being huge. I don't think that's a good solution.

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