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

[Stian Thorgersen]

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.

On Tue, 8 Jan 2019 at 09:37, AMIEL Patrice <Patrice.Amiel at gemalto.com>
wrote:

> Hi all,
>
> We are currently working on adding the capability to define several
> Password Policies for a given realm.
> The rationale is that in our systems, within a given realm, we have
> different "types" of accounts that have different constraints on password
> management. For instance:
>
> -          Administrators shall have long and complex passwords, with a
> very short password expiration time
>
> -          Regular users have a "normal" :P password strength, and medium
> expiration time
>
> -          Accounts for technical/automated access to the system shall
> never expire and have very long passwords
> All these Users shall be part of the same Realm.
> Obviously, these 3 types are only an example and there might be a need of
> more types or less types of accounts for other deployments => the number of
> Password Policies is not fixed in advance.
>
> We would definitely like to push the work as a PR, but before doing that,
> we'd like to be sure that we are going on the good tracks so that this PR
> could be accepted.
> The idea is consequently, from Web UI perspectives:
>
> -          To update the Password Policy pane so that we have first a list
> of what we could call "Password Policy Groups". Within this pane, an
> initial list would allow to list, create and edit the Password Policy
> Groups.
>
> -          When creating or editing one of the available Password Policy
> Groups, a sub pane would allow to select the individual Password Policies
> to be added to the Group.
>
> -          Then, on Users management section, a new drop-down field of the
> User edition page would enable to select the Password Policy Group to be
> applied to this specific User
>
> -          The Password Policy Group page might remain under the
> Authentication menu area... but it might also be eligible to be moved to a
> dedicated area similar to the current "Group" area (indeed, we would then
> have a "Roles Groups" area (this is indeed what the current "Group" area
> is) and a "Password Policy Groups" area...)
>
> Note that it would maybe be more convenient to attach a Password Policy
> Group to a "Group" rather than to an individual User, but as Users may
> belong to several Groups, then it would generate conflicts when applying
> the individual Password Policies if they are conflicting (for example, one
> saying that the min password length is 10 characters while the other saying
> it is 15).
>
> Impacts are:
>
> -          On the DB model and JPA classes to support a list of Password
> Policies (i.e. Password Policy Groups),
>
> -          On the User classes to support attachment of a User to a
> Password Policy Group
>
> -          On the GUI, as described above
>
> -          On the authentication process, to select the right Password
> Policy
>
> -          On the change password process, to select the right Password
> Policy
>
> -          On the REST API
>
> Does this proposal make sense to you (any concern or recommendation) ?
>
> Thanks for your feedbacks
>
> Best regards,
> Patrice
>
>
> ________________________________
> 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
>