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/13PpcT26WPTC7v34hS6rj8U63xyZx4lZrP...
>> > >>>
>> > >>> 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@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
>> >
>> >
>>