[keycloak-dev] kerberos retry issue we talked about

[Bill Burke]

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.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com