[keycloak-dev] kerberos retry issue we talked about

[Marek Posolda]

Fact is that for production environment using Kerberos (FreeIPA or 
Windows domain backed by ActiveDirectory) the kerberos ticket is usually 
tight to the desktop login of user and user either has it or not. The 
flow with "display the form, then kinit from CMD to obtain kerberos 
ticket and then refresh the page to retry kerberos" is probably 
something more for development use.

 From the possibilities, the (a) seems to me slightly better? For 
example if you accidentally have 2 opened tabs with the login form in 
the browser and you login successfully in tab1, you will have SSO 
cookie, so refresh on tab2 should retry the cookie and logged you 
successfully. In case (b) it won't logged you because cookie won't be 
retried. But not sure if this is not corner case as well ;-)

Marek

On 19.6.2015 15:15, Bill Burke wrote:
> On 6/19/2015 4:56 AM, Marek Posolda wrote:
>> 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).
>>
>
> The problem is what if after page refresh, a different user is logged 
> in with Kerberos than what you logged in with password? You'd have to 
> know exactly how to clean up the ClientSession to get to a valid 
> state.  Also we may have Authenticators where retrying ATTEMPTED might 
> be a bad thing.  Doing this makes me nervous as this makes the 
> algorithm more complex and I think that we'll miss something and get 
> something wrong in the algorithm. For example, you would have to make 
> sure that for ALTERNATIVES, you don't re-attempt them if an 
> ALTERNATIVE later in the flow wasn't successful.  I'm worried there 
> are other cases like that or that an Authenticator would have to have 
> knowledge about the flow and code for it.
>
>
> Let me explain how page refresh is detected.  The "action url" of a 
> login form is /authenticate?code={code}&execution={execution}.  When 
> the login form sends a challenge it sets the "current execution" of 
> the ClientSession.  It also specifies the "execution" query parameter 
> in the action URL.  If the "execution" query param matches the 
> "current execution", then the action is processed by the 
> Authenticator, and the Flow continues where it left off.  If the 
> "execution" param doesn't match, then there was probably a page 
> refresh or somebody hit a back button or an attacker is trying to 
> bypass the flow.
>
> There are two options which I can easily implement for page refresh:
>
> a) A page refresh resets the client session
> b) A page refresh reiterates on the flow, skipping any authenticators 
> already processed.  It would *NOT* re-attempt ATTEMPTED authenticators.
>
> For a) Kerberos would be retried, but you would have to log in from 
> the beginning.  For b)  Kerberos would not be retried, but you could 
> continue where you left off.  IMO, I would prefer b) because there is 
> already a "cancel" button on the login form which can reset the flow.
>
>
>