[keycloak-dev] kerberos retry issue we talked about

[Stian Thorgersen]

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 at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at 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 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
>