Currently, the majority of access control enforcement for the trusts API
is not done in policy, but hardcoded in the controller logic. The
default policy check strings for these routes are empty. Before we can
enable system scope and default roles through the trusts policy, we need
to replicate the existing access control in policy. To do that, we
should test how it currently works. This patch adds those tests.
The trusts API is mostly only useable by the trustor or trustee. Mostly,
admins can't perform trust actions on behalf of the trustor or trustee.
The exception is for the delete action, but only when the is_admin
context is set. This change also fixes a minor regression where the
is_admin admin could not perform this action due to the auth_context not
being populated.
Reviewed: https:/ /review. opendev. org/675720 /git.openstack. org/cgit/ openstack/ keystone/ commit/ ?id=5086709ae2d 673716653cd8812 247ea5a1cb5e69
Committed: https:/
Submitter: Zuul
Branch: master
commit 5086709ae2d6737 16653cd8812247e a5a1cb5e69
Author: Colleen Murphy <email address hidden>
Date: Fri Aug 9 21:37:23 2019 -0700
Add protection tests for trusts API
Currently, the majority of access control enforcement for the trusts API
is not done in policy, but hardcoded in the controller logic. The
default policy check strings for these routes are empty. Before we can
enable system scope and default roles through the trusts policy, we need
to replicate the existing access control in policy. To do that, we
should test how it currently works. This patch adds those tests.
The trusts API is mostly only useable by the trustor or trustee. Mostly,
admins can't perform trust actions on behalf of the trustor or trustee.
The exception is for the delete action, but only when the is_admin
context is set. This change also fixes a minor regression where the
is_admin admin could not perform this action due to the auth_context not
being populated.
Change-Id: I6a5eca8240aa90 5e02fbf9bec3359 96c3a4f1c79
Partial-bug: #1818846
Partial-bug: #1818850