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(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
> To: "Marek Posolda" <mposolda(a)redhat.com>, "Stian
Thorgersen"
> <stian(a)redhat.com>
> Cc: "mike cirioli" <mikecirioli(a)gmail.com>,
keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev