Hi all, We are currently working on adding the capability to define several Password Policies for a given realm. The rationale is that in our systems, within a given realm, we have different "types" of accounts that have different constraints on password management. For instance: - Administrators shall have long and complex passwords, with a very short password expiration time - Regular users have a "normal" :P password strength, and medium expiration time - Accounts for technical/automated access to the system shall never expire and have very long passwords All these Users shall be part of the same Realm. Obviously, these 3 types are only an example and there might be a need of more types or less types of accounts for other deployments => the number of Password Policies is not fixed in advance. We would definitely like to push the work as a PR, but before doing that, we'd like to be sure that we are going on the good tracks so that this PR could be accepted. The idea is consequently, from Web UI perspectives: - To update the Password Policy pane so that we have first a list of what we could call "Password Policy Groups". Within this pane, an initial list would allow to list, create and edit the Password Policy Groups. - When creating or editing one of the available Password Policy Groups, a sub pane would allow to select the individual Password Policies to be added to the Group. - Then, on Users management section, a new drop-down field of the User edition page would enable to select the Password Policy Group to be applied to this specific User - The Password Policy Group page might remain under the Authentication menu area... but it might also be eligible to be moved to a dedicated area similar to the current "Group" area (indeed, we would then have a "Roles Groups" area (this is indeed what the current "Group" area is) and a "Password Policy Groups" area...) Note that it would maybe be more convenient to attach a Password Policy Group to a "Group" rather than to an individual User, but as Users may belong to several Groups, then it would generate conflicts when applying the individual Password Policies if they are conflicting (for example, one saying that the min password length is 10 characters while the other saying it is 15). Impacts are: - On the DB model and JPA classes to support a list of Password Policies (i.e. Password Policy Groups), - On the User classes to support attachment of a User to a Password Policy Group - On the GUI, as described above - On the authentication process, to select the right Password Policy - On the change password process, to select the right Password Policy - On the REST API Does this proposal make sense to you (any concern or recommendation) ? Thanks for your feedbacks Best regards, Patrice ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hi Stian, Thanks for your reply. I’m glad to see that you would welcome a PR on the topic ! To be sure that my understanding of your proposal is correct, let me rephrase what it could be: - Several “Password policies groups” might be defined within a single “Realm”, each of them having their own set of “Password Policies” with their own configuration values. In addition to that, you propose to add another information to each of the “Password policies groups”: a priority. - Contrary to my proposal, application of a “Password policy group” would not be on a per-User basis. Instead, a “Password policy group” would be applied to the “Groups”, meaning that a “Group” would now be able to gather Attributes, Roles and (new !) Password Policies for all the members of the “Group”. - Then, when a “User” needs to login or to change its password (i.e. to access to its password policies), then KeyCloak would get the list of “Groups” the user is member of, and then select the Group’s “Password policies group” that has the highest priority: this is the one to be applied for password policy. Is my understanding correct? I also understand that not everyone is using Groups, but if so, I don’t understand what you mean by “it may be useful to also add support for a role”. Do you want also to be able to attach a “Password policies group” to individual roles, and thus apply the same election of the “policy to be used” thanks to the priority, taking into account not only the “Password policies groups” attached to the “Groups” the “User” is member of, but also the “Password policies groups” attached to the “Roles” the “User” is granted to? I like the fact that “Password policies groups” are attached to “Groups” instead of “Users”… but the priority mechanism looks to me a bit complex to understand for Realm administrators… and it becomes quite odd when having “Password policies groups” attached to “Roles”, don’t you think so? Best regards, Patrice *From:* Stian Thorgersen [mailto:sthorger@redhat.com] *Sent:* lundi 14 janvier 2019 08:51 *To:* AMIEL Patrice <Patrice.Amiel(a)gemalto.com&gt; *Cc:* keycloak-dev(a)lists.jboss.org *Subject:* Re: [keycloak-dev] Defining several Password Policies within a Realm Hi, This is a feature that have had a few requests for it so we would welcome a PR. Assigning password policy groups to individual users is not the way to go. I'd suggest adding a priority to the password policy group where the password policy group with highest priority that applies to a user is used. This would allow adding different matching conditions for a policy. Initially it would be sufficient to match on a group of users, but it may be useful to also add support for a role as not everyone use groups at all. ------------------------------ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

