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