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

[Stian Thorgersen]

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 at 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.
>
> 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 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.
> > >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>