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

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

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
Changed in keystone:
assignee: nobody → Lance Bragstad (lbragstad)
status: Triaged → In Progress

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

commit d4a6023de5bdfe5a6e9214579a35e083a45c1151
Author: Lance Bragstad <email address hidden>
Date: Mon Sep 16 02:52:12 2019 +0000

    Remove policy.v3cloudsample.json

    We've make all the default policies keystone supports better by
    incorporating default roles and scope types. These changes have made
    the ``policy.v3cloudsample.json`` file obsolete.

    Let's simply things for users, operators, and develpers by removing
    it.

    A follow-on patch will remove the test_v3_protection.py file since
    those behaviors are passing all the protection tests with the default
    policies in code.

    Related-Bug: 1805880
    Closes-Bug: 1630434
    Closes-Bug: 1806762
    Change-Id: Ie45955f5cc54563cc9704d7cb2b656b5544ae030

Changed in keystone:
status: In Progress → Fix Released

Reviewed: https://review.opendev.org/687639
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=d9217f07b83399373c6e0879a71d943b73632ff5
Submitter: Zuul
Branch: stable/train

commit d9217f07b83399373c6e0879a71d943b73632ff5
Author: Lance Bragstad <email address hidden>
Date: Mon Sep 16 02:52:12 2019 +0000

    Remove policy.v3cloudsample.json

    We've make all the default policies keystone supports better by
    incorporating default roles and scope types. These changes have made
    the ``policy.v3cloudsample.json`` file obsolete.

    Let's simply things for users, operators, and develpers by removing
    it.

    A follow-on patch will remove the test_v3_protection.py file since
    those behaviors are passing all the protection tests with the default
    policies in code.

    Related-Bug: 1805880
    Closes-Bug: 1630434
    Closes-Bug: 1806762
    Change-Id: Ie45955f5cc54563cc9704d7cb2b656b5544ae030
    (cherry picked from commit d4a6023de5bdfe5a6e9214579a35e083a45c1151)

tags: added: in-stable-train

This issue was fixed in the openstack/keystone 16.0.0.0rc2 release candidate.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers