Ability to block users from changing passwords is missing in Keystone v3

[Pavlo Shchelokovskyy]

While fixing bug 1641645 the solution was to 'unprotect' the v3/users/{id}/password endpoint.

However some deployments that were using Keystone v2 and are migrating to v3 use ability to block users from changing their passwords (via edited policy in policy.json), and are now left w/o any possibility to have the same behavior.

[Lance Bragstad (lbragstad)]

Thanks for the bug report. Why would you ever want to prevent a user from updating their password?

[Vlastimil Mikes (v-mikes-z)]

the use case is as following:

“There is a customer which grants access to OpenStack via centralized authentication services. They employ so called ‘service users’ for authentication of automated toolchains only. These are Keystone user entries that are being created and destroyed on request by user action in a fully automated service portal.

These generated credentials adhere to company policy in regard to anonymity (username is random, can’t be connected to single person), traceability and isolation (generated for a single tenant inside OpenStack), and, for the lack of a better term, breakability (password strength by generating random 24 characters out of [a-zA-Z0-9], should never be changed without adhering to this password policy, better no end-user may change it, they can always re-create users).

Though the Horizon dashboard now is able to effectively block password change requests or can be configured, so that a password policy is enforced, the Identity API V3 employed by Keystone does have no means to effectively block password changes for non-admin users.”

[Adam Young (ayoung)]

Change the policy for the API call. Its a user modification. This is not done via config file change.

[Pavlo Shchelokovskyy (pshchelo)]

Adam, there is no more policy for that endpoint - see bug 1641645. Currently in V3 the password change does not require a token (AFAIU was done to deal with expiring passwords so that admins won't be nagged by password reset requests), thus RBAC protection is not applied.

[Pavlo Shchelokovskyy (pshchelo)]

patch has been proposed here https://review.openstack.org/#/c/552988/

[Lance Bragstad (lbragstad)]

Thanks for the use case. Does this centralized authentication service mainly enforce password strength requirements? Does it do other things that keystone can't do today? I ask because it sounds somewhat related to PCI, and keystone has some support for that built in.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/559438

[OpenStack Infra (hudson-openstack)]

Change abandoned by Pavlo Shchelokovskyy (<email address hidden>) on branch: master
Review: https://review.openstack.org/552988
Reason: superseded by https://review.openstack.org/#/c/559438

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/559438
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=f17fa57f6ccb3a578507ee494d6d6d9e3680e5e3
Submitter: Zuul
Branch: master

commit f17fa57f6ccb3a578507ee494d6d6d9e3680e5e3
Author: Morgan Fainberg <email address hidden>
Date: Fri Apr 6 15:15:35 2018 -0700

    Allow blocking users from self-service password change

    User option ``lock_password`` has been implemented. This
    option when set to ``True`` will prevent the usage of the
    self-service password change API. If the ``lock_password``
    option is set to ``False`` or ``None`` (to remove the
    option from the user-data structure) normal password
    change operations are allowed

    Closes-Bug: #1755874
    Change-Id: Icf1776c5fe625c2e9292bfcf40a8a9f17a002656

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone 14.0.0.0b2 development milestone.