[keycloak-dev] Sticky sessions in backchannel requests

Fri May 19 07:46:29 EDT 2017

On 19/05/17 12:21, Stian Thorgersen wrote:
>
>
> On 19 May 2017 at 10:54, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 19/05/17 10:30, Stian Thorgersen wrote:
>>     Why do you need a separate route.id <http://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.
Ah true. I will try to look what may people typically use as deployment 
scenarios with more DCs. Which environment, loadbalancers they use etc. 
Not sure how much "user stories" are publicly available.

Still undertow and mod_cluster will be helpful even for classic cluster 
without multiple DCs. If you can achieve sticky sessions for all 
backchannel requests (even if you have 3rd party adapters), it's good 
improvement for performance. But I won't treat it as big priority. Maybe 
just if there is demand or time permits.

>
>>
>>     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.
yep, with async by default, it will be more network communication for 
sure. However throughput for user requests may be better due the fact 
that they don't need to wait until session is fetched, as session may be 
already available. But not sure, maybe performance tests will help with 
this.

Marek
>
>
>
>     Marek
>
>>
>>
>>     On 16 May 2017 at 10:19, Marek Posolda <mposolda at redhat.com
>>     <mailto: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
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>