Keystone both allows and prevents creation of third party app credentials

[Andrew Bogott]

When creating an app credential (e.g. via POST to /v3/users/{user_id}/application_credentials) the api takes a <user> arg to specify which user the cred is created for. That implies that in some cases user A might be creating a cred for user B. As it happens, I have such a use case[0].

The default keystone policy prevents this (via rule:owner) and only permits a user to alter their own creds. This is probably the right default policy, and weird deploys (like me) should be able to add an exception to that policy (e.g. admin_or_owner) as needed.

Adding a policy exception isn't possible, though, because in addition to the policy check there's an explicit check in the code:

        if self.oslo_context.user_id != user_id:
            action = _('Cannot create an application credential for another '
                       'user.')
            raise ks_exception.ForbiddenAction(action=action)

That explicit check shouldn't be there. The policy check is adequate to prevent what we want to prevent, and the explicit code check renders useless the <user> argument supported by the API.

So, either the <user> arg should be marked as deprecated, or the context check should be removed from the code. I prefer the latter, since it supports my weird use case.

[0] My weird use case: I'm mapping ldap service users from ldap into keystone. Because they're service users, no one will ever log in as those users directly so they don't have passwords. I nonetheless want those service users to do one or two select things, so I need to grant them credentials via a privileged account even though it's impossible to authenticate as the service user directly.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/keystone/+/918697