correct the admin_or_target_domain rule
With the removal of KeystoneToken from the token model, we longer have the ability to use the token data syntax in the policy rules. This change broke backward compatibility for those is deploying customized Keystone policies. Unfortunately, we can't go back to KeystoneToken model as the change was tightly coupled with the other refactored authorization functionalities. Since the scope information is now available in the credential dictionary, we can just make use of it instead. Those who have custom policies must update their policy files accordingly. Change-Id: I83eae5c390d720da05e91264519ae01e8ca32159 closes-bug: 1810983
This commit is contained in:
parent
718f4a9c4c
commit
a2e307ed4d
|
@ -41,7 +41,7 @@
|
||||||
"identity:update_limit": "rule:admin_required",
|
"identity:update_limit": "rule:admin_required",
|
||||||
"identity:delete_limit": "rule:admin_required",
|
"identity:delete_limit": "rule:admin_required",
|
||||||
|
|
||||||
"identity:get_domain": "rule:cloud_admin or rule:admin_and_matching_domain_id or token.project.domain.id:%(target.domain.id)s",
|
"identity:get_domain": "rule:cloud_admin or rule:admin_and_matching_domain_id or project_domain_id:%(target.domain.id)s",
|
||||||
"identity:list_domains": "rule:cloud_admin",
|
"identity:list_domains": "rule:cloud_admin",
|
||||||
"identity:create_domain": "rule:cloud_admin",
|
"identity:create_domain": "rule:cloud_admin",
|
||||||
"identity:update_domain": "rule:cloud_admin",
|
"identity:update_domain": "rule:cloud_admin",
|
||||||
|
|
|
@ -20,7 +20,7 @@ RULE_ADMIN_OR_CREDENTIAL_OWNER = (
|
||||||
'(rule:owner and user_id:%(target.credential.user_id)s)')
|
'(rule:owner and user_id:%(target.credential.user_id)s)')
|
||||||
RULE_ADMIN_OR_TARGET_DOMAIN = (
|
RULE_ADMIN_OR_TARGET_DOMAIN = (
|
||||||
'rule:admin_required or '
|
'rule:admin_required or '
|
||||||
'token.project.domain.id:%(target.domain.id)s')
|
'project_domain_id:%(target.domain.id)s')
|
||||||
RULE_ADMIN_OR_TARGET_PROJECT = (
|
RULE_ADMIN_OR_TARGET_PROJECT = (
|
||||||
'rule:admin_required or '
|
'rule:admin_required or '
|
||||||
'project_id:%(target.project.id)s')
|
'project_id:%(target.project.id)s')
|
||||||
|
|
|
@ -1559,6 +1559,23 @@ class IdentityTestv3CloudPolicySample(test_v3.RestfulTestCase,
|
||||||
entity_url = '/domains/%s' % self.domainA['id']
|
entity_url = '/domains/%s' % self.domainA['id']
|
||||||
self.get(entity_url, auth=self.auth)
|
self.get(entity_url, auth=self.auth)
|
||||||
|
|
||||||
|
def test_project_admin_get_own_domain(self):
|
||||||
|
self.auth = self.build_authentication_request(
|
||||||
|
user_id=self.project_admin_user['id'],
|
||||||
|
password=self.project_admin_user['password'],
|
||||||
|
project_id=self.project['id'])
|
||||||
|
entity_url = '/domains/%s' % self.domainA['id']
|
||||||
|
self.get(entity_url, auth=self.auth)
|
||||||
|
|
||||||
|
def test_project_admin_get_other_domain_failed(self):
|
||||||
|
self.auth = self.build_authentication_request(
|
||||||
|
user_id=self.project_admin_user['id'],
|
||||||
|
password=self.project_admin_user['password'],
|
||||||
|
project_id=self.project['id'])
|
||||||
|
entity_url = '/domains/%s' % self.domainB['id']
|
||||||
|
self.get(entity_url, auth=self.auth,
|
||||||
|
expected_status=exception.ForbiddenAction.code)
|
||||||
|
|
||||||
def test_list_user_credentials(self):
|
def test_list_user_credentials(self):
|
||||||
credential_user = unit.new_credential_ref(self.just_a_user['id'])
|
credential_user = unit.new_credential_ref(self.just_a_user['id'])
|
||||||
PROVIDERS.credential_api.create_credential(
|
PROVIDERS.credential_api.create_credential(
|
||||||
|
|
|
@ -0,0 +1,14 @@
|
||||||
|
---
|
||||||
|
fixes:
|
||||||
|
- |
|
||||||
|
[`bug 1810983 <https://bugs.launchpad.net/keystone/+bug/1810983>`_]
|
||||||
|
With the removal of KeystoneToken from the token model, we longer
|
||||||
|
have the ability to use the token data syntax in the policy rules.
|
||||||
|
This change broke backward compatibility for anyone deploying
|
||||||
|
customized Keystone policies. Unfortunately, we can't go back
|
||||||
|
to KeystoneToken model as the change was tightly coupled with
|
||||||
|
the other refactored authorization functionalities.
|
||||||
|
|
||||||
|
Since the scope information is now available in the credential
|
||||||
|
dictionary, we can just make use of it instead. Those who have
|
||||||
|
custom policies must update their policy files accordingly.
|
Loading…
Reference in New Issue