[keycloak-dev] kerberos retry issue we talked about

[Marek Posolda]

I wonder if ClientSession should track the state of all authentication 
mechanisms? Then on refresh, you don't need to retry those, which were 
already successfully finished.

Example: You want both password and TOTP authentication. After login 
with username/password on form1, user will see form2 with TOTP. When he 
do refresh at this stage, he won't be put into the password screen 
(form1) because ClientSession has already PASSWORD mechanism in state 
SUCCESS . But the mechanisms, which are not in SUCCESS but in ATTEMPTED 
state (Cookie, Kerberos, ...) will be tried again and then user is put 
directly into TOTP form (form2).

Marek


On 19.6.2015 09:47, Stian Thorgersen wrote:
> 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
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev