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

Wed Nov 13 06:52:49 EST 2019

On Tue, 12 Nov 2019 at 22:00, Marek Posolda <mposolda at redhat.com> wrote:

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

Added some comments, but would be good to go through this in person. Can we
have a chat sometime early next week?

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

I found the ability to configure requirement on a condition strange and
confusing. Perhaps we should enable/disable conditions for now, then
consider something more powerful next year. We can chat about this as well
on GMeet next week.

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

+1

>
> 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).
>

Need to see how it behaves after the updates, but I would think being able
to set requirement on an authenticator within a sub-flow where they are all
alternatives doesn't make sense.

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

I would focus on usability improvements on changing the default flows for
now, then we can polish custom flows later.

I was actually thinking that the default flows should not use the flow UI
at all, but rather some more high-level options. Just to illustrate the
idea (not sensible options):

Identity first login:  [ON]

Delegated
-------------
Cookie: [ON]
Kerberos: [configure]
IdP redirect: [configure]

First-factor
--------------
Password: [ON]
WebAuthn: [ON]

Second-factor
------------------
OTP: [ON]
WebAuthn: [ON]
Backup Codes: [ON]

>
> 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.
>
>
+1 Would also be good to make sure Conditions look different to
Authenticators

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

See my comment on the slides. I don't think we should have cancel or back
buttons. We should have:

* Something that displays the select user, with an option to start from
scratch to select another user.
* "Try another way" to select a different credential for the corresponding
step.

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

I don't think we should change the behavior from what it was previously.

>
> Thanks for the feedback,
> Marek
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>