yahoo-eng-team team mailing list archive

[Andrew Bogott <2065212@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: keystone
     Importance: Undecided
         Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/2065212

Title:
  Keystone both allows and prevents creation of third party app
  credentials

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/2065212/+subscriptions