GET /v3/users and /v3/groups lists entries in all domains

[Adam Young]

The behaviour of this API is different if CONF.identity.domain_specific_drivers_enabled is set or not. If it is not set, then listing user shows for all domains. If it is set, even for SQL, only a single domain is listed.

The correct behavior would be to only list users for the domain extracted from the users tokens, regardless of the value set here. Otherwise, data leaks across domains.

[Adam Young (ayoung)]

$ http http://localhost:5000/v3/users X-Auth-Token:8ae436b60ca047af8745af85551a3d72
HTTP/1.1 200 OK
Content-Length: 4137
Content-Type: application/json
Date: Wed, 13 Aug 2014 22:58:08 GMT
Server: Apache/2.4.10 (Fedora) mod_wsgi/3.5 Python/2.7.5
Vary: X-Auth-Token

{
"links": {
"next": null,
"previous": null,
"self": "http://10.0.1.62:5000/v3/users"
},
"users": [
{
"default_project_id": "84caa4bfe589426db2117f2c29ad54c6",
"domain_id": "default",
"email": "<email address hidden>",
"enabled": true,
"id": "159db39c66ac4b83abfd42b57290c137",
"links": {
"self": "http://10.0.1.62:5000/v3/users/159db39c66ac4b83abfd42b57290c137"
},
"name": "swiftusertest1"
},
{
"default_project_id": "84caa4bfe589426db2117f2c29ad54c6",
"domain_id": "default",
"email": "<email address hidden>",
"enabled": true,
"id": "68d32890819c4dc78e9e8d81b7899f39",
"links": {
"self": "http://10.0.1.62:5000/v3/users/68d32890819c4dc78e9e8d81b7899f39"
},
"name": "swiftusertest3"
},
{
"description": "Manages users and projects created by heat",
"domain_id": "39bb82cc58e04c888e782a308d6eb20f",
"enabled": true,
"id": "7a590a6df2f34cfba168fcb0ab9be40b",
"links": {
"self": "http://10.0.1.62:5000/v3/users/7a590a6df2f34cfba168fcb0ab9be40b"
},
"name": "heat_domain_admin"
},
{
"default_project_id": "324d1ec2fe9f44f591d013b592479dd0",
"domain_id": "default",
"email": null,
"enabled": true,
"id": "7b39d6834aca4f1a9b7861a2ef712be4",
"links": {
"self": "http://10.0.1.62:5000/v3/users/7b39d6834aca4f1a9b7861a2ef712be4"
},
"name": "swift"
},
{
"default_project_id": "324d1ec2fe9f44f591d013b592479dd0",
"domain_id": "default",
"email": "<email address hidden>",
"enabled": true,
"id": "7b6cfc976e3b4e5dbc179cd6b6cf331b",
"links": {
"self": "http://10.0.1.62:5000/v3/users/7b6cfc976e3b4e5dbc179cd6b6cf331b"
},
"name": "glance-swift"
},
{
"default_project_id": "53f8037d955749e8ad134c1055f5022c",
"domain_id": "default",
"email": null,
"enabled": true,
"id": "7f691c2dc67b403988b21b7c9b1af70a",
"links": {
"self": "http://10.0.1.62:5000/v3/users/7f691c2dc67b403988b21b7c9b1af70a"
},
"name": "admin"
},
{
"default_project_id": "324d1ec2fe9f44f591d013b592479dd0",
"domain_id": "default",
"email": null,
"enabled": true,
"id": "83d5d384b29d49aea9ad15cb404a466c",
"links": {
"self": "http://10.0.1.62:5000/v3/users/83d5d384b29d49aea9ad15cb404a466c"
},
"name": "heat"
},
{
"default_project_id": "7fee0cba826f4fe293e638f8f3bf2982",
"domain_id": "default",
"email": "<email address hidden>",
"enabled": true,
"id": "9603a6806d6a4405bc1e6e0d93de3970",
"links": {
"self": "http://10.0.1.62:5000/v3/users/9603a6806d6a4405bc1e6e0d93de3970"
},
"name": "swiftusertest2"
},
{
"default_project_id": "ca0752255dc4450e977e753b221a8e91",
"domain_id": "default",
"email": "<email address hidden>",
"enabled": true,
"id": "9a28cbebbe4245f29ffaaa1873b8e29d",
"links": {
"self": "http://10.0.1.62:5000/v3/users/9a28cbebbe4245f29ffaaa1873b8e29d"
},
"name": "alt_demo"
},
{
"default_project_id": "0a37a6c21d3e40718e74f92a8ff94307",
"domain_id": "default",
"email": "<email address hidden>",
"enabled": true,
"id": "9e8fda6c9add452aa459be1adc9d15c6",
"links": {
"self": "http://10.0.1.62:5000/v3/users/9e8fda6c9add452aa459be1adc9d15c6"
},
"name": "demo"
},
{
"default_project_id": "3...

[Henry Nash (henry-nash)]

So the situation you describe is by design (which we could decide to change, of course). The rationale is that if, in the case of only using SQL with multiple domains, you want to prevent such leakage, then setting the appropriate rules in the policy file will prevent the leakage of user data across domains. The example policy.v3cloudsample.json shows how to do this - it basically requires (unless you are cloud admin) that you specify a domain filter on the query - and will return "Not Authorized" if you do not.

I guess my comments over the proposal here would be:

1) We'd have to do this for users, groups and projects - make it consistent
2) We'd have to still allow, I think, some "admin way" of bypassing this, if that's what the cloud provider wanted.
3) If we do go to a project hierarchy, where domains are just (effectively) an attribute of a given project node where you can attach users, would the idea of restricting this API via its domain token scope still be implementable (I think, actually, the answer is yes)

[Dolph Mathews (dolph)]

This is certainly expected behavior - Henry's explanation looks spot on, and (2) explains the justification for the current behavior.

[Adam Young (ayoung)]

The design then does not line up with how people originally were justifying the use of Domains. Domains need to be secured from each other by default. Since cloudpolicy is not the default file, we have a hole.

Admin can always request for a specific domain. In addition, we could provide "all_domains" as a filter that would explicitly bypass the restriction for an authenticated user, but Ithink that is probably a mistake: listing all users in a a large system is likeyl to cause memory exhaustion.