We should use the template corresponding to the release. This change
replaces the wrong template(victoria template) by the appropriate one
(wallaby template).

Change-Id: Ic25357863b78c0e5c11cbd0e0da1dbd3e4099519

Training-labs had been officially retired as no maintainer.
The information of training-labs has been deleting in the openstack
documentatioan. It is not appropriate to continue the presentation in
note form here.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025586.html
[2] https://opendev.org/openstack/training-labs/commit/e78d74f10558ab3e6a9a6fd7d45e617c15e9c3d8

Change-Id: I0ac3d05389041ac58fe2347171541ffaaf151fdf

When connecting to some LDAP server software, the ldap client returns
bytes instances instead of the expected strings. This can result in
either being transparently converted to strings, when the data is
inserted via sqlalchemy into the database, or could be used as
input to other functions, and/or cached, which causes unexpected
results.

Closes-Bug: #1952458
Resolves: rhbz#1964872
Change-Id: I77148641715efe09e3adc2e9432e66e50fb444b4
(cherry picked from commit 1e0cd901)

Testing a new FIPS enabled gate job here.  This job will be
for Centos 8 with FIPS enabled.  This will use a playbook in
the zuul-jobs repo to enable FIPS.

Change-Id: I3187971a14b38c7ca3bb64bdd3d18c64709c466f
(cherry picked from commit 50f0a50c)

We updated these policies when we introduces system scope and default
roles, but the policy names accidentally changed, which makes the policy
files render with an alias because oslo.policy thinks the names are
changing.

Conflicts:
      keystone/common/policies/application_credential.py in later
      releases the deprecated parameters were moved from the
      DocumentedRuleDefault object to the DeprecatedRule object, which
      is a non-functional change.

Change-Id: I1121f1abe769ee83ffc285103a95ee95540ce727
(cherry picked from commit 60e898c4)
(cherry picked from commit 7b28f1b3b47d0e4a22afe99c64d047016a772da5)

There was a trailing s in two of these policies and it caused the policy
names to mismatch, which causes confusion with the rendered policy files
and potentially causes uses with deprecation logic.

Conflicts:
      keystone/common/policies/ec2_credential.py in later releases the
      deprecated parameters were moved from the DocumentedRuleDefault
      object to the deprecated object.

Change-Id: I54021986d17c57d7733d53caa4032c2767eaf25e
(cherry picked from commit 82da8824)
(cherry picked from commit 6dff22b5baa1a19842aca435782fe1f9789f72cc)

This cause the sample generated policy file to alias the old name with
the new policy name, which isn't needed since we're not renaming these
policies at all and it was likely a typo.

Conflicts:
      keystone/common/policies/identity_provider.py
      In later releases the deprecation parameters were moved up to the
      deprecated options and not in the DocumentedRule defaults.

Change-Id: Idfd9adbbe800bbc21814d94002a2b61524cce28a
(cherry picked from commit c10d5c88)

This avoids the "String length exceeded." error, when using LDAP
domain specific backend in case the user uses a user id
attribute, which can exceed the previous constraint of 64 chars.

Change-Id: I923a2a2a5e79c8f265ff436e96258288dddb867b
Closes-Bug: #1929066
Resolves: rhbz#1959345
(cherry picked from commit ce6031ca)

This change hides the AccountLocked exception from being returned
to the end user to hide sensitive information that a potential
malicious person could gain insight from.

The notification handler catches the AccountLocked exception as
before, but after sending the audit notification, it instead
bubbles up Unauthorized rather than AccountLocked.

Co-Authored-By: Samuel de Medeiros Queiroz <samueldmq@gmail.com>

Change-Id: Id51241989b22c52810391f3e8e1cadbf8613d873
Related-Bug: #1688137
(cherry picked from commit ac2631ae)

Keystone's update_user() method in the SQL driver processes a lot of
information about how to update users. This includes evaluating password
logic and authentication attempts for PSI-DSS. This logic is evaluated
after keystone pulls the user record from SQL and before it exits the
context manager, which performs the write.

When multiple clients are all updating the same user reference, it's
more likely they will see an HTTP 500 because of race conditions exiting
the context manager. The HTTP 500 is due to stale data when updating
password expiration for old passwords, which happens when setting a new
password for a user.

This commit attempts to handle that case more gracefully than throwing a
500 by detecting StaleDataErrors from sqlalchemy and retrying.  The
identity sql backend will retry the request for clients that have
stale data change from underneath them.

Change-Id: I75590c20e90170ed862f46f0de7d61c7810b5c90
Closes-Bug: 1885753
(cherry picked from commit ceae3566)

