I guess we should just always go back to step 1 then. We could do this both for page
refreshes and maybe even login timeouts?
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 18 June, 2015 9:36:14 PM
Subject: Re: [keycloak-dev] kerberos retry issue we talked about
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
the server.
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com