3:30 a.m.
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?
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.
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.
On 16 May 2017 at 10:19, Marek Posolda <mposolda(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev