[keycloak-dev] Authentication flows - follow-up tasks and usability improvements
Stian Thorgersen
sthorger at redhat.com
Wed Nov 20 02:42:47 EST 2019
A multi-step action is something completely different to supporting custom
flows per action though.
On Tue, 19 Nov 2019 at 16:09, Marek Posolda <mposolda at redhat.com> wrote:
> I guess it could be the case when some "action" requires multiple screens?
> For example "passport validation" would consider of 4 separate steps/forms
> and each of them needs to be properly filled by the user.
>
> I can see it can be useful that action points to the custom flow, but also
> not sure how common this use-case is...
>
> Marek
>
> On 19. 11. 19 15:33, Stian Thorgersen wrote:
>
> I agree it would be good to be able to configure actions. I guess that's
> the main reason you're using an authenticator and not an action? I think
> using an action instead would be simpler in your case than an authenticator.
>
> One way you could configure the action until we have support for
> configurable actions would be to just use some custom realm attributes.
>
> To be honest I don't fully understand why you need a custom flow. As it
> seems you just have an action for the user to validate their identity,
> which based on some condition should be triggered during login.
>
>
> On Tue, 19 Nov 2019 at 13:02, Johannes Knutsen <johannes at kodet.no> wrote:
>
>> Hard to tell how wide the usage is/would be and it probably varies a
>> lot between business sectors. I will be happy to present our use cases
>> in more details if you are interested.
>>
>> Your proposed solution is basically the way we solved it, but the
>> required actions are hard to make generic to be used in different
>> realms because the don't have any configuration per realm. So at least
>> have them configurable per realm would help a lot.
>> The basic terms and condition is quite simple and in our case the code
>> because quite complex when we must design the flow in code.
>
>
>> In some cases we have also used a custom authenticator in the
>> registration flow, but it seems like executors marked as Required in
>> the registration flow can be bypassed by registering the user and then
>> go to reset password and trigger the reset password flow. This case is
>> solved by adding the same authenticator to the reset password flow,
>> but then we end up with duplicate configuration. Is this by design or
>> is it a bug or unwanted side effect of how this is designed?
>>
>
> I'd say it seems like it's valid behavior and the unwanted side effects is
> probably more down to the fact that you are trying to write an action as an
> authenticator.
>
> If a user completes the registration form, but then abandons the flow,
> they are free to continue from any other flow. To prevent that you'd have
> to make sure your custom registration flow doesn't have a valid user until
> after it has gone through all the steps required. Not sure how easy that
> would be, but again it feels like it's down to using the wrong tool for the
> job (authenticator vs action).
>
>
>>
>> If anyone else in the community have made custom required actions, it
>> would be nice to hear about it. I like the concept they represent and
>> to have them a little more flexible would make some authentication
>> flows simpler in our cases.
>>
>
> Perhaps it would be best to start a new thread around this as it's buried
> within a different topic at the moment.
>
>
>>
>> - Johannes
>>
>> On Tue, Nov 19, 2019 at 12:18 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> >
>> > 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