What is needed is to create a new PasswordPolicyConditionSPI that leverages
the component model. This allows adding a configured
PasswordPolicyConditionProvider to a specific password policy. The
component model has support for various built-in configuration types like
picking a role or group.
The password policy could even still be stored as a single string, would
just have something like "conditionProvider(<id>)" which would allow
creating an instance of the policy linked to the configured
When looking up the correct password policy for a user we'd simply loop
through the registered password policies calling the appliesTo method until
it returns true.
On Mon, 4 Feb 2019 at 09:49, AMIEL Patrice <Patrice.Amiel(a)gemalto.com>
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 !
*From:* Stian Thorgersen [mailto:email@example.com]
*Sent:* lundi 21 janvier 2019 09:21
*To:* Dmitry Telegin <dt(a)acutus.pro>
*Cc:* AMIEL Patrice <Patrice.Amiel(a)gemalto.com>;
*Subject:* Re: [keycloak-dev] Defining several Password Policies within a
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> 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.
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
> 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
> 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
> 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>
> > Hi Stian,
> > Thanks for your reply. I’m glad to see that you would welcome a PR on
> > 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
> > with their own configuration values. In addition to that, you propose
> > 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
> > would be applied to the “Groups”, meaning that a “Group” would now be
> > 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
> > of “Groups” the user is member of, and then select the Group’s
> > 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
> > to individual roles, and thus apply the same election of the “policy
> > used” thanks to the priority, taking into account not only the
> > policies groups” attached to the “Groups” the “User” is member of, but
> > the “Password policies groups” attached to the “Roles” the “User” is
> > granted to?
> > I like the fact that “Password policies groups” are attached to
> > instead of “Users”… but the priority mechanism looks to me a bit
> > understand for Realm administrators… and it becomes quite odd when
> > “Password policies groups” attached to “Roles”, don’t you think so?
> > Best regards,
> > Patrice
> > > > *From:* Stian Thorgersen [mailto:firstname.lastname@example.org]
> > *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
> > Realm
> > Hi,
> > This is a feature that have had a few requests for it so we would
> > a PR.
> > Assigning password policy groups to individual users is not the way to
> > 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
> > This would allow adding different matching conditions for a policy.
> > Initially it would be sufficient to match on a group of users, but it
> > be useful to also add support for a role as not everyone use groups at
> > ------------------------------
> > 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
> > the message if altered, changed or falsified. If you are not the
> > recipient of this message, please delete it and notify the sender.
> > Although all reasonable efforts have been made to keep this
> > free from viruses, the sender will not be liable for damages caused by
> > transmitted virus.
> keycloak-dev mailing list
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