[keycloak-dev] Authentication flows - follow-up tasks and usability improvements
Marek Posolda
mposolda at redhat.com
Thu Nov 14 05:24:51 EST 2019
On 13. 11. 19 12:52, Stian Thorgersen wrote:
>
>
> On Tue, 12 Nov 2019 at 22:00, Marek Posolda <mposolda at redhat.com
> <mailto: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?
Sure, I will try to schedule something. Replied to some of your comments.
>
>
>
> 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.
Yes, so probably have just something like ENABLED/DISABLED on the
conditions for now? Or don't have any checkbox/switch and automatically
assume that condition, which is in the authentication flow is enabled.
Then admin can remove the condition if he wants to "disable" it. I
probably vote for that option.
>
>
>
>
> 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
Ok
Question is, how exactly to hide the authenticators of disabled subflow,
so that UI is nice and clear for the administrators... IMO it will be
nice if it is still somehow visible that there are some hidden
authenticators in the disabled subflow. Maybe they can be somehow
collapsed and should be some tooltip or something, that those
authenticators are 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).
>
>
> 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.
Ok
The question is again, how to do that in the UI. I can try to do some
screenshots / HTML templates and maybe look at some Patternfly
components regarding this.
>
> 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.
I am not 100% sure if having 2 different UI is good? What you describe
below can be configured with the current authentication flow UI.
I can see that having "simple" UI, which will just allow enable 1st
factor and 2nd factor authenticators have some advantages, but it
probably have some side-effects too. More work for us, more potential
for bugs. It may be also less clear for administrators how to configure
custom authentication flow as they won't see what happens during the
default flow and hence they can't "inspire" from it.
> 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]
Few points regarding this:
- Right now, the default login form in the browser flow is still
"Username / password" form. The multi-factor prototype didn't change
this default behaviour. Should we change the default form to be
username-only form, so that next form can be adjusted based on which
credentials the particular user has? Basically have something like
Google? The side-effect is, that having UsernameForm as default allows
"username enumeration", but that IMO is not big issue for most of the
deployments.
- I think there will be usually different requirements for the
"First-factor WebAuthn" and "second-factor WebAuthn" . For example
"First-factor WebAuthn" may require WebAuthn authenticator with
"UserRequirement: REQUIRED" when the second-factor just
"UserRequirement: PRESENT" . However we still have this limitation that
there is single WebAuthn configuration (WebAuthn policy) per whole
realm. Same for OTP. So I think we may need to address this first.
Perhaps we can have a way, so that administrator can configure multiple
"Credential configuration" instances of same credential type in the
realm. Then he can link the particular "credential configuration" with
the Authenticator in the flow. So that the "First-factor WebAuthn"
authenticator has the configuration with the UserRequirement: REQUIRED"
and the second-factor with PRESENT.
I think this can be doable before February, we just need to agree on
priorities.
- We probably need some more flexibility regarding RequiredActions.
Basically have a possibility to have required action like "Register 2nd
factor credential" . So user will be required to register the
credential, but he should be able to choose which credential he
registers. IMO this is pretty complex thing, which may require separate
design documents. I have some doubts we can do it before February...
>
> 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.
Ok, so cancel button should be removed. Regarding "Back" button, I
replied on the slides.
>
>
>
> 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.
Ok
Marek
>
> Thanks for the feedback,
> Marek
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
More information about the keycloak-dev
mailing list