[keycloak-dev] Authentication flows - follow-up tasks and usability improvements

[Marek Posolda]

Based on the discussion within Keycloak team and with CloudTrust team 
and also based on the other facts, there are still quite a few follow-up 
tasks regarding usability and further improvements. It will be good to 
clarify the priorities of the follow-up tasks and also how exactly to 
address them. Regarding usability, it will be nice to receive feedback, 
so we're on the same page how screens should look like.


1) Improvement for end-user during authentication in regards to select 
alternative credential for authentication. This is something, which we 
discussed within the Keycloak team. The idea is to provide users the 
same/similar screens like Google does. We are a bit more constrained as 
Google doesn't allow administrators to have custom authentication flows 
and hence doesn't need to care too much about various corner cases. So 
not sure if we can achieve same usability for all the possible 
authentication flow configurations. But we probably have a space for 
improvement here.

I've created google docs 
https://docs.google.com/presentation/d/13PpcT26WPTC7v34hS6rj8U63xyZx4lZrPdeHF7qLkdU/edit?usp=sharing 
with some example scenarios how could authentication of end user looks 
like for particular authentication flow configuration and for particular 
set of credentials available to target user. Comments should be allowed 
to anyone, so feel free to comment here or in the docs. Also if you have 
idea for some more use-cases to cover, feel free to write here.

IMO this looks like quite a priority as it affects end-users usability 
and hence will be nice to have this before February?


2) More flexibility around conditional authenticators

Some basic ideas, which we discussed within Keycloak team around 
conditional authenticators are:
- Ability that each condition is able to "vote" rather than have 
requirements on conditional executions. It could be something similar to 
authorization policies available in Keycloak authorization services.

- Ability to compound conditions based on "AND" / "OR" logical 
conditions. For example allow easily to configure that particular 
subflow will be triggered if (condition1 == true || (condition2 == true 
&& condition3 == true)

- Ability to configure conditions. For example ability to have 
positive/negative logic for RoleCondition similarly like RolePolicy in 
authorization services has.

- Ability to integrate with the 3rd party engine for adaptive authentication

- Ability for administrators to clearly see how conditions are 
evaluated. Ideally have same/similar level of flexibility like 
Authorization policies have

I can try to do some more concrete proposal with example of screens, 
hopefully later this week. If anyone wants to start on some proposal 
around this before, feel free to go. IMO this is something, which 
doesn't have so big priority like (1) as it doesn't affect end users. 
The question is, whether to postpone improvements around conditions to 
later next year when we start on step-up authentication (which will 
require good flexibility around conditions and hence should help to 
naturally address this)



3) Usability improvements in the admin console in the "Authentication 
flows" screen. The plan is to rewrite admin console in the future and 
improve on various screens, however until that is done, we can probably 
improve usability a bit even in the current admin console to make the 
things slightly more friendly for the administrators. I consider those 
things a low hanging fruits in comparison to (2) and hence hopefully 
doable before February.

https://issues.jboss.org/browse/KEYCLOAK-12013 Hide the subflows if the 
parent flow is disabled

https://issues.jboss.org/browse/KEYCLOAK-11968 Ensure that REQUIRED and 
ALTERNATIVE executions are not mixed at same level. ALTERNATIVE 
executions are defacto ignored/disabled when they are used together with 
REQUIRED executions, hence it will be nice if admin is aware of that and 
won't have possibility to configure ALTERNATIVE at same level as 
REQUIRED (or at least is WARNED somehow that this configuration doesn't 
makes sense and ALTERNATIVES will be ignored).

https://issues.jboss.org/browse/KEYCLOAK-11824 When authentication 
execution is added, we should make sure that some REQUIREMENT is 
selected by default

https://issues.jboss.org/browse/KEYCLOAK-11969 Hide the conditional 
authenticator if it is configured outside of conditional flow. This JIRA 
is related to the conditional executions and hence I am not sure whether 
to address it together with other improvements related to conditional 
authenticators. However it is low hanging fruit in comparison to (2), so 
probably doable.



4) Other usability improvements. Similarly like (3), those are low 
hanging fruits and likely doable before February.

https://issues.jboss.org/browse/KEYCLOAK-12011 Remove cancel button from 
OTP form. IMO it will be better for usability if "Cancel" button is 
removed from the OTP form. Form already has the "Back" button, which 
provides more flexiblity. This is a bit related to the topic (1). WDYT?


https://issues.jboss.org/browse/KEYCLOAK-11922 Apply password history 
policy when password reset by admin. After applying multi-factor 
prototype, the password history policy is not applied when password 
reset by admin. It is applied just in case when it is reset by user 
himself. IMO this behaviour is fine and can even have better security 
(The case when admin randomly guess the password of some user can cause 
admin to be tempted to try this password against some other web 
application and authenticate as that user). Any preference on the behaviour?

Thanks for the feedback,
Marek