Re: [keycloak-dev] Defining several Password Policies within a Realm

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@gemalto.com<mailto:Patrice.Amiel@gemalto.com>> 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<mailto:sthorger@redhat.com>] > *Sent:* lundi 14 janvier 2019 08:51 > > > *To:* AMIEL Patrice <Patrice.Amiel@gemalto.com<mailto:Patrice.Amiel@gemalto.com>> > *Cc:* keycloak-dev@lists.jboss.org<mailto:keycloak-dev@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@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev<https://emea01.s...