[keycloak-dev] Authentication flows - follow-up tasks and usability improvements
Stian Thorgersen
sthorger at redhat.com
Tue Nov 19 06:18:16 EST 2019
It makes sense, but not convinced about the approach with custom flows for
required actions. I think that would be quite a lot of effort and at the
same time not have a wide use.
Actions can already have logic within the action itself on whether or not
it should be triggered during a login. It seems in your use-case that would
be sufficient. One way you could do that is to add a custom attribute to
the user "identity.verified", when you want the action to trigger you set
the attribute to "not-verified" then the action would set it to "verified"
when user has verified their identity. Would be similar to terms and
condition.
On Mon, 18 Nov 2019 at 10:16, Johannes Knutsen <johannes at kodet.no> wrote:
> One specific use-case is identity verification of users using passport
> or other types of identity papers. Such a process is typically a
> default required action which is required before the user is allowed
> to login. But there are also cases where a user must be identified at
> a later point of time. This could be triggered by some external system
> which would add the required action to the user entity in Keycloak.
> For example an external fraud system could flag the user as a suspect
> and add the required action to the user. Scheduling of required action
> would also be an interesting model, where you could configure Keycloak
> to run a required action every x days.
>
> The process of identification is typically a complete flow which could
> involve several required steps and must be configurable. The current
> required actions does not seem to have any way of adding configuration
> properties? And it would be nice if we could model this flow as a flow
> in Keycloak the same way we model authentication and registration
> browser flow.
> Currently, the best way we have found is to create a custom
> authenticator which is added to registration, password reset, and
> authentication flows. But this requires us to configure the
> authenticators multiple times with the possibility of inconsistencies
> between the configuration.
>
> Another example is the current required action "UpdateProfile", which
> does all the verification logic itself. But instead, the UpdateProfile
> action could have been an UpateProfile flow which defined several
> required or alternative actions which defined the process of
> UpdateProfile. The required action would then just point to that flow.
>
> Does this make sense?
>
> - Johannes
>
>
> On Sun, Nov 17, 2019 at 9:25 PM Marek Posolda <mposolda at redhat.com> wrote:
> >
> > Thanks for the feedback. But I am not 100% sure I understand your
> use-case.
> >
> > If I understand correctly, at some point, you want the user to do
> > something - for example confirm his contact details. Is this something,
> > which administrator should specify (EG. administrator will need to add
> > requiredAction to the user in admin console) or is it something
> > requested by some applications?
> >
> > Maybe AIA and step-up authentication is solution for your use-case, but
> > will be good to clarify exactly how your ideal use-case looks like.
> >
> > Thanks,
> > Marek
> >
> > On 15. 11. 19 21:24, Johannes Knutsen wrote:
> > > Sorry if you find this a little off topic, but I found this discussion
> > > interesting.
> > > Regarding RequiredActions, we have some use cases where we would like
> > > to build custom required flows. For example for user identification
> > > (think scanning of passports), regular confirmation of contact details
> > > and so on.
> > > From our point of view, a required action where you could specify a
> > > custom authentication flow the same way you select a flow for IdP
> > > First/Post login flow, would be really nice. This way you could mostly
> > > reuse existing logic and flexibility.
> > >
> > > Do you have any thoughts on how much changes this would require? Do
> > > you have other more specific thoughts on how required actions could be
> > > more flexible. Currently, I find them a little useless since they are
> > > not configurable as regular authenticators.
> > >
> > > Johannes
> > >
> > > On Thu, Nov 14, 2019 at 11:27 AM Marek Posolda <mposolda at redhat.com>
> wrote:
> > >> 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
> > >>>
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
>
>
More information about the keycloak-dev
mailing list