This API has been in keystone for a long time and we never updated it
to stable, yet we treat it like a stable API. This change updates the
JSON home document to reflect that. This is also consistent with
discussions during the Rocky PTG:
https://etherpad.openstack.org/p/keystone-rocky-ptg-json-home
Change-Id: I0b5aef233d9e51799595802d0812015866727987
This change makes tags a property of Project instead of a hybrid_property
since we will always have a Project contain some list of tags.
Change-Id: I1033321132cb3ec71bf94b8293cef91dfc6b8272
Co-Authored-By: Morgan Fainberg <morgan.fainberg@gmail.com>
Closes-Bug: #1752301
The fernet token unit tests had a bunch of config_fixture overrides to
populate the fernet max_active_keys configuration option with its
default value. Since it is just setting these to the default, it's
not necessary to provide overrides when it's already established in
keystone.tests.unit.core.TestCase.
Change-Id: Id09459104d9b5ec412ec60211ef71b7c7c62b14f
This assertion was a bit misleading in that it seemed to validate
one key at a time. But the implementation of the assertion actually
assumes it is given a list of string values. This commit fixes the
name of the assertion to be more clear and it also makes the
assertion iterate all values given, which ensures each key in the
list is valid, not just the first one.
Change-Id: Ifc9542e4e7f57f54d473183c97f616f92cb0961b
This should have been done before the queens release. I noticed it
when looking at the API reference and only seeing application
credentials listed under 3.10 information.
Change-Id: I6f2d9551d15061dbe99e9228c097e735910a41db
In queens the v2.0 APIs were removed. This commit removes the
leftover v2.0 policies documented in the sample policy file.
Change-Id: Ibb841bcbc12d0be365ddb2681310a0eee6724782
Without this patch, the token formatter does not have enough data to
construct a token created with an application credential. This means
that if the token cache is disabled or expired, when keystone goes to
create the token it will not find any application credential information
and will not recreate the application_credential_restricted parameter in
the token data. This patch creates a new Payload class for application
credentials so that the application credential ID is properly persisted
in the msgpack'd payload. It also adds more data to the token data
object so that the application credential ID and name as well as its
restricted status is available when the token is queried.
Co-authored-by: Lance Bragstad <lbragstad@gmail.com>
Change-Id: I322a40404d8287748fe8c3a8d6dc1256d935d84a
Closes-bug: #1750415
The token provider listened for specific callbacks from the
federation and oauth APIs. These were mainly for token invalidation
and token persistence removal. Now that the sql token driver and uuid
token provider have been removed, we can remove the need for
persistence notifications.
Instead, both of these cases can use a generic token cache
invalidation callback. This makes the token provider Manager simpler
because it only has to listen for a single internal notification to
invalidate the token cache, instead of multiple. It also makes the
code sending the notification easier to understand because it's
clearer about what it's doing.
Change-Id: I3281a013ce2764872dda8c183c4e9851974e1d14
The INVALIDATE_USER_TOKEN_PERSISTENCE and
INVALIDATE_USER_PROJECT_TOKEN_PERSISTENCE callbacks were meant to
clean up invalid tokens from the token storage layer. Now that the
sql token driver has been removed, we don't need them any more. This
commit removes those notifications and refactors the places where
notifications are still needed, making them more specific and not
eluding to token persistence.
This commit also removes a significant amount of logic from the
assignment API that used to notify the token API when assignments
were deleted. This made sense when tokens were written to disk
because there was an opportunity to invalidate them when users were
removed from projects. This is no longer needed since we do
validation online and we don't persist tokens anymore.
Change-Id: I100b7416e8ba61eb4ea2c2eb4962e952a53ea388
There are several cases where we need to invalidate the token cache.
Notifications are used to do this and the token provider API uses
callbacks to subscribe to those notifications. This commit makes them
all use a single callback function instead of each defining their own
just to do the same thing. A subsequent patch will refactor the term
"persistence" from the notification names used across keystone.
Change-Id: I5e78f8aafec74e3edb952ab92947503c9be38b91
Since the sql token storage mechanism was removed in Rocky, we no
longer need hooks in the token Manager to determine if a token needs
to be retrieved from or written to a backend somewhere. Instead, token
providers will need to handle storage requirements if they need them.
This will result in a cleaner token provider interface.
Change-Id: Icc095987d41e9c08de2f34dc657b08b98bd944e4
Add documentation in the User section on managing, using, and rotating
application credentials.
Since application credential support didn't make it into
python-openstackclient in the Queens release, show examples using
python-keystoneclient.
Change-Id: I24bc51d2f3741771ba321fc05d49fd111aa76c15
This will help with testing since SQLite will start enforcing the
foreign key relationships.
We will still have a problem with migrations for tables that refer to
each other. SQLite can't alter tables and sqlalchemy-migrates tmp table
strategy for migrations fails in this situation.
This patch did:
1. Add FK support for the tests. Disable it by default.
2. Make sure the Fk is disabled for test_sql_upgrade and
identity.backens.test_sql
Partial-Bug: #1744195
Co-Authored-By: wangxiyuan<wangxiyuan@huawei.com>
Change-Id: I276af7c0125dc2cb2c54215d54491665db1caa22
These two were just chillin' as token provider class variables. They
are not used anywhere and we use special notification strings defined
in notification.py for good reason. Keeping things defined in one
place makes maintenance easier. Remove the unused variabels from the
token provider.
Change-Id: I98f29114daa01df94f12813143da9097c294b43a
Now that we have system scope in place, we should make sure at least
one user has a role assignment on the system. We can do this at the
same time we grant the user a role on a project during bootstrap.
This is backwards compatible because even if a deployment doesn't use
system-scope, the assignment will just sit there. The deployment will
have to opt into enforcing scope by updating configuration options
for oslo.policy to enforce scoping.
This shouldn't prevent deployments from fixing bug 968696 and using
system scope.
Closes-Bug: 1749268
Change-Id: I6b7196a28867d9a699716c8fef2609d608a5b2a2
This commit removes system role assignments when querying keystone
for a list of assignments pertaining to a specific role. For example,
`GET /v3/role_assignments?role.id={role_id}`, now returns assignments
only for that role. Previously, the list contained false positives
because some system role assignments weren't being removed. This
was introduced in queens with the system scope work.
Change-Id: Iab35ae01bb715da5813e62cd09900de555dceaaa
Closes-Bug: 1748970
Keystone removes role assignments that groups have on projects and
domains when deleting groups. This should apply to system role
assignments, too.
Change-Id: Iebedfcae0b77e350e5359b97fa87894af3f1c8ba
Closes-Bug: 1749267
Project and domain role assignment are cleaned up when deleting
groups. This commit introduces a test case that shows this isn't the
case for system role assignments. A subsequent patch will implement
a fix to make sure system role assignments are removed when groups
are deleted, to be consistent with project and domain assignments.
Change-Id: I9b452aff144fd8867cdac2f44cbcaa0d1de63a12
Partial-Bug: 1749267
Keystone removes role assignments that users have on projects and
domains when deleting users. This should also apply to system role
assignments, too.
Change-Id: Ied51b9c3b58714b2d5dbcb933eca1839d1351fc7
Closes-Bug: 1749264
Project and domain role assignment are cleaned up when deleting
users. This commit introduces a test case that shows this isn't the
case for system role assignments. A subsequent patch will implement
a fix to make sure system role assignments are removed when users
are deleted, to be consistent with project and domain assignments.
Change-Id: I1a1e7395f462159037e939aa143e9e24aefb1841
Partial-Bug: 1749264
The role_assignment API supports a bunch of query parameters that
gives users flexibility when querying for role assignments. This
commit exposes an issue when querying keystone for a specific role
using /role_assignments?role.id={role_id}. The expected result was
that the returned list would only contain role assignments for that
specific role ID. The actual result is a set of role assignments with
that role ID and all system role assignments.
This caused issues in tempest because tempest goes through and cleans
up resources using `tearDownClass`, and it is common to remove
specific roles used in the test class. The problem is that keystone
queries the role assignment API for all role assignment with a
specific role ID, which is the equivalent to
`GET /v3/role_assignments?role.id={role_id}` when deleting a role. The
list returned included false positives, which were system role
assignments, resulting in revocation events getting persisted for
users in those role assignments. This prevented the administrator in
tempest from cleaning up the rest of the resources because the
revocation event would make the token being used to do resource
cleanup.
This commit exposes the bug using tests.
Change-Id: If93400be3c9d3fe8e266bb36c16accca93d77154
Partial-Bug: 1748970
