| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we check the EC2 signature without the port part of the host value
received, we should properly split host:port. Keep in mind the splitting
should work for values like [fc00::]:123 too.
Change-Id: I1d90dfcea3568e2a9b22069daa428ea6a2a38bd6
Closes-Bug: #1988168
(cherry picked from commit 6c35b366e3c8c6d7f47471b93f5315582301c5ef)
(cherry picked from commit d39790ac4e9dc25af09cdddc6217e36bacbc2bb1)
(cherry picked from commit 0bb9cdee71805af1a7cb0a7db110b336eae5da1e)
(cherry picked from commit aa50b963cce20a76db0c4834b3716d3658c784af)
(cherry picked from commit fe837d87c949f6a2347cf79d81b66214f0a449b3)
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In the keystone installation for rdo [1], installation of
package mod_wsgi is required. But in Centos8/RHEL8 the
package name is updated to python3-mod_wsgi [2].
This patch updates the keystone doc about the same.
[1]https://docs.openstack.org/keystone/queens/install/keystone-install-rdo.html#install-and-configure-components
[2]https://docs.openstack.org/trove/latest/install/apache-mod-wsgi.html
Change-Id: Ic7aac07ab52275cc3b47481d8278a404909fc39f
Closes-Bug: #1886036
(cherry picked from commit 6b37a0abbb52aac0c24ee7b64645ed7265f752da)
|
| |\ \ \
| | | |
| | | |
| | | | |
stable/ussuri
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 1e0cd90191663c100c165d4c6a2b1ca796b5af25)
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 ce6031ca12156620cec214a49d162ec7bb30752f)
(cherry picked from commit 2700adaadcd19baf4ee6edf9b41ff9e6e4009edc)
(cherry picked from commit e8045af63119b201093c424d5f8d029535197c97)
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 60e898c47038667e66a54e0a9a6cd7b91e115f55)
(cherry picked from commit 7b28f1b3b47d0e4a22afe99c64d047016a772da5)
(cherry picked from commit 14d2f5944ce9ef0cc881b91463df7cf3a1114d5b)
(cherry picked from commit 4063ad98e7bebc4c56eb92be742cfda7254c27e7)
|
| |\ \ \ |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
Change-Id: I54021986d17c57d7733d53caa4032c2767eaf25e
(cherry picked from commit 82da8824df0f56ef4e137805bf32d647cef1ea59)
(cherry picked from commit 6dff22b5baa1a19842aca435782fe1f9789f72cc)
(cherry picked from commit a57ae85c9699e7a560b7ffe9786ed0a6453c1e86)
(cherry picked from commit 65c99d6efb6a83fcc16ddf957e59297763e85b6c)
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 c10d5c88ef40e63d4dfefb792d6c3d68acd72dd9)
(cherry picked from commit bdd8f82f60d2e46e5f6951c4407366b89591cde5)
(cherry picked from commit f742fadef1718e070ff4e151d400a96dc6acf74e)
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 ac2631ae33445877094cdae796fbcdce8833a626)
|
| |\ \ \
| |/ /
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The application credential policies use the `rule:owner` policy to allow
users to manage their own credentials. The policy engine pulled the
user_id attribute from the request path instead of the actual
application credential. This allowed for users to exploit the
enforcement and view or delete application credentials they don't own.
This commit attempts to resolve the issue by updating the flask
parameters before they're translated to policy arguments and target
data, prior to policy enforcement.
Change-Id: I903d20fa41270499ca1c39d296120dd97cef5405
Closes-Bug: 1901207
(cherry picked from commit 2d7bf10a5a145ed3b6e34c3cb95e05fb7e33e0d1)
(cherry picked from commit 80832de6ced534bccbf7cfe24a6a01c8262c1779)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 ceae3566e83b26fd6a1679154eae9b0cef29da64)
(cherry picked from commit f47e635b8041542faa05e64606e66d2fbbc5f284)
(cherry picked from commit 5b7d4c80d484262018f937083050844648f07a11)
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
(cherry picked from commit f7df9fba828328d8b20e85d711c1d27c77089632)
(cherry picked from commit 5b860e0b3b4e318b91325996156bae3f99abd6c7)
|
| |\ \ \ \
| | | | |
| | | | |
| | | | | |
stable/ussuri
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
(cherry picked from commit c1dcbb05b4488f1fa3e7af4d9171d11702d94119)
(cherry picked from commit b83170a386ba8da2195c7494d04d832ce9b6d7b0)
(cherry picked from commit 6f93063ff95f3c65af106a09281427e411d01850)
|
| |\ \ \ \
| |_|/ /
|/| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It implements the same behavior of the old one.
It is worth noting that the existing job the MULTI_KEYSTONE does not
produce any effect because this change hasn't been merged yet:
- https://review.opendev.org/399472
and when that merges, the following devstack-gate changes should be
applied directly to this new job definition instead:
- https://review.opendev.org/394895
Both changes are out of scope for this porting.
Change-Id: I5d5d31c8d89b0d2812a5e9be18a81611041e6da8
(cherry picked from commit 3be8d40fc56f876f3dea30812e6352e1e482bb86)
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Lower-constraints is not a requirement of the OpenStack Python PTI
[0] and there currently is a discussion on the mailing list [1]
about dropping the test, with the oslo team already having done
so [2].
The new dependency resolver in pip fails due to incompatible
dependency versions in our lower-constraints file, meaning that
we were never providing any real guarantees with it.
To unblock the CI, I am disabling lower-constraints job for now,
with the option to reenable it in case we fix the constraints,
and based on the outcome of the mailing list discussions and
consensus.
This also marks the k2k federation job as non-voting because Xenial is
broken with Shibboleth and OpenSUSE python dependencies are currently
broken.
[0]. https://governance.openstack.org/tc/reference/pti/python.html
[1]. http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.html
[2]. http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019659.html
Change-Id: I47e747058891596e7717848a0b0bc10f0a235b2f
(cherry picked from commit d6610594d1b766a8ee3ac65182b951f2a3d431f7)
(cherry picked from commit 42faeb277b6eb4b4a772f516a6e2b547f2b2a2b4)
|
| |\ \ \
| | | |
| | | |
| | | | |
calls" into stable/ussuri
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Keystone's paging implementation contains a memory leak. The issue is
noticeable if you integrate keystone with an LDAP server that supports
paging and set `keystone.conf [ldap] page_size` to a low integer
(e.g., 5).
Keystone's LDAP backend uses `python-ldap` to interact with LDAP
servers. For paged requests, it uses `search_ext()`, which is an
asynchronous API [0]. The server responds with a message ID, which the
client uses to retrieve all data for the request. In keystone's case,
the `search_ext()` method is invoked with a page control that tells
the server to deliver responses in increments according to the page
size configured with `keystone.conf [ldap] page_size`. So long as the
client has the original connection used to fetch the message ID, it
can request the rest of the information associated to the request.
Keystone's paging implementation loops continuously for paged
requests. It takes the message ID it gets from `search_ext()` and
calls `result3()`, asking the server for the data associated with that
specific message. Keystone continues to do this until the server sends
an indicator that it has no more data relevant to the query (via a
cookie). The `search_ext()` and `result3()` methods must use the same
LDAP connection.
Given the above information, keystone uses context managers to provide
connections. This is relevant when deploying connection pools, where
certain connections are re-used from a pool. Keystone relies on Python
context managers to handle connections, which is pretty typical
use-case for context managers. Connection managers allow us to do the
following (assuming pseudocode):
with self.get_connection as conn:
response = conn.search_s()
return format(response)
The above snippet assumes the `get_connection` method provides a
connection object and a callable that implements `search_s`. Upon
exiting the `with` statement, the connection is disconnected, or put
back into the pool, or whatever the implementation of the context
manager decides to do. Most connections in the LDAP backend are
handled in this fashion.
Unfortunately, the LDAP driver is somewhat oblivious to paging, it's
control implementation, or the fact that it uses an asynchronous API.
Instead, the driver leaves it up to the handler objects it uses for
connections to determine if the request should be controlled via
paging. This is an anti-pattern since the backend establishes the
connection for the request but doesn't ensure that connection is
safely handled for asynchronous APIs.
This forces the `search_ext()` and `result3()` implementations in the
PooledLDAPHandler to know how to handle connections and context
managers, since it needs to ensure the same connection is used for
paged requests. The current code tried to clean up the context
manager responsible for connections after the results are collected
from the server using the message ID. I believe it does this because
it needs to get a new connection for each message in the paged
results, even though it already operates from within a connection
established via a context manager and the PooledLDAPHandler almost
always returns the same connection object from the pool. The code
tries to use a weak reference to create a callback that tears down the
context manager when nothing else references it. At a high-level, the
idea is similar to the following pseudocode:
with self.get_connection as conn:
while True:
ldap_data = []
context_manager = self.get_connection()
connection = context_manager.__enter__()
message_id = connection.search_ext()
results = connection.result3(message_id)
ldap_data.append(results)
context_manager.__exit__()
I wasn't able to see the callback get invoked or work as described in
comments, resulting in memory bloat, especially with low page sizes
which results in more requests. A weak reference invokes the callback
when the weak reference is called, but there are no other references
to the original object [1]. In our case, I don't think we invoke that
path because we don't actually do anything with the weak reference. We
assume it's going to run the callback when the object is garbage
collected.
This commit attempts to address this issue by using the concept of a
finalizer [2], which was designed for similar cases. It also attempts
to hide the cleanup implementation in the AsynchronousMessage object,
so that callers don't have to worry about making sure they invoke the
finalizer.
An alternative approach would be to push more of the paging logic and
implementation up into the LDAP driver. This would make it easier to
put the entire asynchronous API flow for paging into a `with`
statement and relying on the normal behavior of context managers to
clean up accordingly. This approach would remove the manual cleanup
invocation, regardless of using weak references or finalizer objects.
However, this approach would likely require a non-trivial amount of
design work to refactor the entire LDAP backend. The LDAP backend has
other issues that would complicate the re-design process:
- Handlers and connection are generalized to mean the same thing
- Method names don't follow a convention
- Domain-specific language from python-ldap bleeds into keystone's
implementation (e.g., get_all, _ldap_get_all, add_member) at
different points in the backend (e.g., UserApi (BaseLdap), GroupApi
(BaseLdap), KeystoneLDAPHandler, PooledLDAPHandler,
PythonLDAPHandler)
- Backend contains dead code from when keystone supported writeable
LDAP backends
- Responsibility for connections and connection handling is spread
across objects (BaseLdap, LDAPHandler)
- Handlers will invoke methods differently based on configuration at
runtime, which is a sign that the relationship between the driver,
handlers, and connection objects isn't truely polymorphic
While keeping the logic for properly handling context managers and
connections in the Handlers might not be ideal, it is a relatively
minimal fix in comparison to a re-design or backend refactor. These
issues can be considered during a refactor of the LDAP backend if or
when the community decides to re-design the LDAP backend.
[0] https://www.python-ldap.org/en/python-ldap-3.3.0/reference/ldap.html#ldap.LDAPObject.search_ext
[1] https://docs.python.org/3/library/weakref.html#weakref.ref
[2] https://docs.python.org/3/library/weakref.html#finalizer-objects
Closes-Bug: 1896125
Change-Id: Ia45a45ff852d0d4e3a713dae07a46d4ff8d370f3
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Without this patch, if this exception is reached, it won't be properly
formed and will result in a log message like this:
Failed to insert replacement values into translated message Could not
find user: %(user_id)s. (Original: 'Could not find user:
%(user_id)s.'): 'user_id'
This patch adds the right parameters to ensure the exception properly
logs the user ID and the translation doesn't fail.
Change-Id: I3229d9a237633cda8f6a25f396a75b8310757d9d
(cherry picked from commit 2d26a87229e25eb723347926e098528695a13543)
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The newest vine release (5.0.0) is incompatible with the version of amqp
used on stable branches and results in test errors[1]:
"AttributeError: False does not have the attribute 'info'"
Ensure the lower-constraints tox environment uses the same version of
vine as defined in upper-constraints.txt.
[1] https://zuul.opendev.org/t/openstack/build/78dfcdd4272241459fb904aa70600e5b
Depends-on: https://review.opendev.org/755405
Change-Id: I4b9b11b89e9f4120ae4b7fb8e213628dd9e8121c
(cherry picked from commit 06e58fcea036fbe95b6a2802a471e8913c0b25e4)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If LDAP returns a UUID as an octet string the LDAP driver will fail to
convert it to something meaningful. The error usually looks something
like:
ID attribute objectGUID not found in LDAP object
Microsoft AD's `objectGUID` parameter is stored and transmitted as an
octet string [0]. If you attempt to use the `objectGUID` to generate
user or group IDs, you'll get an HTTP 404 because keystone can't decode
it properly. This is unfortunate because `objectGUID` are a fixed
length, UUID format, and ideal for generating IDs in keystone. As
opposed to using the object's CN, which is variable length, and can
generate hashes that are larger than keystone's database table limit for
user IDs.
[0] https://docs.microsoft.com/en-us/windows/win32/ad/reading-an-objectampaposs-objectguid-and-creating-a-string-representation-of-the-guid
Change-Id: Id80b17bdff015e10340e636102576b7435bd564f
Closes-Bug: 1889936
(cherry picked from commit 8bf222ac5d390e25d306d35f69bd958b18bee4d8)
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
keystone does not have any lower constraint for PyMySQL so the
latest version 0.10.0 is picked by the job which is failing [1]
In OpenStack, PyMySQL upper constraint is .9.3 means that version
is tested not 0.10.0 [2] let's add PyMySQL lower constraint also
so that we test lower-constraint job with correct lower version.
[1]https://zuul.opendev.org/t/openstack/build/3077d96f4fff4b7985cb763d0635d471/log/job-output.txt#621
[2]https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L384
Change-Id: I3834b3b34641c006c70614d5331d292c41f8a346
Closes-Bug: #1888886
(cherry picked from commit 3de085b1eb9750cb0d0d25cb468250cf34804eaf)
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The integrated gate template (integrated-gate-py3) has been switched
to the new grenade name (grenade-py3 -> grenade). This repo uses the
template but also has for irrelevant files an extra entry.
Rename the job following the template change to avoid duplicate
grenade runs.
Details:
- http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014602.html
Depends-On: https://review.opendev.org/725148
Change-Id: I52ebbcae0d77c0420848a37babc73bb75dd58e0b
(cherry picked from commit 2b4e53792d75bc02a47b0caf2b53d3cb55b53737)
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This change addresses several issues in the creation and use of EC2/S3
credentials with keystone tokens.
1. Disable altering credential owner attributes or metadata
Without this patch, an authenticated user can create an EC2 credential
for themself for a project they have a role on, then update the
credential to target a user and project completely unrelated to them. In
the worst case, this could be the admin user and a project the admin
user has a role assignment on. A token granted for an altered credential
like this would allow the user to masquerade as the victim user. This
patch ensures that when updating a credential, the new form of the
credential is one the acting user has access to: if the system admin
user is changing the credential, the new user ID or project ID could be
anything, but regular users may only change the credential to be one
that they still own.
Relatedly, when a user uses an application credential or a trust to
create an EC2 credential, keystone automatically adds the trust ID or
application credential ID as metadata in the EC2 access blob so that it
knows how the token can be scoped when it is used. Without this patch, a
user who has created a credential in this way can update the access blob
to remove or alter this metadata and escalate their privileges to be
fully authorized for the trustor's, application credential creator's, or
OAuth1 access token authorizor's privileges on the project. This patch
fixes the issue by simply disallowing updates to keystone-controlled
metadata in the credential.
2. Respect token roles when creating EC2 credentials
Without this patch, a trustee, an application credential user, or an
OAuth1 access token holder could create an EC2 credential or an
application credential using any roles the trustor, application
credential creator, or access token authorizor had on the project,
regardless of whether the creator had delegated only a limited subset of
roles. This was because the trust_id attribute of the EC2 access blob
was ignored, and no metadata for the application credential or access
token was recorded either. This change ensures that the access
delegation resource is recorded in the metadata of the EC2 credential
when created and passed to the token provider when used for
authentication so that the token provider can look up the correct roles
for the request.
Change-Id: I39d0d705839fbe31ac518ac9a82959e108cb7c1d
Closes-bug: #1872733
Closes-bug: #1872755
Closes-bug: #1872735
(cherry picked from commit 37e9907a176dad6843819b1bec4946c3aecc4548)
|
| |\ \ \
| |/ /
| | /
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Without this patch, when an OAuth1 request token is authorized with a
limited set of roles, the roles for the access token are ignored when
the user uses it to request a keystone token. This means that user of an
access token can use it to escallate their role assignments beyond what
was authorized by the creator. This patch fixes the issue by ensuring
the token model accounts for an OAuth1-scoped token and correctly
populating the roles for it.
Change-Id: I02f9836fbd4d7e629653977fc341476cfd89859e
Closes-bug: #1873290
(cherry picked from commit 6c73690f779a42a5c62914b6bc37f0ac2f41a3e3)
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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/ussuri branch, tests will
continue to use the upper-constraints list on master.
Change-Id: I1ba5e8d68d807c9b6dbd3feb3d5abd21a2d8d9d3
|
| |\ \ \
| |/ /
| | /
| |/
|/| |
|
| | |
| |
| |
| | |
Change-Id: Ia39b41727d5b529f4b2bec46fb90fbd5e46341f0
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
EC2 token requests contain a signature that signs the entire request,
including the access timestamp. While the signature is checked, the
timestamp is not, and so these signed requests remain valid
indefinitely, leaving the token API vulnerable to replay attacks. This
change introduces a configurable TTL for signed token requests and
ensures that the timestamp is actually validated against it.
The check will work for either an AWS Signature v1/v2 'Timestamp'
parameter[1] or the AWS Signature v4 'X-Aws-Date' header or
parameter[2].
Although this technically adds a new feature and the default value of
the feature changes behavior, this change is required to protect
credential holders and therefore must be backported to all supported
branches.
[1] https://docs.aws.amazon.com/general/latest/gr/signature-version-2.html
[2] https://docs.aws.amazon.com/general/latest/gr/sigv4-date-handling.html
Change-Id: Idb10267338b4204b435df233c636046a1ce5711f
Closes-bug: #1872737
(cherry picked from commit ab89ea749013e7f2c46260f68504f5687763e019)
|
| |/
|
|
|
|
|
| |
For more information about this automatic import see:
https://docs.openstack.org/i18n/latest/reviewing-translation-import.html
Change-Id: I3ec600bcc04c2dfacac58a2ef0ce0f4a4d1b0d97
|
| |\ |
|
| | |
| |
| |
| | |
Change-Id: Id17ad67d366d539f54752b076b4e6b14187f9782
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A code related to UUID tokens was removed from keystone during
Rocky developepment cycle. Change-Id:
I76d5c29f6b1572ee3ec7f2b1af63ff31572de2ce
This patch removes a small note related to UUID tokens from
keystone example configuration file.
Change-Id: I40782c4f41b1a0a7bd285b53b60cd8aca000ede0
|
| |\ \ \ |
|
