This repo does not support Python 2 anymore, so we don't need
six for compatibility between Python2 and 3, convert six usage to Python
3 code.
Change-Id: Icba56808f38277b27af2ae5aac4b8507dee71b3b
In 09088690 we mistakenly added E501 to the flake8 ignore list. Since
then, many new violations have been introduced. This patch re-enables
the check and corrects all violations, except in some cases like unit
test names where the subunit output would suffer if we attempted to
shorten the function name.
This may appear to be a pointless no-op that messes with
git-blameability, and it is, but the reason to do this is that if PEP8
violations are introduced in master and then backported to a stable
branch, most stable branches will fail the pep8 job since the flake8
ignore list is correct for those branches. Rather than loosening the
check in older branches or requiring those backports to fix the linter
errors independently of what's been merged in master, we should fix it
now so that we don't introduce more errors in the future and patches can
more easily be backported.
Change-Id: I9f71926105eb448bb0200201d1838b67d4963cd6
Without this change, policy enforcement for the GET
/OS-TRUST/trusts/{trust_id}/roles/{role_id} API is hardcoded in the
flask dispatcher code. This is a problem because this enforcement can't
be controlled by the operator, as is the norm. Moreover, it makes the
transition to system-scope and default-roles-aware policies more
difficult because there's no sensible migration from "" to a logical
role-based check string.
This converts the hardcoded enforcement to enforcement via default
policies for GET /OS-TRUST/trusts/{trust_id}/roles/{role_id}. The API
specifically blocks the is_admin user from using it, and since policies
aren't loaded for the is_admin user we need to continue explicitly
blocking it.
This change does not use the formal oslo.policy deprecation system
because "" OR'd with the new default is entirely useless as a policy.
Change-Id: Ib5a6a87313aa7b2a73211f512b8a8c675a21b52f
Partial-bug: #1818850
Partial-bug: #1818846
Without this change, policy enforcement for the GET
/OS-TRUST/trusts/{trust_id}/roles API is hardcoded in the flask
dispatcher code. This is a problem because this enforcement can't be
controlled by the operator, as is the norm. Moreover, it makes the
transition to system-scope and default-roles-aware policies more
difficult because there's no sensible migration from "" to a logical
role-based check string.
This converts the hardcoded enforcement to enforcement via default
policies for GET /OS-TRUST/trusts/{trust_id}/roles. The API specifically
blocks the is_admin user from using it, and since policies aren't loaded
for the is_admin user we need to continue explicitly blocking it.
This change does not use the formal oslo.policy deprecation system
because "" OR'd with the new default is entirely useless as a policy.
Change-Id: Ib339852c9d619b8cbf7a00d45da461377991ba6f
Partial-bug: #1818850
Partial-bug: #1818846
Without this change, policy enforcement for the GET
/OS-TRUST/trusts/{trust_id} API is hardcoded in the flask dispatcher
code. This is a problem because this enforcement can't be controlled by
the operator, as is the norm. Moreover, it makes the transition to
system-scope and default-roles-aware policies more difficult because
there's no sensible migration from "" to a logical role-based check
string.
This converts the hardcoded enforcement to enforcement via default
policies for GET /OS-TRUST/trusts/{trust_id}. The API specifically
blocks the is_admin user from using it, and since policies aren't loaded
for the is_admin user we need to continue explicitly blocking it.
This change does not use the formal oslo.policy deprecation system
because "" OR'd with the new default is entirely useless as a policy.
Change-Id: I3c0718330d5a18c0c79e8f12509200fd97a55913
Partial-bug: #1818850
Partial-bug: #1818846
Without this change, policy enforcement for the DELETE
/OS-TRUST/trusts/{trust_id} API is hardcoded in the flask dispatcher
code. This is a problem because this enforcement can't be controlled by
the operator, as is the norm. Moreover, it makes the transition to
system-scope and default-roles-aware policies more difficult because
there's no sensible migration from "" to a logical role-based check
string.
This converts the hardcoded enforcement to enforcement via default
policies for DELETE /OS-TRUST/trusts/{trust_id}. Currently only the
trustor or the is_admin user can access this API (since the is_admin
user bypasses the policy loading). This behavior will be changed in a
future patch that will allow the system admin to access this API.
This change does not use the formal oslo.policy deprecation system
because "" OR'd with the new default is entirely useless as a policy.
Change-Id: I1aaba72b69b389ffbfcf7d5b8cc70453ffa59e73
Partial-bug: #1818850
Partial-bug: #1818846
Without this change, policy enforcement for the GET /OS-TRUST/trusts API
is hardcoded in the flask dispatcher code. This is a problem because
this enforcement can't be controlled by the operator, as is the norm.
Moreover, it makes the transition to system-scope and
default-roles-aware policies more difficult because there's no sensible
migration from "" to a logical role-based check string.
This patch starts the conversion from hardcoded enforcement to
enforcement via default policies for GET /OS-TRUST/trusts. To do this,
we add two new policy rules, "identity:list_trusts_for_trustor" and
"identity:list_trusts_for_trustee". We need to do this so that we can
keep backwards compatibility with the bizarre behavior that an admin can
list all trusts (GET /OS-TRUST/trusts) but not list trusts for a trustor
or trustee (GET /OS-TRUST/trusts?trustor_user_id={} and
GET/OS-TRUST/trusts?trustee_user_id={}). The tricky part is that it's
plausible that operators may have incorporated the hardcoded empty
default for "identity:list_trusts" into their on-disk policy
configuration, either by never removing the old default policy file that
used to come packaged with keystone, or by generating a sample file and
applying that to disk (we don't recommend that but we don't expressly
forbid or discourage it either). To overcome
this, the trust API code checks whether the "identity:list_trusts" rule
is "" and re-applies the enforcement with a warning. We don't need to do
this for the two new policies because they are initially enforced
in-code and an operator would have to take explicit action on upgrade to
override them.
This change does not use the formal oslo.policy deprecation system
because "" OR'd with the new default is entirely useless as a policy.
Partial-bug: #1818850
Partial-bug: #1818846
Change-Id: I6c1a4ecd756519f7f807c9d28960482e7f0d235b
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: I6a5eca8240aa905e02fbf9bec335996c3a4f1c79
Partial-bug: #1818846
Partial-bug: #1818850
Forbidden exception does not take any format parameter, so
use ForbiddenAction instead in api/trusts.py
Change-Id: I6869f26240fdf040bf236133fe97b1e4987090f7
Since the credential API and trust API were one of the first APIs
converted to flask, there weren't using a utility method to parse
JSON out of request bodies.
This commit makes both APIs re-use common code to get request
bodies.
Change-Id: Ic67fb1bc45018cdc6c3598adbc43cfc57f8592ab
Move the json_home "extension" rel functiond to a common location
so that they may be shared as needed between apis. Since there
are no new extensions for keystone, once keystone is moved to being
100% flask dispatched, no new relation functions will need to be
added to keystone.api._shared.json_home_relations.
Change-Id: I7040526acccee63183559b5b817b3e33990ab508
Partial-Bug: #1776504
Allowing targeting of the types for wrap_member and wrap_collection.
This prevents the need to cross-call controllers such as wrapping role
refs fro the trust api.
Change-Id: Id8658cf6fba2fb765ec0f9b2265367741470f50e
Partial-Bug: #1776504
This change mirrors what was done prior to flask and leans on the
base_url and full_url functions to append '/v3' and the path or
collection_name. This will allow for changes to wrap_member and
wrap_collection to properly handle local-only wrapping (no need
to cross-api call wrap because a "role" is returned from the "trust"
api).
Change-Id: I5376d8abc581994f28da64f3b578a04b00e68c4d
Partial-Bug: #1776504
This commit removes the original KeystoneToken object in favor of the
new TokenModel object. Since we have a token provider that knows how
to deal with TokenModel object, we don't really need another object
that uses reflection at all.
Closes-Bug: 1778945
Change-Id: I778cab0a6449184ecf7d5ccfbfa12791be139236
Vishakha Agarwal