Re: [keycloak-dev] Alternative flows on Browser refresh
I am not sure when exactly we want to retry the alternative
authenticators like kerberos or X509? The possibilities are:
1) When user opens the secured application URL (which will redirect him
to Keycloak initial OIDC/SAML Authorization endpoint)
2) When user press browser "refresh" on username/password screen
3) When user press browser "refresh" on TOTP (or any possible additional
authenticator screen after username/password was already SUCCESS)
I wouldn't do 3. It would be likely complicated to implement when
thinking various corner cases (browser back/refresh/forward buttons,
authenticator state etc). And usability also won't help much IMO...
1 will be easier to implement. Is it sufficient or do we want also 2?
The 2 is possible but maybe harder to do, we will need to track whether
there was some successful action OR whether some authenticator is
already in state SUCCESS.
Marek
Dne 23.11.2017 v 12:15 Bruno Oliveira napsal(a):
Good morning,
For alternative flows like X509 browser, if something goes wrong
it will fall back to username/password form, as we already know.
But the flow is not executed again until the browser is closed.
Based on what Stian commented[1], seems like the same applies to
Kerberos. To fix this, we need to change the way how it works today,
by going through the list of all alternative flows on refresh,
executing them again.
Does it make sense? Should we have Jira as "enhancement" for this?
[1] - https://issues.jboss.org/browse/KEYCLOAK-5466