Update the URL to the upper-constraints file to point to the redirect
rule on releases.openstack.org so that anyone working on this branch
will switch to the correct upper-constraints list automatically when
the requirements repository branches.

Until the requirements repository has as stable/wallaby branch, tests will
continue to use the upper-constraints list on master.

Change-Id: Idd89731aaf3138bb400182f5852a85ad23ea309d

Change-Id: I6624fb2b4299aba328b02a870722ed60c89876a6

This commit introduces a new check and gate job for keystone to use the
functional RBAC tests in keystone-tempest-plugin.

These tests were derived from keystone's original protection tests, but
they use tempest and they're re-useable for people looking to validate
secure RBAC functionality in their own deployments.

Depends-On: https://review.opendev.org/#/c/686305/
Change-Id: I813cff07c20fcba1aaec6a5e68014a2a9eb9462e

After reading through the documentation, I thought this sentence sounded
funny using 'within' and 'in' so close to each other. I updated it so
that it isn't quite so jarring.

Change-Id: I2619108216035a37823e53efb5a3f9fe6cfe5cbb

This commit updates the documentation for service api protection to
better describe the overall personas for system, domain, and project
users. It also adds some examples that show operators how to list users
with all role assignments on a particular target, which include a
superset of the existing examples.

Change-Id: I40dd33fc0afa0240c6b1cd48322fd988fc5524af

The secure RBAC work propogating throughout the community has led to
some interesting discussions about how to implement support for
``reader``. Specifically, should ``reader`` be used for auditing
deployments?

Some compliance targets, verified by third-party auditors, require
access to sensitive information (e.g., thinking about license keys in
glance images or volume type encryption metadata in cinder). The concern
raised among developers updating their default policies to use
``reader`` roles is if they should be using that role to protect
sensitive information, especially if it's the least-authoritative role
in the hierarchy between reader, member, and admin.

This documentation is supposed to assist deployers in understanding the
various personas that developers are implementing by default, but it
doesn't call out the complicated relationship we have with ``reader``
and auditing.

The change here proposes that we explicitly say that ``reader``
shouldn't be used to protect sensitive information, regardless of the
scope, because ``reader`` was designed to be the least-authoritative
role provided by keystone, by default. Instead, service developers
working to implement these personas consistently in other services
should keep sensitive information, if applicable to their API or
resources, at the ``admin`` tier of the hierarchy. This provides better
protection of sensitive information by not exposing is implicitly.

We can consider supporting a formal default role for auditing in the
future, but building it outside the default implied role tree so that
it's not implied to anyone with a role assignment. This will come at
another time and we can use implied roles to re-use all the work we've
done across OpenStack to implement support for ``reader``.

For now, ``reader`` should be viewed from the perspective of the
least-authoritative permissions grant-able to a given scope (e.g.,
system, domain, or project). Even if ``reader`` has limited use in
auditing deployments, it's still incredibly useful for operators
because they have a role they can grant to users with minimal trust, or
minimal permissions in the deployment.

This commit acknowledges the use-case for an elevated auditor role and
that it's something we can implement as a formal role in keystone in the
future.

Change-Id: Iea28faf1b3e63c7ab07e90808d2bc76ee3ee0612

As per the community goal of migrating the policy file
the format from JSON to YAML[1], we need to do two things:

1. Change the default value of '[oslo_policy] policy_file''
config option from 'policy.json' to 'policy.yaml' with
upgrade checks.

2. Deprecate the JSON formatted policy file on the project side
via warning in doc and releasenotes.

Also replace policy.json to policy.yaml ref from doc and tests.

[1]https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html

Change-Id: Ic65d2fd6ce7215b4a47a6fb41b9cbf991f27773b

In I59335b4f318bae2e29ab139cdea089a4d6e14305, oslo.db
is now emitting deprecation warnings for SQLAlchemy-migrate
functions.  This breaks Keystone tests which raise on
DeprecationWarning, so add to the filters.

Change-Id: I42f0abc2ddf8c53239d5098d5f32b667314b942d

This is a non-voting job to validate py3 unittests on ARM64

Task: 40403
Story: 2007938

Change-Id: Ibb82d65784368ff82588d6879111cb6c7eb780ca

python-ldap3.0 or later running on python3 uses str or bytes
data type according to what fields are returned.
local_id may be a bytes data type.
To handle it properly, mapping[key] needs to be examined for
identifying its data type and what python version is used.

Closes-Bug: #1901654
Change-Id: Iac097235fd31e166028c169d14ec0937c663c21c

For more information about this automatic import see:
https://docs.openstack.org/i18n/latest/reviewing-translation-import.html

Change-Id: Ic8c9b155a20aea11f74794aeb45a4e92e632148a