[keycloak-dev] Alternative flows on Browser refresh

[Marek Posolda]

Cool, Thanks.

Just thinking about the help. Do you have a chance to write an automated 
test for the X509 scenario from 
https://issues.jboss.org/browse/KEYCLOAK-5466 and put it to some your 
branch? Not sure if for scenario 1 or 2 or both? I can then cherry-pick 
and see if the test will be automagically fixed after my changes :) WDYT?


On 24/11/17 15:59, Bruno Oliveira wrote:
> 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 
> <mailto: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
>     >>
>     >
>