[keycloak-dev] kerberos retry issue we talked about

[Bill Burke]

On 6/18/2015 1:45 PM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at 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