[keycloak-dev] Sticky sessions in backchannel requests

[Bill Burke]

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.

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.


On 5/16/17 4:19 AM, Marek Posolda wrote:
> I was thinking about possibilities how to solve the issue with sticky
> sessions in backchannel requests. It seems that we need to support the
> scenarios, when backchannel requests won't be able to share the sticky
> session cookie with the browser. However in many cases it may be
> possible that backchannel requests can participate in the "sticky
> session", which will have great advantage for performance. Some thoughts:
>
> - OAuth code (the one used in code-to-token backchannel request) can be
> JWT signed by realm HMAC key. One of the claims in the code could be
> "route-id"
>
> - Refresh tokens will also contain "route-id" claim
>
> - Keycloak OIDC adapters will be able to read the "route-id" from the
> code and they will attach sticky session information to the single
> backchannel request. Hence the backchannel request will be able to
> participate in sticky session and will be properly routed by
> loadbalancer to the correct node. Same for requests using refresh token.
>
> - It seems we will need some flexibility how is the "sticky session"
> added to the request to support various loadbalancers (cookie,
> path-parameters etc). Maybe we need some SPI on adapter side? Or just
> some kind of expressions/tokens, which will help to configure how
> exactly will cookie/path parameter look like?
>
> - Keycloak.js adapter seems to be working already. Ajax requests are
> re-sending the browser cookies and they are available in backchannel
> endpoint on server-side. This is true even if AUTH_SESSION_ID cookie is
> httpOnly. I've tested with Firefox, Chrome, my mobile phone. Not sure if
> this is different in other browsers/devices (cordova etc)?
>
> - For SAML backchannel requests (backchannel logout), we can add the
> same to our own SAML adapters though.
>
> - If people use 3rd party adapters, they won't have this. However we can
> also have support for some loadbalancers to route the requests directly
> based on the content of the route-id inside code (or refresh token). In
> many cases, customers will already have established loadbalancer in
> their deployments. However some others might be starting their
> deployment from the scratch and we can suggest them to use some of our
> preferred loadbalancers though.
>
> I've checked that if wildfly+mod_cluster is used as loadbalancer, we
> have the flexibility to inject custom undertow handler, which will be
> able to look into JWT and add the route info to the HttpServerExchange,
> from where mod_cluster will read it. Maybe we can investigate this
> possibility in the other popular loadbalancers (nginx etc) ?
>
> So in summary: Backchannel requests won't be able to participate in
> sticky session just if: 3rd party adapter is used AND customer can't use
> our preferred loadbalancer.
>
> WDYT?
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev