Resolve the following RemovedIn20Warning warning:
"ApplicationCredentialRoleModel" object is being merged into a Session
along the backref cascade path for relationship
"ApplicationCredentialModel.roles"; in SQLAlchemy 2.0, this reverse
cascade will not take place. Set cascade_backrefs to False in either
the relationship() or backref() function for the 2.0 behavior; or to
set globally for the whole Session, set the future=True flag
This also applies for "ApplicationCredentialAccessRuleModel" and
"AccessRuleModel.application_credential".
Change-Id: I277cb4d512ca6b4e4aca5aad60a97a78cdb961e3
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The repo is Python 3 now, so update hacking to version 3.0 which
supports Python 3.
Fix problems found.
Update local hacking checks for new flake8.
Change-Id: Ic440219814ee0c2b98217e9a821f38f5baf482ec
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
This change creates a /v3/users/{user_id}/access_rules endpoint to allow
users to view and delete their own access rules. Access rules are not
automatically deleted when an application credential is deleted, so they
can be re-used for other application credentials or explicitly deleted
by the user. Access rules are automatically deleted when the user is
deleted, the same way that application credentials are. Access rules
that are in use by an application credential may not be deleted.
bp whitelist-extension-for-app-creds
Change-Id: I37d243d802cd538189ccfffee6ebf0624b7785d3
Without this patch, when an individual application credential is deleted
it emits a notification, but when all are deleted for a user there is no
notification (although this is only triggered when a user is deleted or
disabled or has a change in role assignments, all of which generate
their own notifications). This patch ensures audit notifications are
generated for every application credential that gets deleted.
Change-Id: I7c820931585802c7afa53727623ac05adee56248
Access rules that a user creates via an application credential will be
preserved independently of the application credential, and can be
queried on a per-user basis and re-used with new application
credentials. This change adds the user_id and external_id columns and
indices to allow that.
bp whitelist-extension-for-app-creds
Change-Id: I8a516fc19be25350593ef915a94f029c65db8de2
This reverts commit 37fc2b9120.
In the Train PTG[1] we agreed to defer the access rules config part of
this feature until we had some kind of traceability or discoverability
for APIs. For simplicity of review, this patch reverts the access rules
addition to the app cred manager so that we can reimplement it in a way
that doesn't require using the access_rules_config API provider.
[1] https://etherpad.openstack.org/p/keystone-train-ptg-application-credentials
Change-Id: I65ac52b8730221562391adc8b0dbccd22ea79b16
This uses the access_rules manager to validate access rules against
configured access rules.
bp whitelist-extension-for-app-creds
Change-Id: I075ab8472cbe93db1c2327c2e82211ff71e9ef72
Invalidate the application credential after deletion, not before.
This prevents timing issues where an app_cred could remain active
after deletion.
Change-Id: I14748bf2399e5da4ee360f451a8050f25dd90803
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 the /auth paths to flask native dispatching.
A minor change to additional_urls was implemented to ensure all
urls are added at once instead of individually (causing an over-
write issue within flask as a single resource may only have a
single set of URL mappings).
Alternate URLs now support adding alternate JSON Home rel links.
This is to support the case of OS-FEDERATION auth routes moving
to /auth. The old JSON Home entries must exist but reference
the new paths.
This port includes the following test changes (needed due to the
way flask handles requests and the way requests are passed through
the auth system):
* Implemented keystone.common.render_token (module)
containing render_token_response_from_model and use it instead
of keystone.common.controller.render_token_response_from_model.
Minor differences occur in render_token_response_from_model in
the keystone.common.render_token module, this is simply
for referencing data from flask instead of the request object.
* Test cases have been modified to no longer rely on the auth
controller(s) directly
* Test cases now use "make_request" as a context manager
since authenticate/authenticate_for_token directly
reference the flask contexts and must have an explicit
context pushed.
* Test cases no longer pass request objects into methods
such as authenticate/authenticate_for_token or similar
methods on the auth plugins
* Test cases for federation reference the token model now
where possible instead of the rendered token response.
Rendered token responses are generated where needed.
* Auth Plugin Configuration is done in test core as well.
This is because Auth controller does not exist.
NOTE: This is a massive change, but must of these changes
were now easily uncoupled because of how far reaching auth
is.
Change-Id: I636928102875760726cc3493775a2be48e774fd7
Partial-Bug: #1776504
We check if user has specified roles in project when creating
application credential. The code can be optimized here instead
of two level loop.
Change-Id: I9de223b693d33a45331af9ffd2960f733c6b43da
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
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
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 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
When delete application credentials for a user/project, the
realted cache information should be invalidated as well.
Closes-Bug: #1747332
Change-Id: I431bf1921a636cce00a807f9d639628da8664c24
The cache invalidation doesn't work for application credential.
This patch fixed it.
Change-Id: I730df6f4abe1ec63d93e999535de7afad05e76a7
Closes-bug: #1746868
This patch updated some base functions' input parameters
and documentation in application credential backend to
keep the same with the usage. So that the customer could
write their own backend easliy.
Change-Id: I5d090d3ab72ab1f31bf3c3edcb8f4429085829ed
In order to protect against possible abuse or bloat, add a config option
to set a limit on the number of application credentials a user may have.
bp application-credentials
Change-Id: Ieab33c3265fa0c0b1b1c6d586e5ea8a9a39edfb1
Add an auth plugin for application credentials and update the common
auth utilities to understand an auth method of 'application_credential'
and validate and scope accordingly.
By default, application credentials should not be allowed to be used for
creating other application credentials or trusts. If a user creates an
application credential with flag `allow_application_credential_creation`
then that application should be allowed to be used for creating and
deleting other application credentials and trusts. Ensure a flag is set
in the token if this property is set to allow this behavior.
bp application-credentials
Change-Id: I15a03e79128a11314d06751b94343f22d533243a
Add the controller, router, schema, and policies for application
credentials. If a secret is not provided, one is generated at the
controller layer.
bp application-credentials
Depends-on: Id26a2790acae25f80bd28a8cb121c80cb5064645
Depends-on: Icbd58464182b082854fb5d73ccc93c900ede020c
Change-Id: I7a371d59c19a11e55f17baf12d92327c1258533d
In the application credential spec[1] we decided to add on a parameter
that would control whether an application credential could be used to
create other application credentials. This parameter is also used to
control whether it can be used to delete other application credentials
and whether it can create and delete trusts. Therefore the name
`allow_application_credential_creation` is misleading. Moreover, giving
a property of the resource a name that is an imperative verb is not
great. It makes more sense for a property to be a noun, an adjective, or
a passive verb.
This change renames the `allow_application_credential_creation`` column
to ``unrestricted``. This maintains the same boolean context, i.e. a
"true" value for the old name maintains the same meaning as a "true"
value for the new name.
At this point, the application credential API has not yet been exposed,
so there should be no data in this table and no need for complicated
migration triggers. In general, we only need to do a column alter to
rename it. Sqlite is special because it does not support column alters,
so in order to accomodate our tests the migration involves copying the
whole table, minus the old column, and recreating it with the new
column.
Change-Id: Id26a2790acae25f80bd28a8cb121c80cb5064645
While the application credential logic was going through review we
noticed the project_id column of the table was not nullable. It is
possible for this to hinder the ability to create system-level
application credentials in the future.
For now, let's create a system column for application credentials
and alter the table so that project_ids can be nullable. This will
make it easier to expand application credential usage in the future.
bp application-credentials
Change-Id: I4e1104f95cc3c7567ee8f6edfe8515d45d154a9f
Add the manager layer for application credentials. This handles
generating CADF notifications on create/delete and listening for
notifications that affect application credentials' lifetime. On create,
the manager keeps a copy of the initial secret so that it may be
returned to the user, but it is otherwise never stored. The secret hash
is stored and must be filtered out before being returned to the user.
bp application-credentials
Change-Id: Iae6377e78d2b8e15472d378ef54e29a946dc51b5
Add a sql model and driver for application credential CRUD operations
and authentication.
bp application-credentials
Change-Id: I192052434c0b0d49d1612824aec1034507dfd233
Christian Rohmann