HA Proxy rocks, BTW.
On 5/15/17 9:56 AM, Schuster Sebastian (INST/ESY1) wrote:
Hi Bill,
I totally understand it is necessary for optimal performance. I am just arguing this is
possible by just configuring your load balancers correctly
without Keycloak doing anything about it (especially leaking the number of nodes in the
cluster or introducing the ability to target individual nodes
from the outside).
Best regards,
Sebastian
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org]
On Behalf Of Bill Burke
Sent: Montag, 15. Mai 2017 15:49
To: keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR
TLDR; For performance, sticky sessions are really important.
Keycloak is not stateless. We use a distributed cache for user sessions. This means
that the user session is not stored on every node in the cluster and is
"queried" if the node doesn't have it. Also, our db caches are all
invalidation based. So, for a specific user it is highly likely that the node will not
have that user loaded and have to hit the database. This problem is exacerbated since
OIDC has out-of-band (non-browser) requests. code-to-token and refresh token are all out
of band.
On 5/15/17 8:14 AM, Schuster Sebastian (INST/ESY1) wrote:
> Hi Marek,
>
> There are a lot of different ways how load balancers can create stickiness. They can
use source or destination IP, they can use cookie insertion or cookie rewriting adding a
route identifier to the response (this is similar to what you did), or they can also
maintain sticky tables holding state like opaque session ids to map future requests to the
right node.
>
> There is some documentation how to do this in a simple way for nginx
(
https://www.nginx.com/products/session-persistence/), while
(
https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-stick%2...)
shows you can store arbitrary things to realize stickiness in HAProxy if you want to (e.g
to act differently for requests coming from a proxy).
>
> Anyways, I guess my point is that you can create session stickiness by just
configuring your load balancer to use whatever mechanism you prefer. Ideally, Keycloak
should not care and should not require a specific mechanism to be used. If I want a higher
level of protection for my cluster more and not give out any information, I should be able
to do this (at the cost of more work for the load balancers).
>
> Of course, I am assuming Keycloak still works fine without session stickiness being
configured correctly (just with reduced efficiency).
>
> Best regards,
> Sebastian
>
> Mit freundlichen Grüßen / Best regards
>
> Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785
> Berlin | GERMANY |
www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
> 30 726112-100 | Sebastian.Schuster(a)bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
> B
> Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda@redhat.com]
> Sent: Montag, 15. Mai 2017 13:02
> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
> keycloak-dev(a)lists.jboss.org
> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR
>
> On 15/05/17 10:20, Schuster Sebastian (INST/ESY1) wrote:
>> Hi Marek,
>>
>> I guess using sticky sessions is fine. I was only referring to the
>> fact that the cookie content looked like it contains some route
>> identifier that is visible to the client. This way a client could
>> find out how many nodes are behind the load balancer or it could
>> target individual nodes. I think this would be a security issue and should be
avoided by using just an opaque session id in the cookie. The load balancer will keep
track of which node generated the session id and will route further requests accordingly.
> Yes, it works this way. However AFAIK using the cookie to route requests is standard
way, which most loadbalancers are using. Exposing some informations about underlying
routes, and possibly count of cluster nodes, might be a price to pay.
>
> It is possible to avoid it by:
> - Avoid sticky sessions.
> - I suppose some loadbalancers might have tools to somehow hide this (eg. encrypt the
cookie), or track the mapping of the session-to-routes in some internal memory.
>
> I must admin that I am not so experienced in what admins are typically doing. I am
curious about your setup. Do you want to avoid sticky sessions at all or your loadbalancer
has some other way to track them rather than through browser cookie? Which loadbalancer
are you using?
>
> Marek
>> Best regards,
>> Sebastian
>>
>>
>> Mit freundlichen Grüßen / Best regards
>>
>> Sebastian Schuster
>>
>> Engineering and Support (INST/ESY1)
>> Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785
>> Berlin | GERMANY |
www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>> 30 726112-100 | Sebastian.Schuster(a)bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
>> B
>> Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>> -----Original Message-----
>> From: Marek Posolda [mailto:mposolda@redhat.com]
>> Sent: Montag, 15. Mai 2017 09:47
>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
>> keycloak-dev(a)lists.jboss.org
>> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens
>> PR
>>
>> Hi,
>>
>> we are adding some sticky session support, so this routeId is used by the
loadbalancer to track to which cluster backend node it should forward the request. This is
pretty much similar to what Wildfly is doing to track the session stickiness of servlet
httpSessions. However I've added the SPI, so it would be possible to avoid adding the
route to the cookie or use different strategy to add the route to the request.
>> But without sticky sessions, you might have worse performance in cluster
environment.
>>
>> Btv. do you want to avoid sticky sessions at all or your loadbalancer has some
other way to track them rather than through browser cookie?
>> Which loadbalancer are you using?
>>
>> Marek
>>
>>
>> On 12/05/17 08:30, Schuster Sebastian (INST/ESY1) wrote:
>>> Hi Marek,
>>>
>>> Is there a technical reason for including the routeid explicitely in the
Cookie?
>>> Normally, I would be reluctant to give out information about the
>>> setup behind the load balancer, like how many nodes the cluster consists of.
>>>
>>> Best regards,
>>> Sebastian
>>>
>>> Mit freundlichen Grüßen / Best regards
>>>
>>> Sebastian Schuster
>>>
>>> Engineering and Support (INST/ESY1)
>>> Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785
>>> Berlin | GERMANY |
www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>>> 30 726112-100 | Sebastian.Schuster(a)bosch-si.com
>>>
>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
>>> 148411 B
>>> Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: keycloak-dev-bounces(a)lists.jboss.org
>>> [mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Marek
>>> Posolda
>>> Sent: Donnerstag, 11. Mai 2017 22:33
>>> To: keycloak-dev(a)lists.jboss.org
>>> Subject: [keycloak-dev] Authentication sessions & Action tokens PR
>>>
>>> I've finally sent the PR
>>>
https://github.com/keycloak/keycloak/pull/4132
>>> with the work for $subject. This includes the work by Hynek and me on
Authentication sessions and action tokens. We finally managed to sort various kinks and
have all tests passing.
>>>
>>> Some things and concepts were already discussed in some previous threads [1],
[2], [3] and during presentations. So I won't repeat everything.
>>> Just some highlights:
>>>
>>> - authenticationSession replaces the old ClientSessionModel. There is
separate AuthenticationSessionProvider and separate infinispan cache
"authenticationSessions" . This cache typicaly won't be replicated over all
the datacenters, but instead it will rely on browser sticky sessions, hence browser will
be redirected by loadbalancer to correct node in correct datacenter. So typicaly there
won't be cross-dc communication needed during authentication.
>>>
>>> - I've added some support for sticky sessions already. In cluster
environment, the authentication session cookie is created in the format like
"sessionId.routeId" . For example
"aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format like
JSESSIONID cookie used as a cookie in classic java web applications. One side-effect of
this PR is, that it also covers the support for running clustering tests on embedded
undertow and from IDE.
>>>
>>> - Support for browser back/forward/refresh buttons was improved since my
presentation last month. There are no browser redirects after the form submit, but instead
there is a change of browser history through the javascript history.replaceState function.
This pretty much removes all the POST requests from the browser history and helps with
having good experience regarding browser buttons. In case that you have old browser not
supporting this, the behaviour is same like before. Hence default browser "Page
expired" page after clicking back from POST request (same behaviour like latest
master). There are no additional redirects.
>>>
>>> - For action tokens, Hynek will likely add more. For quick summary, I can
just mention that action token is JWT signed by realm secret key.
>>> You can generate it in your authenticator or requiredActionProvider and send
it somehow to user. Typically through email. Once user opens the actionToken URL from the
email, it is processed on LoginActionsService endpoint, which provides most of the common
basic functionality and verifications. LoginActionsService then finds the correct
implementation of ActionTokenHandler, which is separate SPI. This allows to specify the
details how can be actionToken handled, whether it's single use or not etc. There is
support for the scenario if user opened link in the same browser when he started
authenticationSession or in different browser etc.
>>>
>>> - Regarding PR, I've tried to squash the commits a bit. However PR still
consists of more commits to track at least what was done by me and what by Hynek. Do you
think it is the issue to have more commits in the PR?
>>>
>>> - This is hopefully the bigest task for the cross-dc support. My hope is that
PR can be reviewed and merged soon as the work is more and more unsynced with the latest
master and rebasing is a bit of pain. But I understand that this will require time. There
is change in 324 files :) There are still a lot things to cover for cross-dc, but I think
those can be done in smaller pieces and commit more often.
>>>
>>> [1]
>>>
http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
>>> [2]
>>>
http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
>>> [3]
>>>
http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html
>>>
>>> Marek
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev