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(a)elca.ch
<mailto:romain.poiffaut@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(a)lists.jboss.org
<mailto:keycloak-dev-bounces@lists.jboss.org>
<keycloak-dev-bounces(a)lists.jboss.org
<mailto:keycloak-dev-bounces@lists.jboss.org>> On Behalf Of Stian
Thorgersen
Sent: mercredi, 20 novembre 2019 08:43
To: Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>>
Cc: keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@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(a)redhat.com
<mailto:mposolda@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(a)kodet.no <mailto:johannes@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(a)redhat.com <mailto:sthorger@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(a)kodet.no <mailto:johannes@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(a)redhat.com <mailto:mposolda@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(a)redhat.com <mailto:mposolda@redhat.com>> wrote:
>> >> > >> On 13. 11. 19 12:52, Stian Thorgersen wrote:
>> >> > >>>
>> >> > >>> On Tue, 12 Nov 2019 at 22:00, Marek Posolda
>> >> > >>> <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>
<mailto:mposolda@redhat.com <mailto:mposolda@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(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org> <mailto:
>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
>> >> > >>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> > >>>
>> >> > >> _______________________________________________
>> >> > >> keycloak-dev mailing list
>> >> > >> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>> >> > >>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> >
>> >> >
>> >>
>>
>>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev