Public bug reported: # OS_USERNAME=user OS_USER_DOMAIN_NAME=admin_domain OS_PROJECT_NAME=admin # OS_PROJECT_DOMAIN_NAME=admin_domain openstack user list --domain testdomain -> users returned for testdomain
# OS_USERNAME=user OS_USER_DOMAIN_NAME=testdomain OS_DOMAIN_NAME=testdomain + policy file modification openstack user list --domain 49a912df2669410faecc6e0ab5d8dc80 -> users returned for testdomain openstack user list --domain testdomain -> no users returned for testdomain The same is valid for projects and roles. Role assignments have slightly different policy rules in a sample file. Environment: OpenStack Pike (UCA) + a slightly modified https://github.com/openstack/keystone/blob/stable/pike/etc/policy.v3cloudsample.json file: https://paste.ubuntu.com/p/Zk7S7d7qm2/ "admin_and_matching_domain_id": "rule:admin_required and (domain_id:%(domain_id)s or domain_name:%(domain_id)s)", domain_name:%(domain_id)s - this was added to allow usage of --domain <domain-name>, not just ID as documented, e.g. here https://docs.openstack.org/python-openstackclient/pike/cli/command- objects/user.html#cmdoption-user-create-domain ("--domain <domain> Default domain (name or ID)") https://paste.ubuntu.com/p/D35vMMbdTm/ - the first part of this is a demonstration that a policy file is not enough to use --domain <domain- name> without policy file modification in a non-admin project, the second part is a demonstration of the problem after policy file modification. The domain_name is taken from auth_context and matched against domain_id API call argument as described here https://docs.openstack.org/keystone/pike/admin/identity-service-api- protection.html Debug mode traces for 3 different scenarios: https://paste.ubuntu.com/p/8ntVt69tYy/ I can see that the whole Admin scoping and policy enforcement implementation is being reworked [0][1][2][3] and UUID tokens were deprecated in Pike so "domain_name" usage from auth context is not a reliable thing to do [4]. If my understanding is correct, please duplicate or "won't fix" this and let this be a reference for others to look at. Usage of --domain argument with a domain name instead of a domain_id is a bit inconsistent in how it's documented in OSC docs because it seems to only work for the admin user with admin project scoped tokens (provided that sample policy files are used). [0] pad.lv/1750673 [1] https://review.openstack.org/#/c/526203/ [2] https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/role-check-from-middleware.html [3] pad.lv/968696 [4] https://review.openstack.org/#/c/525325/ ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1759120 Title: Objects are not returned if domain name is used instead of domain id Status in OpenStack Identity (keystone): New Bug description: # OS_USERNAME=user OS_USER_DOMAIN_NAME=admin_domain OS_PROJECT_NAME=admin # OS_PROJECT_DOMAIN_NAME=admin_domain openstack user list --domain testdomain -> users returned for testdomain # OS_USERNAME=user OS_USER_DOMAIN_NAME=testdomain OS_DOMAIN_NAME=testdomain + policy file modification openstack user list --domain 49a912df2669410faecc6e0ab5d8dc80 -> users returned for testdomain openstack user list --domain testdomain -> no users returned for testdomain The same is valid for projects and roles. Role assignments have slightly different policy rules in a sample file. Environment: OpenStack Pike (UCA) + a slightly modified https://github.com/openstack/keystone/blob/stable/pike/etc/policy.v3cloudsample.json file: https://paste.ubuntu.com/p/Zk7S7d7qm2/ "admin_and_matching_domain_id": "rule:admin_required and (domain_id:%(domain_id)s or domain_name:%(domain_id)s)", domain_name:%(domain_id)s - this was added to allow usage of --domain <domain-name>, not just ID as documented, e.g. here https://docs.openstack.org/python-openstackclient/pike/cli/command- objects/user.html#cmdoption-user-create-domain ("--domain <domain> Default domain (name or ID)") https://paste.ubuntu.com/p/D35vMMbdTm/ - the first part of this is a demonstration that a policy file is not enough to use --domain <domain-name> without policy file modification in a non-admin project, the second part is a demonstration of the problem after policy file modification. The domain_name is taken from auth_context and matched against domain_id API call argument as described here https://docs.openstack.org/keystone/pike/admin/identity-service-api- protection.html Debug mode traces for 3 different scenarios: https://paste.ubuntu.com/p/8ntVt69tYy/ I can see that the whole Admin scoping and policy enforcement implementation is being reworked [0][1][2][3] and UUID tokens were deprecated in Pike so "domain_name" usage from auth context is not a reliable thing to do [4]. If my understanding is correct, please duplicate or "won't fix" this and let this be a reference for others to look at. Usage of --domain argument with a domain name instead of a domain_id is a bit inconsistent in how it's documented in OSC docs because it seems to only work for the admin user with admin project scoped tokens (provided that sample policy files are used). [0] pad.lv/1750673 [1] https://review.openstack.org/#/c/526203/ [2] https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/role-check-from-middleware.html [3] pad.lv/968696 [4] https://review.openstack.org/#/c/525325/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1759120/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
