v3/users or groups calls not working without domain_id

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

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"}}}}}'

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

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.

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

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

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.