[keycloak-dev] Sticky sessions in backchannel requests
Marek Posolda
mposolda at redhat.com
Fri May 19 11:08:19 EDT 2017
On 19/05/17 16:31, Bill Burke wrote:
>
>
> On 5/19/17 10:29 AM, Marek Posolda wrote:
>> 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.
>>
>
> Backchannel sticky session becomes quite difficult if you can't talk
> to node directly. Adapter will have to know to set a cookie that the
> loadbalancer can handle. If the load balancer is using client IP to
> loadbalance, then you are SOL.
Yes, that's the pain with no easy solution. There is no standard for
loadbalancers and we don't know if people use private networks for
backend nodes or not etc :( Support for cookie in the adapter request is
the option I would like to go, we agreed so far in different thread on
ML. For loadbalancing on client IP not sure we can handle that. Maybe
use "client-ip" as the claim in code or token and do some hacking around
"X-" http headers in the adapter request to Keycloak?
Talking application to backend node directly has issues and AFAIK Stian
don't like this option at all. Hostname issues, backend node not
available to the app etc. Perhaps he can add more.
Marek
>
> Bill
More information about the keycloak-dev
mailing list