diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 2ea2931..c1f7f08 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -28,7 +28,7 @@ jobs: - uses: vexxhost/docker-atmosphere/.github/actions/checkout@a1ad25c00b6bbf44621748b3a9ed664c6b6cf929 # main with: repository: openstack/keystone - ref: a568938e0c967a56ade269c93f42718008487b14 # master + ref: b6fd80996b882890a51f3e2aab41d952d7ff68ae # master - uses: vexxhost/docker-atmosphere/.github/actions/build-image@a1ad25c00b6bbf44621748b3a9ed664c6b6cf929 # main with: diff --git a/patches/openstack/keystone/0001-Revert-setup-Remove-pbr-s-wsgi_scripts.patch b/patches/openstack/keystone/0001-Revert-setup-Remove-pbr-s-wsgi_scripts.patch index ac5b47d..ab5032d 100644 --- a/patches/openstack/keystone/0001-Revert-setup-Remove-pbr-s-wsgi_scripts.patch +++ b/patches/openstack/keystone/0001-Revert-setup-Remove-pbr-s-wsgi_scripts.patch @@ -1,18 +1,33 @@ -From 3d312a6ce35734aa490b2928d0a6f59fd2077119 Mon Sep 17 00:00:00 2001 +From 817abe6c2ba5bd64bcb5110f128c723e783c410d Mon Sep 17 00:00:00 2001 From: ricolin -Date: Mon, 8 Sep 2025 09:56:09 +0800 +Date: Thu, 23 Apr 2026 01:24:42 +0000 Subject: [PATCH] Revert "setup: Remove pbr's wsgi_scripts" This reverts commit 0d2cc1a3af4dbd2825cef5992056bffe935eaadd. --- + pyproject.toml | 4 ++++ .../notes/remove-wsgi-scripts-615b97ee4d6e0de2.yaml | 8 -------- - setup.cfg | 4 ++++ 2 files changed, 4 insertions(+), 8 deletions(-) delete mode 100644 releasenotes/notes/remove-wsgi-scripts-615b97ee4d6e0de2.yaml +diff --git a/pyproject.toml b/pyproject.toml +index 4d27974..136f34b 100644 +--- a/pyproject.toml ++++ b/pyproject.toml +@@ -165,6 +165,10 @@ keystone = "keystone.common.policies:list_rules" + keystone-manage = "keystone.cmd.manage:main" + keystone-status = "keystone.cmd.status:main" + ++[project.entry-points.wsgi_scripts] ++keystone-wsgi-admin = "keystone.server.wsgi:initialize_admin_application" ++keystone-wsgi-public = "keystone.server.wsgi:initialize_public_application" ++ + [project.optional-dependencies] + ldap = [ + "python-ldap>=3.0.0", # PSF diff --git a/releasenotes/notes/remove-wsgi-scripts-615b97ee4d6e0de2.yaml b/releasenotes/notes/remove-wsgi-scripts-615b97ee4d6e0de2.yaml deleted file mode 100644 -index 7eb670e3c..000000000 +index 7eb670e..0000000 --- a/releasenotes/notes/remove-wsgi-scripts-615b97ee4d6e0de2.yaml +++ /dev/null @@ -1,8 +0,0 @@ @@ -24,20 +39,6 @@ index 7eb670e3c..000000000 - module paths for the service, ``keystone.wsgi.api``, if their chosen WSGI - server supports this (gunicorn, uWSGI) or implement a ``.wsgi`` script - themselves if not (mod_wsgi). -diff --git a/setup.cfg b/setup.cfg -index 7b0662c7e..1511d4dd5 100644 ---- a/setup.cfg -+++ b/setup.cfg -@@ -38,6 +38,10 @@ console_scripts = - keystone-manage = keystone.cmd.manage:main - keystone-status = keystone.cmd.status:main - -+wsgi_scripts = -+ keystone-wsgi-admin = keystone.server.wsgi:initialize_admin_application -+ keystone-wsgi-public = keystone.server.wsgi:initialize_public_application -+ - keystone.assignment = - sql = keystone.assignment.backends.sql:Assignment - -- 2.25.1 + diff --git a/patches/openstack/keystone/0002-Invalidate-token-of-user-disabled-in-readonly-backen.patch b/patches/openstack/keystone/0002-Invalidate-token-of-user-disabled-in-readonly-backen.patch deleted file mode 100644 index 5cf56fa..0000000 --- a/patches/openstack/keystone/0002-Invalidate-token-of-user-disabled-in-readonly-backen.patch +++ /dev/null @@ -1,125 +0,0 @@ -From c63efe1df102bcd6d39361bef45baf4ecdb7f1bd Mon Sep 17 00:00:00 2001 -From: Artem Goncharov -Date: Mon, 10 Nov 2025 16:01:18 +0100 -Subject: [PATCH] Invalidate token of user disabled in readonly backend - -We support custom identity plugins. They (and also LDAP backend) may be -considered as a read-only (not supporting user data modification through -Keystone API). When a user of such backend is disabled in the remote -system Keystone will never learn about that and as such tokens for those -users will remain active. They cannot be renewed, but still they stay -valid. -In order to address this situation we need to do additional steps in the -token validation and identify the current state of the user in the -backend. Due to the use of the token caching it is not possible to reuse -normal token validation functionality (it will never gets invalidated as -such). In order to keep performance impact as low as possible modify the -token validation as following: -- regular checks -- revocation check -- if token is still active and revoke check passed fetch current user - data. When user is disabled - log a warning (explaining the situation) - and raise `UserDisabled` exception. - -Since Keystone also does not receive a message when user is reactivated -(i.e. it was accidentally disabled) we cannot use the same approach as -for regular user disabling and generate a token revocation event. This -would cause the user to be locked out until the revocation event -expires. - -Closes-bug: #2122615 -Change-Id: If5b83feabc670ced54ef12fe7826267af7e3419d -Signed-off-by: Artem Goncharov ---- - -diff --git a/keystone/tests/unit/test_v3_auth.py b/keystone/tests/unit/test_v3_auth.py -index b95a21e..e6762b2 100644 ---- a/keystone/tests/unit/test_v3_auth.py -+++ b/keystone/tests/unit/test_v3_auth.py -@@ -873,18 +873,29 @@ - # Make sure the token is valid - r = self._validate_token(unscoped_token) - self.assertValidUnscopedTokenResponse(r) -+ user_id = self.user["id"] -+ domain_id, driver, entity_id = ( -+ PROVIDERS.identity_api._get_domain_driver_and_entity_id(user_id) -+ ) -+ user = PROVIDERS.identity_api.get_user(user_id) -+ user["enabled"] = False - # Disable the user -- self._set_user_enabled(self.user, enabled=False) -+ PROVIDERS.identity_api._update_user_with_federated_objects( -+ user, driver, entity_id -+ ) -+ PROVIDERS.identity_api.get_user.invalidate(self, user_id) - # Ensure validating a token for a disabled user fails - self._validate_token( - unscoped_token, expected_status=http.client.NOT_FOUND - ) -- # Enable the user -- self._set_user_enabled(self.user) -- # Ensure validating a token for a re-enabled user fails -- self._validate_token( -- unscoped_token, expected_status=http.client.NOT_FOUND -+ ## Re-enable the user -+ user["enabled"] = True -+ PROVIDERS.identity_api._update_user_with_federated_objects( -+ user, driver, entity_id - ) -+ PROVIDERS.identity_api.get_user.invalidate(self, user_id) -+ ## Ensure validating a token for a re-enabled user passes -+ self._validate_token(unscoped_token, expected_status=http.client.OK) - - def test_unscoped_token_is_invalid_after_disabling_user_domain(self): - unscoped_token = self._get_unscoped_token() -diff --git a/keystone/token/provider.py b/keystone/token/provider.py -index 46b7571..ed4186c 100644 ---- a/keystone/token/provider.py -+++ b/keystone/token/provider.py -@@ -214,7 +214,32 @@ - raise exception.TokenNotFound(_('Failed to validate token')) - - if current_time < expiry: -+ # Check for the normal revocation - self.check_revocation(token) -+ -+ # Token is not revoked, but maybe it should've been. -+ if token.user_id: -+ # NOTE: in readonly backend drivers (the ones where the user -+ # can be deactivated remotely without involving Keystone) -+ # there is no token revocation event for the user deactivation. -+ # As such it is necessary to implement an additional check. -+ # Due to the caching of the `_validate_token` function it is -+ # not enough to have the validation in the token model itself. -+ # On the other side we cannot really use the same revocation -+ # strategy, since when the user gets re-enabled (i.e. it was -+ # accidentially disabled) it would not be able to login for a -+ # token TTL time (since we do not know when exactly the user -+ # was disabled/enabled (revocation to expire). -+ # See bug https://bugs.launchpad.net/keystone/+bug/2122615 -+ user = PROVIDERS.identity_api.get_user(token.user_id) -+ -+ if user and not user.get('enabled'): -+ LOG.warn( -+ 'Unable to validate token because user ' -+ f' {token.user_id} is disabled' -+ ) -+ raise exception.UserDisabled(user_id=token.user_id) -+ - # Token has not expired and has not been revoked. - return None - else: -diff --git a/releasenotes/notes/invalidate-token-disabled-user-readonly-backend-5fa09c3e40e8d795.yaml b/releasenotes/notes/invalidate-token-disabled-user-readonly-backend-5fa09c3e40e8d795.yaml -new file mode 100644 -index 0000000..f3b5153 ---- /dev/null -+++ b/releasenotes/notes/invalidate-token-disabled-user-readonly-backend-5fa09c3e40e8d795.yaml -@@ -0,0 +1,8 @@ -+--- -+security: -+ - | -+ A potential security related issue is fixed where a token of the user from a -+ read-only backend (i.e. LDAP) continues being accepted after the user is -+ disabled in the backend. This is caused by the fact that Keystone does not -+ receive any notification for that and is not able to revoke such tokens. -+ See https://bugs.launchpad.net/keystone/+bug/2122615 for details.