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 >

Cool, I just assigned it to you, but let me know if you need any help. From my pov, 1 and 2 are the best alternatives. We can revisit it after your changes. On Fri, Nov 24, 2017 at 12:10 PM Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: Bruno, did you already started on https://issues.jboss.org/browse/KEYCLOAK-5466 ? I have one related issue https://issues.jboss.org/browse/KEYCLOAK-5797, which I plan to look at next week. I afraid it clashes a bit with the stuff related to https://issues.jboss.org/browse/KEYCLOAK-5466 . Especially since I think that some changes may be needed in AuthorizationEndpointBase. Do you mind to re-assign KEYCLOAK-5466 to me as well? I am pretty sure that I will at least address (1) during the https://issues.jboss.org/browse/KEYCLOAK-5797 . Marek Dne 24.11.2017 v 15:03 Marek Posolda napsal(a): > 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 >> >