Just my 2¢, this looks very similar to authorization policies that we already have - the same user/group/role/time/rules/JS stuff; maybe time-based *password* policies don't make much sense, but everything else does. The only difference is that authorization policies do simple grant/deny, and here the result should be a list of password policies to activate. Maybe we can reuse portions of existing authz code and/or GUI for that. Cheers, Dmitry On Fri, 2019-01-18 at 09:09 +0100, Stian Thorgersen wrote: > Implementation wise it will be more flexible to have multiple password > policies defined in a realm and have some logic defined on how to select > the correct password policy for a user. It sounds like are proposing to > have a password policy associated directly with a group, but I believe this > is a more complex, less flexible and harder to manage approach. > > I can imagine the following use-cases to select password policy for a > specific user: > > * Based on a group the user belongs to > * Based on a role the user has > * Based on which user federation provider the user comes from > * Based on identity provider links > > If a password policy is something that has: > > * The string representation of the policy (as we have today) > * A priority > * A condition that matches it against users > > Note: There also needs to be a way to define the default policy for the > realm > > That means we can support all mentioned use-cases above. I'm happy to > accept a contribution that only has supports to match on groups, but it has > to be implemented in a way where additional matching can easily be added, > so there should be an SPI to allow adding matchers. > > On Wed, 16 Jan 2019 at 17:00, AMIEL Patrice <Patrice.Amiel(a)gemalto.com&gt; > wrote: > > > Hi Stian, > > > > > > > > Thanks for your reply. I’m glad to see that you would welcome a PR on the > > topic ! > > > > > > > > To be sure that my understanding of your proposal is correct, let me > > rephrase what it could be: > > > > - Several “Password policies groups” might be defined within a > > single “Realm”, each of them having their own set of “Password Policies” > > with their own configuration values. In addition to that, you propose to > > add another information to each of the “Password policies groups”: a > > priority. > > > > - Contrary to my proposal, application of a “Password policy > > group” would not be on a per-User basis. Instead, a “Password policy group” > > would be applied to the “Groups”, meaning that a “Group” would now be able > > to gather Attributes, Roles and (new !) Password Policies for all the > > members of the “Group”. > > > > - Then, when a “User” needs to login or to change its password > > (i.e. to access to its password policies), then KeyCloak would get the list > > of “Groups” the user is member of, and then select the Group’s “Password > > policies group” that has the highest priority: this is the one to be > > applied for password policy. > > > > > > > > Is my understanding correct? > > > > > > > > I also understand that not everyone is using Groups, but if so, I don’t > > understand what you mean by “it may be useful to also add support for a > > role”. Do you want also to be able to attach a “Password policies group” > > to individual roles, and thus apply the same election of the “policy to be > > used” thanks to the priority, taking into account not only the “Password > > policies groups” attached to the “Groups” the “User” is member of, but also > > the “Password policies groups” attached to the “Roles” the “User” is > > granted to? > > > > I like the fact that “Password policies groups” are attached to “Groups” > > instead of “Users”… but the priority mechanism looks to me a bit complex to > > understand for Realm administrators… and it becomes quite odd when having > > “Password policies groups” attached to “Roles”, don’t you think so? > > > > > > > > Best regards, > > > > Patrice > > > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger@redhat.com] > > *Sent:* lundi 14 janvier 2019 08:51 > > > > *To:* AMIEL Patrice <Patrice.Amiel(a)gemalto.com&gt; > > *Cc:* keycloak-dev(a)lists.jboss.org > > *Subject:* Re: [keycloak-dev] Defining several Password Policies within a > > Realm > > > > > > > > Hi, > > > > > > > > This is a feature that have had a few requests for it so we would welcome > > a PR. > > > > > > > > Assigning password policy groups to individual users is not the way to go. > > I'd suggest adding a priority to the password policy group where the > > password policy group with highest priority that applies to a user is used. > > This would allow adding different matching conditions for a policy. > > Initially it would be sufficient to match on a group of users, but it may > > be useful to also add support for a role as not everyone use groups at all. > > > > > > ------------------------------ > > This message and any attachments are intended solely for the addressees > > and may contain confidential information. Any unauthorized use or > > disclosure, either whole or partial, is prohibited. > > E-mails are susceptible to alteration. Our company shall not be liable for > > the message if altered, changed or falsified. If you are not the intended > > recipient of this message, please delete it and notify the sender. > > Although all reasonable efforts have been made to keep this transmission > > free from viruses, the sender will not be liable for damages caused by a > > transmitted virus. > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hi, I’ve been reading the SPI documentation during the past days, but to be honest, I’m not 100% comfortable with your proposal. Can you please clarify what you have in mind for this? Indeed, I don’t really see who would create the SPI interface (and why an “ appliesTo” function?), who would implement it, and who would call it (and when)! (you see how foggy it is for the moment in my mind :P ) Thanks for your help ! Best regards, Patrice *From:* Stian Thorgersen [mailto:sthorger@redhat.com] *Sent:* lundi 21 janvier 2019 09:21 *To:* Dmitry Telegin <dt(a)acutus.pro&gt; *Cc:* AMIEL Patrice <Patrice.Amiel(a)gemalto.com>; keycloak-dev(a)lists.jboss.org *Subject:* Re: [keycloak-dev] Defining several Password Policies within a Realm Not sure I fully understand, but sounds a bit overkill. Here's a simple way do to it: Introduce a Password Policy Condition SPI that leverages component model. The provider can have a simple method: * boolean appliesTo(UserModel user) That allows creating implementations of it that can be dynamically configured. So pretty simple to implement a group, role, etc. condition. Most of the screens is in the admin console today as component model provides this. We already have role selects and I think there is a group selector as well. On Fri, 18 Jan 2019 at 23:06, Dmitry Telegin <dt(a)acutus.pro&gt; wrote: Just my 2¢, this looks very similar to authorization policies that we already have - the same user/group/role/time/rules/JS stuff; maybe time-based *password* policies don't make much sense, but everything else does. The only difference is that authorization policies do simple grant/deny, and here the result should be a list of password policies to activate. Maybe we can reuse portions of existing authz code and/or GUI for that. Cheers, Dmitry On Fri, 2019-01-18 at 09:09 +0100, Stian Thorgersen wrote: > Implementation wise it will be more flexible to have multiple password > policies defined in a realm and have some logic defined on how to select > the correct password policy for a user. It sounds like are proposing to > have a password policy associated directly with a group, but I believe this > is a more complex, less flexible and harder to manage approach. > > I can imagine the following use-cases to select password policy for a > specific user: > > * Based on a group the user belongs to > * Based on a role the user has > * Based on which user federation provider the user comes from > * Based on identity provider links > > If a password policy is something that has: > > * The string representation of the policy (as we have today) > * A priority > * A condition that matches it against users > > Note: There also needs to be a way to define the default policy for the > realm > > That means we can support all mentioned use-cases above. I'm happy to > accept a contribution that only has supports to match on groups, but it has > to be implemented in a way where additional matching can easily be added, > so there should be an SPI to allow adding matchers. > > On Wed, 16 Jan 2019 at 17:00, AMIEL Patrice <Patrice.Amiel(a)gemalto.com&gt; > wrote: > > > Hi Stian, > > > > > > > > Thanks for your reply. I’m glad to see that you would welcome a PR on the > > topic ! > > > > > > > > To be sure that my understanding of your proposal is correct, let me > > rephrase what it could be: > > > > - Several “Password policies groups” might be defined within a > > single “Realm”, each of them having their own set of “Password Policies” > > with their own configuration values. In addition to that, you propose to > > add another information to each of the “Password policies groups”: a > > priority. > > > > - Contrary to my proposal, application of a “Password policy > > group” would not be on a per-User basis. Instead, a “Password policy group” > > would be applied to the “Groups”, meaning that a “Group” would now be able > > to gather Attributes, Roles and (new !) Password Policies for all the > > members of the “Group”. > > > > - Then, when a “User” needs to login or to change its password > > (i.e. to access to its password policies), then KeyCloak would get the list > > of “Groups” the user is member of, and then select the Group’s “Password > > policies group” that has the highest priority: this is the one to be > > applied for password policy. > > > > > > > > Is my understanding correct? > > > > > > > > I also understand that not everyone is using Groups, but if so, I don’t > > understand what you mean by “it may be useful to also add support for a > > role”. Do you want also to be able to attach a “Password policies group” > > to individual roles, and thus apply the same election of the “policy to be > > used” thanks to the priority, taking into account not only the “Password > > policies groups” attached to the “Groups” the “User” is member of, but also > > the “Password policies groups” attached to the “Roles” the “User” is > > granted to? > > > > I like the fact that “Password policies groups” are attached to “Groups” > > instead of “Users”… but the priority mechanism looks to me a bit complex to > > understand for Realm administrators… and it becomes quite odd when having > > “Password policies groups” attached to “Roles”, don’t you think so? > > > > > > > > Best regards, > > > > Patrice > > > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger@redhat.com] > > *Sent:* lundi 14 janvier 2019 08:51 > > > > *To:* AMIEL Patrice <Patrice.Amiel(a)gemalto.com&gt; > > *Cc:* keycloak-dev(a)lists.jboss.org > > *Subject:* Re: [keycloak-dev] Defining several Password Policies within a > > Realm > > > > > > > > Hi, > > > > > > > > This is a feature that have had a few requests for it so we would welcome > > a PR. > > > > > > > > Assigning password policy groups to individual users is not the way to go. > > I'd suggest adding a priority to the password policy group where the > > password policy group with highest priority that applies to a user is used. > > This would allow adding different matching conditions for a policy. > > Initially it would be sufficient to match on a group of users, but it may > > be useful to also add support for a role as not everyone use groups at all. > > > > > > ------------------------------ > > This message and any attachments are intended solely for the addressees > > and may contain confidential information. Any unauthorized use or > > disclosure, either whole or partial, is prohibited. > > E-mails are susceptible to alteration. Our company shall not be liable for > > the message if altered, changed or falsified. If you are not the intended > > recipient of this message, please delete it and notify the sender. > > Although all reasonable efforts have been made to keep this transmission > > free from viruses, the sender will not be liable for damages caused by a > > transmitted virus. > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.... ------------------------------ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.