[keycloak-dev] Sticky sessions in backchannel requests
mposolda at redhat.com
Tue May 23 05:26:22 EDT 2017
On 22/05/17 09:15, Stian Thorgersen wrote:
> An application can only access a backend node directly if it's within
> the same subnet. At that point it's not a big problem in either case
> as local traffic can easily be configured to talk to nodes within the DC.
> Some pluggable way of setting headers/cookies or something that allows
> load balancer to stick the requests is probably the best we can do.
> Not even sure that'll even work between DCs as I believe that can be
> handled at the DNS level. One option that could work is to have smart
> proxies/routers. These would be replicated within DCs and have some
> way of proxying requests to the correct node. That'd work for third
> party apps and other things where you can get the client to set any
> special headers etc.
> I second Bills suggestion of raising this on the OIDC mailing lists.
> Marek could you do that?
Yes, will try to look into it this week.
> On 19 May 2017 at 17:08, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
> On 19/05/17 16:31, Bill Burke wrote:
> > On 5/19/17 10:29 AM, Marek Posolda wrote:
> >> On 19/05/17 15:21, Bill Burke wrote:
> >>> This issue comes up in:
> >>> * code to token
> >>> * refresh token
> >>> * backchannel logout
> >>> * access token validation (bearer token authentication)
> >>> * Authorization and RPT
> >>> * Token exchange
> >>> Any others?
> >>> We need to get on OIDC lists and discuss these types of issues
> so that
> >>> they can get standardized.
> >> Good point. I can try to start discussion there.
> >>> Other thoughts:
> >>> * What if you talk to the node directly by providing a URL
> claim in the
> >>> token or code? The issue with that is that since we derive a
> lot of
> >>> things from the hostname of the request, we will need the
> ability to
> >>> override this.
> >> You mean to bypass loadbalancer entirely and let the
> application talk
> >> to the backend node directly?
> >> Besides the hostname issue, there is another one, that backend node
> >> may not be directly available. Those are typically on private
> >> networks and it can be different private network that
> application is
> >> using. That was the case for example in RedHat IT environment.
> >> BTV. We already had similar possibility in adapter to directly talk
> >> to backend node in backchannel requests. Instead of lookup the
> >> backend node URL from claim, we had the option in adapter
> >> configuration "auth-server-url-for-backend-requests" . But the
> >> was removed due those issues like hostname, verifications of "iss"
> >> claim in tokens etc.
> > Backchannel sticky session becomes quite difficult if you can't talk
> > to node directly. Adapter will have to know to set a cookie that the
> > loadbalancer can handle. If the load balancer is using client IP to
> > loadbalance, then you are SOL.
> Yes, that's the pain with no easy solution. There is no standard for
> loadbalancers and we don't know if people use private networks for
> backend nodes or not etc :( Support for cookie in the adapter
> request is
> the option I would like to go, we agreed so far in different thread on
> ML. For loadbalancing on client IP not sure we can handle that. Maybe
> use "client-ip" as the claim in code or token and do some hacking
> "X-" http headers in the adapter request to Keycloak?
> Talking application to backend node directly has issues and AFAIK
> don't like this option at all. Hostname issues, backend node not
> available to the app etc. Perhaps he can add more.
> > Bill
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
More information about the keycloak-dev