This patch modifies a few policies to allow users with the "admin" role
to access /v3/auth/tokens and /v3/credentials. These policies were
missed when we implemented Phase 1 of Secure RBAC.
Change-Id: Id789c09121f1405f7ba5e4926498dab4ad98e057
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
When calling the s3tokens or ec2tokens API with a
HTTP GET we should get a 405 Method Not Allowed but
we get a 500 Internal Server Error because we enforce
that method.
Closes-Bug: #2052916
Change-Id: I5f60d10dc25551175cc73ca8f3f28b0b95ec9f99
Signed-off-by: Tobias Urdin <tobias.urdin@binero.se>
Introduces domain-scoped filtering of the response list of the
list_domains endpoint when the user is authenticated in domain scope
instead of returning all domains. This aligns the implementation with
other endpoints like list_projects or list_groups and allows for a
domain-scoped reader role.
Changes the default policy rule for identity:list_domains to
incorporate this new behavior for the reader role.
Closes-Bug: 2041611
Change-Id: I8ee50efc3b4850060cce840fc904bae17f1503a9
This patch updates system-scoped policies to also accept project-admin
tokens so that operators can continue to use the "admin" role to access
system level APIs.
The protection test job is marked non-voting since tempest does not yet
expect these policy changes. A follow-up patch will make it voting
again after the test changes have merged into tempest.
[1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-1
Change-Id: I31b5a1f85d994a90578657bc77fa46ace0748582
We propose to extend Keystone identity provider (IdP) attribute mapping
schema to make Keystone honor the `domain` configuration that we have
on it.
Currently, that configuration is only used to define a default domain
for groups (and then each group there, could override it). It is
interesting to expand this configuration (as long as it is in the root
of the attribute mapping) to be also applied for users and projects.
Moreover, to facilitate the development and extension concerning
attribute mappings for IdPs, we changed the way the attribute mapping
schema is handled. We introduce a new configuration
`federation_attribute_mapping_schema_version`, which defaults to "1.0".
This attribute mapping schema version will then be used to control the
validation of attribute mapping, and also the rule processors used to
process the attributes that come from the IdP. So far, with this PR,
we introduce the attribute mapping schema "2.0", which enables
operators to also define a domain for the projects they want to assign
users. If no domain is defined either in the project or in the global
domain definition for the attribute mapping, we take the IdP domain
as the default.
Change-Id: Ia9583a254336fad7b302430a38b538c84338d13d
Implements: https://bugs.launchpad.net/keystone/+bug/1887515
Closes-Bug: #1887515
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
The eventlet server implementation was removed during Newton, and have
not been used by any other implementations for a while.
Change-Id: I01f9adfc3e610d820c1834209d36c10568cccf41
Python 3.11 job now run on Debian Bookwarm which does not provide
some of the packages in bindep. This fixes the bindep file so that
it pulls packages actually available.
This also updates a few assertions of log records in unit tests to make
these robust for any warning logs.
Change-Id: Iae3f4da24418530b61b9a0b64390160d194da05b
A situation might arise, when the user does not exist any more and we
are attempting to set last_active_at on them. This results in keystone
raising AttributeError.
Check for user existense before addressing the attribute
Closes-Bug: 2044624
Change-Id: I3eb5890fb6d52a222b7caa4a52effc06774c0542
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
This patch adds new hashing alhorythm bcrypt_sha256, which is based on
the bcrypt but does not have limitations on the leght of the passwords,
since passwords are passed through HMAC-SHA2-256 first.
At accepts exactly same parameters as bcrypt does.
However, it prefix the hash using `prefix` attribute rather then
`indent_values` which are same as for bcrypt.
Change-Id: I5430ebf5a20142c1a9caab960ced9b3ee2e782c1
bcrypt hashing algorythm has a limitation on length of passwords it
can hash on 72 bytes. In [1] a password trimm to 54 symbols has been
implemented, which resulted in password being invalidated after the
keystone upgrade, since passwords are trimmed differently by bcrypt
itself, as well as len(str()) is not always equal to
len(str().encode()) as trimming should be done based on bytes and not
string itself.
With the change we return a byte object from
`verify_length_and_trunc_password`, so it does not need to
be encoded afterwards, since we need to strip based on bytes
rather then on length of the string.
[1] https://review.opendev.org/c/openstack/keystone/+/828595
Closes-Bug: #2028809
Related-Bug: #1901891
Change-Id: Iea95a3c2df041a0046647b3d3dadead1a6d054d1
We shouldn't specify a server default for a configurable option since it
means our initial database schema is not consistently reproducible.
Instead, we should specify the default at runtime. It turns out we
already do this and the server default was overkill. We can remove it.
Change-Id: I74e47a9ed986c7c3af19676ac65f4d290bcb4cc0
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
A primary key is automatically unique, therefore if one or columns is
included in a primary key constraint there is no need to add a separate
unique constraint for these columns. Remove it.
Note that this only affects MySQL. Both SQLite and PostgreSQL appear to
ignore the duplicate unique constraint. As a result, it was necessary to
run auto-generation against MySQL instead of the default SQLite. The
actual command used was similar to what we normally do, however.
$ python keystone/common/sql/migrations/manage.py revision \
--autogenerate --message 'Remove duplicate constraints'
As always, the resulting schema migrations then needed some manual
tweaks to remove "please adjust!" comments and unnecessary imports but
they are correct.
Change-Id: I64252086f994901a5ebe05afec37a6afd3a192ee
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The fix is to copy the missing check from class AuthProtocol
of keystonemiddleware.
Closes-bug: 1999068
Change-Id: I4fd7bf6b194c38815c2a9cdbab92a07315397eab
This is our first test of the autogeneration tooling integrated in
change I17c9ff9508c5e2bd9521c18973af093d7550ab5a. To generate this, we
simply removed all but one of the "skipped" constraints defined in the
'env.py' file and then ran the following command within a virtualenv:
$ python keystone/common/sql/migrations/manage.py revision \
--autogenerate --message 'Fix incorrect constraints'
The resulting schema migrations then needed some manual tweaks to remove
"please adjust!" comments (don't worry, the commands were correct).
Change-Id: Ie1be3df78189f4165079a43d0a9050fcece6989b
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The OAuth2.0 Access Token API is modified, support to get an OAuth2.0
certificate-bound access token from the keystone identity server with
OAuth 2.0 credentials and Mutual-TLS certificates.
Co-Authored-By: Hiromu Asahina <hiromu.asahina.az@hco.ntt.co.jp>
Change-Id: I885527bec61429b1437a046097a16491848b5a0a
Implements: blueprint support-oauth2-mtls
Two issues here. The most pressing is that we are banning use of the
'batch_alter_table' operation. There's no reason to do this as it isn't
an operation per se, but rather a way of modifying how operations run.
Fixing this highlighted a weird error case, whereby the error message
we'd see when we called a banned operation would indicate that we had
called a different operation from the one we were *actually* calling.
This made fixing the issue far more time consuming than it should have
been (I thought it was doing something else entirely!). Turns out this
is due to late binding [1]. The fixture is rewritten to avoid the issue,
simplifying it significantly in the process.
[1] https://stackoverflow.com/a/3431699/613428
Change-Id: Ib3f9099160265c4eafea1b2e38537c58eadf9a5c
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
sqlalchemy-migrate does not (and will not) support sqlalchemy 2.0. We
need to drop these migrations to ensure we can upgrade our sqlalchemy
version.
Change-Id: I31ba9e4f129a7cc28744e814b5fd28eb284ae3de
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
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>
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>
Douglas Mendizábal