[keycloak-dev] Authentication flows - follow-up tasks and usability improvements
Marek Posolda
mposolda at redhat.com
Tue Nov 19 10:09:18 EST 2019
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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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>
> >> > >>> <mailto: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>
> <mailto: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
> <mailto:keycloak-dev at lists.jboss.org>
> >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >
> >> >
> >>
>
More information about the keycloak-dev
mailing list