[keycloak-dev] Authentication sessions & Action tokens PR

Marek Posolda mposolda at redhat.com
Mon May 15 06:52:26 EDT 2017

So the PR is merged.

The next step is to update docs, migrations, create the blogpost and 
describe that people may need to update their authenticators etc. We 
expect the feedback in next days/weeks, so if you have questions or if 
you are seeing that something is broken, feel free to blame us :) 
Hopefully it won't be so bad, and you will rather see the improvements 
instead of regressions.


On 12/05/17 01:15, Bill Burke wrote:
> 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
> _______________________________________________
> 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