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

[Stian Thorgersen]

By the way this is exactly the sort of stuff Inifinspan is built for so we should leverage it

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 4 June, 2015 2:55:20 PM
> Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication
> 
> 
> 
> ----- 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
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>