[keycloak-dev] Alternative flows on Browser refresh

[Bruno Oliveira]

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 at 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
> >>
> >
>
>