On 6/18/2015 1:45 PM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Thursday, 18 June, 2015 5:54:02 PM
> Subject: [keycloak-dev] kerberos retry issue we talked about
> Hitting the cancel button works. Hitting the cancel button sends you
> back to the app, which sends you back to keycloak and starts a new
> client session. So that would work fine.
> What doesn't work is refreshing the page. Kerberos won't be attempted
> again. Would it be ok that any browser page refresh might completely
> reset the authentication flow and the user has to re login? If so, I
> think I have a solution to the problem, but it would take quite a bit of
> refactoring of the auth spi...Not another two months of work :) But
> probably another few days or a week.
As long as the user is actively refreshing the page that works, but I wonder if
there's cases where it could break things. For example if there's high load on the
system and some requests time out, then when user retries the request they end up in the
beginning of the login flow again.
Nothing would break, the user would just have to start over. If there
is only 1 login form, then this isn't an issue at all.
BTW, OIDC has an issue with this too if the user hits a browser refresh
in the middle of the code_to_token exchange. Since the code can only be
exchanged once, the browser refresh will be a second request and fail.
SAML doesn't have this issue because there is no out of band callback to
Honestly, I think it makes the algorithm much easier, simpler, and safer
if there is a complete client session reset on a page refresh.
Why could it not just continue the flow at the step it's on?
Basically a challenge wouldn't count as moving on. So when password authenticator
sends the challenge for the first request, you'd still be on stage 0 when the user
refreshes the page.
You're forgetting the original problem. We want Kerberos to be
re-attempted on a page refresh. The algorithm would have to know where
it had to go back and retry. Forms are contained in a nested flow. How
would you know when to hop back up to the parent flow and retry things?
It just gets real complicated.
There's a few problems with browser page refresh:
* On a page refresh, the exact request is resubmitted. This means a
POST sends a POST to the previous authenticator's URL action.
* You need to guard against an attacker trying to jump around in a flow.
* What about back button?
Also, What I"m doing right now is to change the ClientSEssionCode every
form challenge. So, page refresh is actually completely broken now :(
Man, I need to rethink this. Actually even within the old code, refresh
page was broken when you went from authentication to the required action
page and then hit refresh.
JBoss, a division of Red Hat