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

Tue Feb 5 01:27:28 EST 2019

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
PasswordPolicyConditionProvider instance.

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 at gemalto.com>
wrote:

> Hi,
>
>
>
> 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 !
>
>
>
> Best regards,
>
> Patrice
>
>
>
> *From:* Stian Thorgersen [mailto:sthorger at redhat.com]
> *Sent:* lundi 21 janvier 2019 09:21
> *To:* Dmitry Telegin <dt at acutus.pro>
> *Cc:* AMIEL Patrice <Patrice.Amiel at gemalto.com>;
> keycloak-dev at lists.jboss.org
> *Subject:* Re: [keycloak-dev] Defining several Password Policies within a
> Realm
>
>
>
> 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
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&data=02%7C01%7CPatrice.Amiel%40gemalto.com%7C3ebd7fdb6e414b62c9b208d67f796a27%7C37d0a9db7c464096bfe31add5b495d6d%7C0%7C0%7C636836556799505604&sdata=E5IH7EaIOvUEckEd5KxXw1V5crFaUhK3msyYt8ZC3iw%3D&reserved=0>
>
> ------------------------------
> 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.
>