4:08 p.m.
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.