[keycloak-dev] Sticky sessions in backchannel requests

[Stian Thorgersen]

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?

On 19 May 2017 at 17:08, Marek Posolda <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 option
> >> 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 around
> "X-" http headers in the adapter request to Keycloak?
>
> Talking application to backend node directly has issues and AFAIK Stian
> don't like this option at all. Hostname issues, backend node not
> available to the app etc. Perhaps he can add more.
>
> Marek
>
> >
> > Bill
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>