yahoo-eng-team team mailing list archive

[Lance Bragstad <lbragstad@xxxxxxxxx>]

Public bug reported:

Keystone implemented scope_types for oslo.policy RuleDefault objects in
the Queens release. In order to take full advantage of scope_types,
keystone is going to have to evolve policy enforcement checks in the
user API.

The trust API and trust entities require projects in order to be useful,
but allowing system users to list or manage trusts would be useful for
support personnel.

GET /v3/OS-TRUST/trusts or GET /v3/OS-TRUST/trusts/{trust_id}

For example, a system user should be able to list all trusts in the
deployment, while project users should only be able to access that API
for trusts they own.

POST /v3/OS-TRUST/trusts

Only project users should be able to call this API since trusts require
a project in order to be useful

DELETE /v3/OS-TRUST/trusts/{trust_id}

This API should be accessible to system administrators and users
attempting to delete their own trust. This work might also present us
with an opportunity to remove some of the logic in the trust API layer,
in favor of something that's more commonly used across keystone APIs
[0].

[0]
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/api/trusts.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc#n45

** Affects: keystone
     Importance: Low
         Status: Triaged


** Tags: policy system-scope

** Tags added: policy system-scope

** Changed in: keystone
       Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => Low

** Description changed:

  Keystone implemented scope_types for oslo.policy RuleDefault objects in
  the Queens release. In order to take full advantage of scope_types,
  keystone is going to have to evolve policy enforcement checks in the
  user API.
  
  The trust API and trust entities require projects in order to be useful,
  but allowing system users to list or manage trusts would be useful for
  support personnel.
  
  GET /v3/OS-TRUST/trusts or GET /v3/OS-TRUST/trusts/{trust_id}
  
  For example, a system user should be able to list all trusts in the
  deployment, while project users should only be able to access that API
  for trusts they own.
  
  POST /v3/OS-TRUST/trusts
  
  Only project users should be able to call this API since trusts require
  a project in order to be useful
  
  DELETE /v3/OS-TRUST/trusts/{trust_id}
  
  This API should be accessible to system administrators and users
- attempting to delete their own trust.
+ attempting to delete their own trust. This work might also present us
+ with an opportunity to remove some of the logic in the trust API layer,
+ in favor of something that's more commonly used across keystone APIs
+ [0].
+ 
+ [0]
+ http://git.openstack.org/cgit/openstack/keystone/tree/keystone/api/trusts.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc#n45

-- 
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/1818850

Title:
  The v3 trust API should account for different scopes

Status in OpenStack Identity (keystone):
  Triaged

Bug description:
  Keystone implemented scope_types for oslo.policy RuleDefault objects
  in the Queens release. In order to take full advantage of scope_types,
  keystone is going to have to evolve policy enforcement checks in the
  user API.

  The trust API and trust entities require projects in order to be
  useful, but allowing system users to list or manage trusts would be
  useful for support personnel.

  GET /v3/OS-TRUST/trusts or GET /v3/OS-TRUST/trusts/{trust_id}

  For example, a system user should be able to list all trusts in the
  deployment, while project users should only be able to access that API
  for trusts they own.

  POST /v3/OS-TRUST/trusts

  Only project users should be able to call this API since trusts
  require a project in order to be useful

  DELETE /v3/OS-TRUST/trusts/{trust_id}

  This API should be accessible to system administrators and users
  attempting to delete their own trust. This work might also present us
  with an opportunity to remove some of the logic in the trust API
  layer, in favor of something that's more commonly used across keystone
  APIs [0].

  [0]
  http://git.openstack.org/cgit/openstack/keystone/tree/keystone/api/trusts.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc#n45

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