[keycloak-dev] Sticky sessions in backchannel requests

[Stian Thorgersen]

On 19 May 2017 at 10:54, Marek Posolda <mposolda at redhat.com> wrote:

> On 19/05/17 10:30, Stian Thorgersen wrote:
>
> Why do you need a separate route.id param? Wouldn't it just rely on the
> session_state being the same value as the authentication session cookie?
>
> Yes, that's also an option.
>
>
> The cookie approach with our adapters seems sensible option. Not sure
> about the approach of looking into the code/JWT as we can't rely on the
> load balancer implementation. There's loads of them out there and we need a
> solution that works regardless of the load balancer.
>
> I know we can't rely on used loadbalancer. However in some cases, people
> may start their environment from scratch. If we have optimized solution for
> some loadbalancers (wildfly/undertow based. Maybe nginx and HAProxy as
> those seem to be quite popular) it won't be bad?
>
> For example the development of undertow handler to be used together with
> Wildfly based mod_cluster loadbalancer won't be hard to do. Maybe the
> bigger challenge is testing and maintenance.
>

I doubt anyone will use undertow as a load balancer when they have multiple
DCs. Most likely it'll be whatever Amazon provides and there's probably
limited possibilities on how it's configured.


>
>
> One option if possible is on demand replication of sessions. A session
> lives in one DC until it's requested from another DC. That means if users
> use only apps that can be sticked to a DC either by cookie or some other
> mechanism (for example the app itself is replicated in all DCs) the session
> won't be replicated. If/when a user hits a third party app or another app
> that for some reason is directed to the other DC that session is fetched
> from the other DC and replicated afterwards.
>
> Yes, I sent something around that in another mail today on keycloak-dev.
> It seems to me that we may need asynchronous requests to not block undertow
> worker thread waiting for userSession to be fetched from the other DC?
>
> Also I wonder how bad it is to have option of userSession replicated
> directly between DCs through ASYNC channel? In other words, when
> userSession is created, it is replicated directly to other DCs by ASYNC
> way. It means that worker in the other DCs won't need to block so big time
> until userSession is fetched from the second DC and/or userSession may be
> already available there. But obviously there is price to pay that more
> communication will happen between DC, as it may result in replicating
> userSessions, which won't be needed in second DC at all.
>

Haven't had time to read that thread yet. Async replication is probably
fine as a starting point, but if you want to really scale things and in
situations when it's possible to route requests for a session to only one
DC it would scale better if we could have an option to replicate on demand.


>
>
> Marek
>
>
>
> On 16 May 2017 at 10:19, Marek Posolda <mposolda at redhat.com> 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
>>
>
>
>