[keycloak-dev] Sticky sessions in backchannel requests

[Marek Posolda]

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.

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