On Tue, 12 Nov 2019 at 22:00, Marek Posolda <mposolda(a)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/13PpcT26WPTC7v34hS6rj8U63xyZx4lZrP...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev