[keycloak-dev] Authentication flows - follow-up tasks and usability improvements
Stian Thorgersen
sthorger at redhat.com
Tue Nov 26 03:31:00 EST 2019
I agree the recover password flow isn't ideal and could do with some
improvements. I would target that to next round though.
On Fri, 22 Nov 2019 at 11:15, Marek Posolda <mposolda at redhat.com> wrote:
> On 22. 11. 19 10:45, Stian Thorgersen wrote:
>
> I agree that it is cleaner to do it during the authentication stage as
> long as it delegates to actions to do the actual registration.
>
> I can see cases where a user should only be allowed to login if they
> already have MFA registered, as well as cases when they are allow to login
> after they have registered an MFA.
>
> Yes, so with this configuration and with assuming that user doesn't yet
> have any credential configured, he will be able to choose the credential to
> register from those 4 possibilities. Otherwise if he already has some
> credential configured (EG. OTP), he will need to provide this OTP during
> authentication.
>
> BTV. One thing, which we didn't yet talked much about is the ability to
> reset the credential. For example if user above losts his phone, then he
> should be somehow able to restart OTP or even choose different mechanism to
> register for 2-factor authentication. Currently it is possible to reset
> OTP, but you need to use "reset-credential" flow for it. This flow requires
> user to reset all his credentials, not just one of them, which is usually
> requested IMO.
>
> Also it is currently triggered by click to link "Forget password" . Which
> is far from obvious that this can be used to reset OTP credential (together
> with required reset of password credential). JIRA exists to improve on
> this: https://issues.jboss.org/browse/KEYCLOAK-11919 . I am not sure
> about priority, but it affects end user experience and hence probably could
> be considered. However it may turn into some non-trivial amount of work to
> do it a bit more properly...
>
> Marek
>
>
> I'm thinking something along the lines of:
>
> | - Authenticate with MFA [ ] Alternative [x] Required [ ] Conditional [ ] Disabled
>
> | - OTP [x] Alternative [ ] Required [ ] Disabled
>
> | - WebAuthn [x] Alternative [ ] Required [ ] Disabled
>
> | - Hardware Token [x] Alternative [ ] Required [ ] Disabled
>
> | - Register MFA [x] Alternative [ ] Required [ ] Disabled
>
>
> On Wed, 20 Nov 2019 at 21:21, Marek Posolda <mposolda at redhat.com> wrote:
>
>> IMO when 2-factor authentication is required for the flow, it may be better if we do "Register 2nd factor credential" *during* authentication, rather than through the action *after* authentication as it is now.
>>
>> One reason is that it will be easier to implement with less potential corner-cases. The orchestration of "register 2nd factor credentials" is just easier when authentication flows can be used instead of bit
>> limited required actions.
>>
>> Another reason is, that it is more proper IMO. For example let's assume that I have "3-factor" authentication enabled. In other words, I have some additional FORM authenticator triggered after 2nd-factor
>> authentication. So the flow looks something like this:
>>
>> Auth type | Requirement
>>
>> -----------------------------------------------------------------------------------------------
>>
>> Cookie [x] Alternative [ ] Required [ ] Disabled
>>
>> Kerberos [x] Alternative [ ] Required [ ] Disabled
>>
>> Identity Provider Redirector [x] Alternative [ ] Required [ ] Disabled
>>
>> Authenticate with Keycloak [x] Alternative [ ] Required [ ] Conditional [ ] Disabled
>>
>> | - Username Password Form [ ] Alternative [x] Required [ ] Disabled
>>
>> | - 2nd factor [ ] Alternative [x] Required [ ] Conditional [ ] Disabled
>>
>> | - OTP [ ] Alternative [x] Required [ ] Disabled
>>
>> | - Some cool 3rd factor form [ ] Alternative [x] Required [ ] Conditional [ ] Disabled
>>
>> In case that user doesn't yet have the 2-nd factor credential registered, then what currently happens is:
>>
>> - User authenticates with username/password
>> - Then during OTP, the "Register OTP" requiredAction is silently added to his account
>> - Then he see the "Some cool 3rd factor form" and needs to authenticate with him
>> - Finally the authentication finished and user is now required to register 2nd factor (OTP)
>>
>> IMO the issue is, that user should ideally first register 2nd factor before he is even able to see the "Some cool 3rd factor form" and authenticate with it.
>>
>> Regarding implementation, I can think that Authenticator interface possibly won't call the method "setRequiredActions" as it is now, but instead particular Authenticator will "delegate" the registration of
>> credential to corresponding RequiredActionProvider directly during authentication. So administrator will be still able to add required actions like "Setup TOTP" or "Setup WebAuthn" to the user and users will
>> be able to register concrete 2nd factor through new account console with AIA. This will be still possible.
>>
>> The configuration of the flow mentioned by Romain, which requires 2nd-factor and allows user to choose from 3 alternatives will be simplified like this:
>>
>> Auth type | Requirement
>>
>> -----------------------------------------------------------------------------------------------
>>
>> Cookie [x] Alternative [ ] Required [ ] Disabled
>>
>> Kerberos [x] Alternative [ ] Required [ ] Disabled
>>
>> Identity Provider Redirector [x] Alternative [ ] Required [ ] Disabled
>>
>> Authenticate with Keycloak [x] Alternative [ ] Required [ ] Conditional [ ] Disabled
>>
>> | - Username Password Form [ ] Alternative [x] Required [ ] Disabled
>>
>> | - Authenticate with MFA [ ] Alternative [x] Required [ ] Conditional [ ] Disabled
>>
>> | - OTP [x] Alternative [ ] Required [ ] Disabled
>>
>> | - WebAuthn [x] Alternative [ ] Required [ ] Disabled
>>
>> | - Hardware Token [x] Alternative [ ] Required [ ] Disabled
>>
>> No separate subflow for "Register MFA" will be needed. Also no conditions will be involved. The 2nd-factor is required by admin in this case, so after username/password form, user will see the screen where he can
>> choose between 3 alternative 2nd-factor credentials to register. This will be triggered during authentication and orchestrated by authentication flow.
>>
>> WDYT?
>>
>> Marek
>>
>>
>> On 20. 11. 19 12:55, Stian Thorgersen wrote:
>>
>> An action doesn't just have to be a required action set on the user
>> anymore. We have support for AIA (application initiated actions, where an
>> application can request the user to complete an action) as well as actions
>> themselves can encode logic on when they should execute.
>>
>> The above doesn't help with the case you are mentioning though with
>> allowing a user to select between different actions where they are required
>> to enable two-factor authentication, but have options on what to implement.
>> That is something we have to figure out pretty soon. My 2 cents on it is
>> that we need an action that can list the options to the user. Not sure how
>> exactly that should look like though and how it should be wired in with the
>> code.
>>
>> On Wed, 20 Nov 2019 at 10:46, Poiffaut Romain <romain.poiffaut at elca.ch>
>> wrote:
>>
>>> Hello,
>>>
>>> We were also using required actions at the beginning but due to some
>>> limitations of required actions we also had to implement some
>>> authenticators to circumvent them.
>>> The main limitation that we have identified is linked to the purpose
>>> itself of required actions, which persists the added action onto the user.
>>> In my view, in some cases it may not be the appropriate tool:
>>> Consider a scenario of a company which enforces 2FA only for external
>>> access.
>>> If a user never uses the extranet, he may live without the 2FA.
>>> Let's imagine this user once tries to connect from external premises, a
>>> required action will be automatically added to the user. For some reasons,
>>> user changes its mind and cancels the process. Then he resumes working from
>>> the internal network, and does not need the 2FA. However, the user will
>>> still have to register 2FA anyway, since the required action is still
>>> attached to this user
>>>
>>> Moreover, the authentication flows are highly customizable, especially
>>> with the new conditional flows. So it sounds an interesting feature to be
>>> able to redirect a user to a flow. That way we would have the benefit of
>>> the two mechanisms (high customization of flow and email sending or AIA).
>>>
>>> As an example, we have implemented the multi-factor registration with
>>> credential registration authenticator. With the following flow, the user
>>> decides which kind of credential he want to register among the configured
>>> alternatives.
>>>
>>> Auth type | Requirement
>>>
>>> -----------------------------------------------------------------------------------------------
>>> Cookie [x] Alternative [ ] Required
>>> [ ] Disabled
>>> Kerberos [x] Alternative [ ] Required
>>> [ ] Disabled
>>> Identity Provider Redirector [x] Alternative [ ] Required
>>> [ ] Disabled
>>> Authenticate with Keycloak [x] Alternative [ ] Required [ ]
>>> Conditional [ ] Disabled
>>> | - Username Password Form [ ] Alternative [x] Required
>>> [ ] Disabled
>>> | - Authenticate with MFA [ ] Alternative [ ] Required [x]
>>> Conditional [ ] Disabled
>>> | - Condition User Configured [x] Required
>>> [ ] Disabled
>>> | - OTP [x] Alternative [ ] Required
>>> [ ] Disabled
>>> | - WebAuthn [x] Alternative [ ] Required
>>> [ ] Disabled
>>> | - Hardware Token [x] Alternative [ ] Required
>>> [ ] Disabled
>>> | - Register MFA [ ] Alternative [ ] Required [x]
>>> Conditional [ ] Disabled
>>> | - Condition User not Configured [x] Required
>>> [ ] Disabled
>>> | - OTP Registration [x] Alternative [ ] Required
>>> [ ] Disabled
>>> | - WebAuthn Registration [x] Alternative [ ] Required
>>> [ ] Disabled
>>> | - Hardware Token Registr. [x] Alternative [ ] Required
>>> [ ] Disabled
>>>
>>> Romain
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: keycloak-dev-bounces at lists.jboss.org <
>>> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
>>> Sent: mercredi, 20 novembre 2019 08:43
>>> To: Marek Posolda <mposolda at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Subject: Re: [keycloak-dev] Authentication flows - follow-up tasks and
>>> usability improvements
>>>
>>> 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/13PpcT26WPTC7v34hS6rj8U63xyZx4
>>> >> lZrPdeHF7qLkdU/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
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >>
>>> >>
>>> >
>>> _______________________________________________
>>> 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