Comment 2 for bug 1437407

Brad Pokorny (bpokorny) wrote :

Priti and I have also tried fixing this with policy file modifications. Here's what we've got currently in the v3 policy file for keystone:

    "admin_on_domain_filter" : "rule:cloud_admin or (rule:admin_required and domain_id:%(scope.domain.id)s)",
    "admin_on_project_filter" : "rule:cloud_admin or (rule:admin_required and (project_id:%(scope.project.id)s or domain_id:%(target.project.domain_id)s))",
    "identity:list_role_assignments": "rule:admin_on_domain_filter or rule:admin_on_project_filter",

But that hasn't allowed us to get further. To rule out any possible limitations in the keystone client, I tried running directly to the API, but got the same error (TOKEN in the below command is a domain scoped token retrieved by an admin of the domain the project is under):

$ curl -sX GET https://keystonehost:443/v3/role_assignments?scope.project.id=63901d683ce04c248f5f2786db05a0b1 -H "X-Auth-Token: $TOKEN" | jq .
{
  "error": {
    "title": "Forbidden",
    "code": 403,
    "message": "You are not authorized to perform the requested action: identity:list_role_assignments (Disable debug mode to suppress these details.)"
  }
}

So I'm not sure at this point whether we've missed something in the policy file or if there's a limitation in the keystone code that doesn't allow this via the API.