policy.v3cloudsample.json doesn't allow domain admin list role assignments on project

Bug #1630434 reported by John Lin on 2016-10-05
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)

Bug Description

My OpenStack version is Mitaka.

With an admin domain-scoped token, a domain admin cannot list role assignments on the project in the domain. The error messages are:

    "error": {
        "code": 403,
        "message": "You are not authorized to perform the requested action: identity:list_role_assignments",
        "title": "Forbidden"

I am currently using a workaround: adding include_subtree=true to use "identity:list_role_assignments_for_tree".

Lance Bragstad (lbragstad) wrote :

It looks like the list role assignments call is protected by the following rule [0]:

  "rule:cloud_admin or rule:admin_on_domain_filter or rule:admin_on_project_filter"

Even the admin_on_domain_filter rule requires the user to have the admin role. Can you verify the domain admin actually has the admin role specified?

[0] https://github.com/openstack/keystone/blob/856bd73826d36731c611b6479d204816cde0b2e9/etc/policy.v3cloudsample.json#L123

Lance Bragstad (lbragstad) wrote :

I should clarify, by specified I mean assigned to the domain being worked on. Thanks!

tags: added: policy
tags: added: configuration
John Lin (johnlinp) wrote :

Yes, I believe that the domain admin actually has the admin role on the domain.

The admin_on_domain_filter rule only works when scope.domain.id is given. However, what I wanted to query is the assignments on the project (by specifying scope.project.id).

guoshan (guoshan) on 2016-12-06
Changed in keystone:
assignee: nobody → guoshan (guoshan)
Lance Bragstad (lbragstad) wrote :

I don't think our policy engine is currently capable of handling nested scope checks like this. This use case is certainly something we need to strive for as we separate role checks from scope checks in the future. The scope check in Kristi's example would consist of checking that the project in the request 9836e076391549c2915c15ae6b51d12c actually belongs in the domain of the scoped token. The lack of this behavior is consistent across other service as well.

Changed in keystone:
status: New → Triaged
importance: Undecided → Medium
guoshan (guoshan) on 2017-07-31
Changed in keystone:
assignee: guoshan (guoshan) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers