openstackclient is not authorized to lookup domains by name

[Adam Young]

Reported by Eduard Barrera in https://bugzilla.redhat.com/show_bug.cgi?id=1346886

Keystone is not properly looking up the domain_id, please check the highlighted log lines

# openstack project create --domain my_domain my_domain_project1

2016-06-15 04:52:06.795 9535 DEBUG keystone.middleware.core [-] Auth token not in the request header. Will not build auth context. process_request /usr/lib/python2.7/site-packages/keystone/middleware/core.py:223
2016-06-15 04:52:06.798 9535 INFO keystone.common.wsgi [-] POST http://192.168.101.196:5000/v3/auth/tokens

2016-06-15 04:52:06.897 9535 DEBUG keystone.middleware.core [-] Auth token not in the request header. Will not build auth context. process_request /usr/lib/python2.7/site-packages/keystone/middleware/core.py:223
2016-06-15 04:52:06.899 9535 INFO keystone.common.wsgi [-] POST http://192.168.101.196:5000/v3/auth/tokens
2016-06-15 04:52:06.978 14354 INFO keystone.common.wsgi [-] GET http://192.168.101.196:35357/
2016-06-15 04:52:06.986 14354 DEBUG keystone.middleware.core [-] RBAC: auth_context: {'is_delegated_auth': False, 'user_id': u'7f603b47d9a14ed2aa4f10d0182c2e3e', 'roles': [u'admin'], 'trustee_id': None, 'trustor_id': None, 'consumer_id': None, 'token': <KeystoneToken (audit_id=pz2LieBES-Wtv7Q9ftxI_g, audit_chain_id=pz2LieBES-Wtv7Q9ftxI_g) at 0x7f06181dc250>, 'access_token_id': None, 'domain_id': u'2e25369784564c508fdb51903ce98368', 'trust_id': None} process_request /usr/lib/python2.7/site-packages/keystone/middleware/core.py:233
2016-06-15 04:52:06.988 14354 INFO keystone.common.wsgi [-] GET http://192.168.101.196:35357/v3/domains/my_domain
2016-06-15 04:52:06.988 14354 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:get_domain(domain_id=my_domain) _build_policy_check_credentials /usr/lib/python2.7/site-packages/keystone/common/controller.py:61

<=======================

2016-06-15 04:52:06.989 14354 DEBUG keystone.common.controller [-] RBAC: using auth context from the request environment _build_policy_check_credentials /usr/lib/python2.7/site-packages/keystone/common/controller.py:66
2016-06-15 04:52:06.992 14354 WARNING keystone.common.wsgi [-] Could not find domain: my_domain
2016-06-15 04:52:07.000 14354 DEBUG keystone.middleware.core [-] RBAC: auth_context: {'is_delegated_auth': False, 'user_id': u'7f603b47d9a14ed2aa4f10d0182c2e3e', 'roles': [u'admin'], 'trustee_id': None, 'trustor_id': None, 'consumer_id': None, 'token': <KeystoneToken (audit_id=pz2LieBES-Wtv7Q9ftxI_g, audit_chain_id=pz2LieBES-Wtv7Q9ftxI_g) at 0x7f062f3e1020>, 'access_token_id': None, 'domain_id': u'2e25369784564c508fdb51903ce98368', 'trust_id': None} process_request /usr/lib/python2.7/site-packages/keystone/middleware/core.py:233
2016-06-15 04:52:07.002 14354 INFO keystone.common.wsgi [-] GET http://192.168.101.196:35357/v3/domains?name=my_domain
2016-06-15 04:52:07.002 14354 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:list_domains() _build_policy_check_credentials /usr/lib/python2.7/site-packages/keystone/common/controller.py:61
2016-06-15 04:52:07.002 14354 DEBUG keystone.common.controller [-] RBAC: using auth context from the request environment _build_policy_check_credentials /usr/lib/python2.7/site-packages/keystone/common/controller.py:66
2016-06-15 04:52:07.003 14354 DEBUG keystone.common.controller [-] RBAC: Adding query filter params (name=my_domain) wrapper /usr/lib/python2.7/site-packages/keystone/common/controller.py:193
2016-06-15 04:52:07.003 14354 DEBUG keystone.policy.backends.rules [-] enforce identity:list_domains: {'is_delegated_auth': False, 'user_id': u'7f603b47d9a14ed2aa4f10d0182c2e3e', 'roles': [u'admin'], 'trustee_id': None, 'trustor_id': None, 'consumer_id': None, 'token': <KeystoneToken (audit_id=pz2LieBES-Wtv7Q9ftxI_g, audit_chain_id=pz2LieBES-Wtv7Q9ftxI_g) at 0x7f062f3e1020>, 'access_token_id': None, 'domain_id': u'2e25369784564c508fdb51903ce98368', 'trust_id': None} enforce /usr/lib/python2.7/site-packages/keystone/policy/backends/rules.py:76
2016-06-15 04:52:07.005 14354 WARNING keystone.common.wsgi [-] You are not authorized to perform the requested action: identity:list_domains (Disable debug mode to suppress these details.)

<===========================

2016-06-15 04:52:07.017 14354 DEBUG keystone.middleware.core [-] RBAC: auth_context: {'is_delegated_auth': False, 'user_id': u'7f603b47d9a14ed2aa4f10d0182c2e3e', 'roles': [u'admin'], 'trustee_id': None, 'trustor_id': None, 'consumer_id': None, 'token': <KeystoneToken (audit_id=pz2LieBES-Wtv7Q9ftxI_g, audit_chain_id=pz2LieBES-Wtv7Q9ftxI_g) at 0x7f0618186bf0>, 'access_token_id': None, 'domain_id': u'2e25369784564c508fdb51903ce98368', 'trust_id': None} process_request /usr/lib/python2.7/site-packages/keystone/middleware/core.py:233
2016-06-15 04:52:07.021 14354 INFO keystone.common.wsgi [-] POST http://192.168.101.196:35357/v3/projects
2016-06-15 04:52:07.021 14354 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_project(project={u'enabled': True, u'domain_id': u'my_domain', u'name': u'my_domain_project1'}) _build_policy_check_credentials /usr/lib/python2.7/site-packages/keystone/common/controller.py:61
Version-Release number of selected component (if applicable):
<============================

Using the domain_id wotrkarounded the problem

# openstack project create --domain 2e25369784564c508fdb51903ce98368 my_domain_project1

How reproducible:

Steps to Reproduce:
1. create a project inside a domain
2.
3.

Actual results:
it fails

Expected results:
project created successfuly

Additional info:

# rpm -qa | egrep keystone
python-keystonemiddleware-1.5.1-1.el7ost.noarch
openstack-keystone-2015.1.2-2.el7ost.noarch
python-keystoneclient-1.3.0-2.el7ost.noarch
python-keystone-2015.1.2-2.el7ost.noarch

[Steve Martinelli (stevemar)]

Changing this to OSC.

Was this done with non-admin credentials? The way OSC tries to find things by name or ID is by:

1) GET /domains/my_domain
if that fails...
2) GET /domains&name=my_domain
if that fails...
3) GET /domains and parse the result for an entry that has my_domain

... or something like that.

The trouble is non-admin often don't have the authorization in the default policy to look up any entry.

[Jamie Lennox (jamielennox)]

So yea, I've seen this before at least on bugzilla and we never had a great way to deal with it.

Steve's correct, if you use domain name then OSC must try to resolve that domain name into a domain_id to perform the operation and the way it does that is by doing a list operation. Listing domains is a very privileged operation for obvious reasons.

I think this is really a policy problem we should fix. Because domain names are also unique you should be able to find your domain by name in this way without exposing other domains. I would need to think about what priviledges you would need to be able to view a domain's details like this but i assumes it's the same as GET /domains/<id>

[venkatamahesh (venkatamaheshkotha)]

Hi,

Just now I have reproduced the same and didn't encounter any problem. The CLI worked correctly. Is you are getting problem again ?

Thanks
mahesh

[Dolph Mathews (dolph)]

For anyone (else) a bit confused by this bug report - this is primarily a user experience issue with the default policy. I've changed the bug title to better reflect the actual issue.

[Matthew Edmonds (edmondsw)]

we addressed a similar issue by changing OSC to avoid a list operation when it could map the name to an id based on the information in the auth token. A project-scoped token's data includes both the name and id of the project's parent domain, and a domain-scoped token's data includes both the name and id of that domain. If that name is my_domain, to match this example, then you can pull the corresponding id from the token data and don't need to make a list domains call. You would still need to make a list domains call if you are not currently authenticated to a project in my_domain (or to my_domain directly), but in most cases that's probably not an issue.

See https://review.openstack.org/#/c/311206/

[Steve Martinelli (stevemar)]

See https://review.openstack.org/#/c/311206/

[Matthew Edmonds (edmondsw)]

Steve, I think this may be a little different from the fix that was already released, which you and I both referenced. I think that fix may have only addressed show operations, whereas this defect is about create operations.