Deletion of a role leads to deletion of role assignments and entries in
the application credentials. However, deletion of the entries in
application credentials depends on the existence of the assignment, so
the order of deletion is important.
Delete the entries from application credentials first and then clean up
role assignment.
Closes-Bug: 2053137
Change-Id: Ibba9063c729961cd4155f8b55dbabd4789d7a438
Validating an application credential token is very slow, taking at least
400ms+ in a simple devstack environment, 5-10x longer than validating a
user/password project token.
The primary bottleneck during a token validation request
(/v3/auth/tokens) is that token.roles is evaluated at least 5 times.
validate_token is called twice, first during RBAC to populate the
subject token context and again to actually validate the token. Each
call to validate_token then called token.roles twice because it first
checks if it is None, before calling it again to use the result. Lastly
token.roles is evaluated a fifth time during
render_token_response_from_model.
Each evaluation of token.roles calls through
_get_application_credential_roles into list_role_assignments which then
makes multiple round-trip SQL queries to the database.
Unlike the related get_roles_for_user_and_project function, none of
these calls are currently cached/memoized. We memoize
list_role_assignments to get the same-speedup.
Reduce the number of token.roles calls to only 3 by storing and re-using
the token.roles result in validate_token, then memoize
list_role_assignments so the 2nd and 3rd call fetch from the cache
instead of repeating many SQL queries.
This provides a substantial performance improvement bringing validation
time in-line with user/password tokens.
Change-Id: I8c45131b298ceae7b43b42e2c5df167607d18c48
These practices cause conflicts periodically. Not right now:
the gate is okay with the current values, which this patch
deletes. However, like sun raising in the east it is sure
to happen again. This patch lets workarounds work that the
infra team puts in place. The downside is, we need to fix
the code once in a while as new checks get added.
Change-Id: Ia7a96fb4b6de4251862a8a96c995cefa94dbc271
Resolve the following LegacyAPIWarning warning:
The Query.get() method is considered legacy as of the 1.x series of
SQLAlchemy and becomes a legacy construct in 2.0. The method is now
available as Session.get()
Change-Id: I30d0bccaddff6a1d91fcd5660f490f904e7c8965
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This patch ensures to delete the system role assignments from
all the assignment tables in keystone after deleting the role
user has over the system.
This also make sure of deleting stale role assignments before
deleting role for the deployments that are already in this state.
Closes-Bug: #1878938
Change-Id: I4df19c45c870ff3fb78578ca1fb7dd0d35da3c82
When you setup a user with a role assignment on a domain
and then a role assignment on a project "acting as a domain",
you can't actually remove them. The database throws you the
error "Multiple rows were found for one()" since it gets two
results for "actor_id" with the same "target_id".
This patch fixes this problem by filtering the database query
by "type" field to determine whether it is a user domain relation
or a user project and then removing the assignment.
Change-Id: Ife92a3c9e0982baafb4224882681c0855f573580
Closes-Bug: #1754677
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
This is to fix the duplicated words issue like
"one for each each user_id in the provided group_id".
Change-Id: Iacb8e713253288d203834355f1de12482c2c029e
Without this patch, if there are multiple role assignments on the system
and they are not all the same role, querying for role assignments with
/v3/role_assignments?role.id={role_id} may leak some role assignments
that don't match the role_id, making the returned results incorrect.
This patch fixes the issue by using a list comprehension instead of a
for loop over a list that was being modified within the loop.
Change-Id: Icfce3b14abb55c6fef3de1b314cee22fc8b1d08c
Closes-bug: #1858012
Add in support for immutable roles and projects (including domains).
If the immutable option is set for a role or a project that
resource may not:
* Be Deleted
* Be Updated, except to change the value of "immutable" from
`True` to `False` or `None` (None explicitly unsets the
resource option).
* For projects (and domains), project tags cannot be created,
updated, or deleted.
The immutable check is performed at the manager layer allowing
for exceptional code-cases to work directly with the driver.
Change-Id: I2027b1235a260b7ae5d66cbd6c369773d9e99876
Partial-bug: #1823258
Add in support for resource options for roles and projects (including
domains). No options are currently implemented for roles or projects.
Scaffolding has been implemented so that adding options should be
straight forward. This will allow for implementing options such
as an immutable flag.
As a mechanism to isolate SQL Models from the Driver implementation
especially when adding in complexity of the resource options, the
models for the Resource backend and the Role Backend (SQL) have been
move to their own module.
Partial-Bug: #1807751
Depends-On: https://review.opendev.org/678379
Required-By: https://review.opendev.org/678380
Change-Id: I456a7c19506d28d5846534f884b8abe0d3079c96
This reverts commit ebac8330d8.
Using the glob that I had not yet had enough coffee to do correctly is a
better solution, and allows us to fix new failures in 1.6.0 which would
break us again when 1.6.1 was released.
Change-Id: Ica473ba71b224cdc0acf815f82d534b6c70a7f54
While Cycles could be a problem, this code was detercting them even
when there were none. If a role gets added twice, it was reporting
an error, but that is possible from the case where two distinct prior
add the same implied role. Just move on quietly.
closes-bug 1803780
Change-Id: I804e5084f74ff4afdd582ece02ff2c833c5f6eb1
In the token model, the trust roles are not cached. This behavior
impacts services that are using trusts heavily like heat or magnum.
It introduces new cache data to improve the performance on token
validation requests on trusts.
Change-Id: I974907b427c34fd5db3228b6139d93bbcdc38df5
Closes-Bug: #1796887
Convert the projects API to Flask native dispatching.
Change-Id: I3406284acfb7950b701f6a98a3a173a427415f97
Co-Authored-By: Morgan Fainberg <morgan.fainberg@gmail.com>
Partial-Bug: #1776504
Convert /v3/users to use flask native dispatching.
The following test changes were required:
* Application Credentials did not have the plural form
in the JSON Home document. The JSON Home document was
corrected both in code and in tests.
* Application Credentials "patch" test needed to be
refactored to look for METHOD_NOT_ALLOWED instead
of NOT FOUND for invalid/unimplemented methods.
The "assertValidErrorResponse" method was
insufficient and the test now uses the flask
test_client mechanism instead.
Change-Id: Iedaf405d11450b11e2d1fcdfae45ccb8eeb6f255
Partial-Bug: #1776504
Convert OS-INHERIT API to flask native dispatching.
NOTE: A minor test change was needed, the test was mis-constructing the
URI with multiple slashes. The test now properly constructs the URI
using an lstrip when combining the direct_url bits.
Change-Id: I0907eb00cdfb9849342220f9b528f94175e71545
Partial-Bug: #1776504
Now user can add the description to the role when user creates the role.
Added support for a ``description`` attribute for V3 Identity Roles.
Co-Authored-By: wangxiyuan<wangxiyuan@huawei.com>
Co-Authored-By: Deepak Mourya<deepakmoriya7@gmail.com>
Change-Id: I230af9cc833af13064636b5d9a7ce6334c3f6e9a
Closes-Bug: #1669080
Convert the /system API (used for granting roles to the system scope) to
Flask native dispatching.
Change-Id: I48b04f2d0e9d858b0c709687beee27227e516843
Partial-Bug: #1776504
Convert Roles and Implied Roles (all paths under /v3/roles) to
flask native dispatching. This change does not convert
/v3/role_inferences to flask native dispatching.
Change-Id: I114380e96c6a2b3c167676fa1525e4470560b541
Partial-Bug: #1776504
Basic conversion of Keystone's core application to flask framework.
This doesn't add much in the way of flask-specific-isms but should
get keystone running directly under flask. This implementation does
not use paste-deploy.
Change-Id: Ib4c1ed3f645dd55fbfb76395263ecdaf605caae7
If a group gets deleted out-of-band in an LDAP environment, the role
assignments cannot be cleaned as it checks the existence of the group
before triggering the deletion. This fix adds the ability to ignore
non-existant group and clean up stale role assignments. We take the
same approach with user assignments.
Co-Authored-By: Lance Bragstad <lbragstad@gmail.com>
Change-Id: I975c8325f50b412c3aa256e1940a27082c009cce
Closes-Bug: #1751045
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
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
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
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
The only API we're supporting on the v2.0 path until the T release is
the ec2tokens API. This commit removes all routers from the public
and admin v2.0 applications. This includes the extensions API. This
commit also removes unused v2.0 controller logic.
Change-Id: I523c1215899ac9ee605df6bf717643c0ba87c761
Closes-Bug: 1746798
This commit exposes the necessary bits to expose system-scoped
token authenticate and validation via the API
bp system-scope
Change-Id: I572a8e48953f493d521fd2aa00007df46e562e2e
This commit makes it so users can query the /role_assignments API
with ?scope.system=all.
bp system-scope
Change-Id: I1476c8da8ace1d60a832dfc3197c147e92f63837
This decorator is only useful when upgrade Keystone form Liberty
to higher release. I don't think any deployments will upgrade
from Liberty to Queens directly. And Liberty is eol already. So
it's safe engouth to remove it.
Change-Id: I891b0d3e87e8c011a2db758fc84dbd4590f78c96
This commit wires up the remaining bits to expose system role
assignments for groups via the assignment API.
bp system-scope
Change-Id: I5051aa97dbecb88ee706749b26a4140f9798e084
This commit wires up the remaining bits to expose system role
assignments via the assignment API.
bp system-scope
Change-Id: Ie17a473c12c9a67bbc5b26f18d8b29e8ad4529d2