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?

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)

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

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).

https://issues.jboss.org/browse/KEYCLOAK-11824 When authentication execution is added, we should make sure that some REQUIREMENT is selected by default

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.

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?

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?

Thanks for the feedback, Marek _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From our point of view, a required action where you could specify a

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>> 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> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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&gt; 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>> 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> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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&gt; 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&gt; 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&gt; 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>> 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> > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >>> > > >> _______________________________________________ > > >> keycloak-dev mailing list > > >> keycloak-dev(a)lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > >

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 >> > >> > >>

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&gt; 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&gt; > 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&gt; > 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&gt; > 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&gt; 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>> 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(a)lists.jboss.org&gt; > >> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >>> > >> > >> _______________________________________________ > >> > >> keycloak-dev mailing list > >> > >> keycloak-dev(a)lists.jboss.org > >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > >> > > >> > >

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

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.

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(a)redhat.com <mailto:mposolda@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(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 >

Hello, I think that the concept that using the same code, that is actions, for registration purposes in all cases is a good idea. I also think that having registration logic in the flows rather than as required actions at the end is the way to go. Marek’s example > 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 Is actually the same sort of concept that the one that Romain posted and that we’ve been playing with, except that in our case it doesn’t trigger actions, which lead us to duplicate code. However, after having discussed the situation with Romain, we think that maybe the existing methods that lead to the flows may not be enough. For example, we would like to send a email to a user that leads him to a “registration” flow for a 2^nd factor, but someone who attempts to simply log in without a 2^nd factor and though the normal login procedure would be barred from login (that is, that user would not see the registration). Currently, I think that the most that you can do with an email is set a required action for a user. I think that this is what led Johannes to suggest the required action into flow concept. But I think that it may be better to send a user directly into a flow, rather than marking a persistent state on a user with the required action.

For our specific case, being able to send to a user an entry point to a flow, rather than an action, would do the trick. For the email example, the administrator could select either an action or a flow to send to the user. Alistair *From:*Marek Posolda <mposolda(a)redhat.com&gt; *Sent:* vendredi, 22 novembre 2019 11:15 *To:* stian(a)redhat.com *Cc:* Poiffaut Romain <romain.poiffaut(a)elca.ch>; keycloak-dev(a)lists.jboss.org; Pages Laurent <laurent.pages(a)elca.ch>; Doswald Alistair <alistair.doswald(a)elca.ch&gt; *Subject:* Re: [keycloak-dev] Authentication flows - follow-up tasks and usability improvements 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(a)redhat.com <mailto:mposolda@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(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: <mailto:%0b>>> 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