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

[Stian Thorgersen]

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 at 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 at redhat.com]
> *Sent:* lundi 14 janvier 2019 08:51
> *To:* AMIEL Patrice <Patrice.Amiel at gemalto.com>
> *Cc:* keycloak-dev at 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.
>