[keycloak-dev] Sticky sessions in backchannel requests

[Marek Posolda]

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.

Marek
>
> 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
>     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 <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>