v3/users or groups calls not working without domain_id

Bug #1431015 reported by Matthew Edmonds on 2015-03-11
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Undecided
lilly

Bug Description

The keystone.common.controller._get_domain_id_for_list_request comment says the below:
        """Get the domain_id for a v3 list call.

        If we running with multiple domain drivers, then the caller must
        specify a domain_id either as a filter or as part of the token scope.

        """

But keystone instead of pulling the domain information from the token scope (the "or" in that statement), keystone fails with an HTTP 401 if you don't explicitly indicate the domain with the domain_id query parameter, as shown with the following commands:

[root@mysystem ~]# curl -k -i -X GET https://127.0.0.1:5000/v3/groups -H "Accept: application/json" -H "X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7"
HTTP/1.1 401 Unauthorized
content-length: 114
vary: X-Auth-Token
server: Apache/2.4.6 (Red Hat) OpenSSL/1.0.1e-fips mod_wsgi/3.4 Python/2.7.5
date: Wed, 11 Mar 2015 20:50:31 GMT
content-type: application/json
www-authenticate: Keystone uri="https://ip9-114-226-167.pok.stglabs.ibm.com:5000"

{"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Unauthorized"}}

[root@mysystem ~]# curl -k -X GET https://127.0.0.1:5000/v3/auth/tokens -H "Accept: application/json" -H "X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7" -H "X-Subject-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7" | python -mjson.tool
{
    "token": {
...
        "project": {
            "domain": {
                "id": "default",
                "name": "Default"
            },
            "id": "0e2df62a46044405bb63be16ab9e2177",
            "name": "ibm-default"
        },
...
        "user": {
            "domain": {
                "id": "default",
                "name": "Default"
            },
            "id": "0688b01e6439ca32d698d20789d52169126fb41fb1a4ddafcebb97d854e836c9",
            "name": "root"
        }
    }
}

[root@mysystem ~]# curl -k -i -X GET https://127.0.0.1:5000/v3/groups?domain_id=default -H "Accept: application/json" -H "X-Auth-Token: 7f9254f016784efdb3b1e6fa8bc5e4f7"
HTTP/1.1 200 OK
...

Henry Nash (henry-nash) wrote :

You need to be using a domain scoped token for the keystone to pick up the domain from the token...it looks like the token you are using is an unscoped token

Changed in keystone:
status: New → Invalid
Matthew Edmonds (edmondsw) wrote :

This was not an unscoped token. Requested as follows:

curl -k -i -X POST https://127.0.0.1:5000/v3/auth/tokens -H "Accept: application/json" -H "Content-Type: application/json" -d '{"auth": {"scope": {"project": {"name": "ibm-default", "domain": {"name": "Default"}}}, "identity": {"methods": ["password"], "password": {"user": {"domain": {"name": "Default"}, "name": "root", "password": "passw0rd"}}}}}'

Changed in keystone:
status: Invalid → New
description: updated

The method _get_domain_id_for_list_request retrieves the domain_id in the case domain specific backends are being used.

In the described case, there are two reasons that may raise a 401 Unauthorized:

i) the policy rules for "identity:list_users": "rule:admin_required" or "identity:list_groups": "rule:admin_required" (depending on the request) is not being satisfied, i.e, the provided user has not the admin role on the specified project or domain;
ii) the provided token is not domain scoped.

If the user "root" is assigned the "admin" role on the project "ibm-default", the described request should not fail for the reason i).

However, the provided request shows a project scoped token, which will fail since 'domain' is not in 'scope' (but 'project' is) [1].

---

In Keystone v3, if domain specific backends are not being used, we allow users and groups to be listed independently on the tokens being scoped to a project or a domain.

We should allow the same (for tokens v3) when domain specific backends are enabled.
In the case of project scoped token, the domain_id could be obtained by calling the project_domain_id property, from KeystoneToken.

[1] https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L656-L661

Changed in keystone:
assignee: nobody → lilly (lilly-spandanabarukula)
Dolph Mathews (dolph) wrote :

The assertion being made by OP is that the domain which owns the scoped project should become the domain upon which the action is performed, but I would consider that behavior to be a privilege escalation vulnerability. The user is presenting explicit domain-level authorization on a domain-level resource, and would thus be circumventing the intended policy.json behavior.

Changed in keystone:
status: New → Invalid
Dolph Mathews (dolph) wrote :

Whoops: s/The user is presenting/The user is NOT presenting/

Henry Nash (henry-nash) wrote :

I agree with Dolphm - the design is that either you need a domain-scoped token or you need to explicitly provide a domain as a parameter.....both of which will, of course, be checked against policy

Matthew Edmonds (edmondsw) wrote :

I think henry and dolph have both agreed on IRC that it would not be a security vulnerability to address this, but we're still hung up on whether it's intuitive. I'm gonna stop pushing.

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

Other bug subscribers