[keycloak-dev] Authentication sessions & Action tokens PR

Bill Burke bburke at redhat.com
Thu May 11 19:15:19 EDT 2017

Nice work...Cut/paste this to docs

On 5/11/17 4:33 PM, Marek Posolda wrote:
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

More information about the keycloak-dev mailing list