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