Just thinking about the help. Do you have a chance to write an automated
test for the X509 scenario from
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
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
Bruno, did you already started on
? I have one related
, which I plan to look at
next week. I afraid it clashes a bit with the stuff related to
. Especially since I
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
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
> 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
> The 2 is possible but maybe harder to do, we will need to track
> whether there was some successful action OR whether some
> is already in state SUCCESS.
> 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, seems like the same applies to
>> Kerberos. To fix this, we need to change the way how it works
>> 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
>>  - https://issues.jboss.org/browse/KEYCLOAK-5466