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

Mon Feb 4 03:49:25 EST 2019

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