openstack/kolla-ansible.git/doc/source/reference/shared-services/keystone-guide.rst, branch stable/2025.1

Remove deleted mod_auth_openidc option

2026-04-07T17:56:08+00:00

The option OIDCTokenBindingPolicy was deleted from mod_auth_openidc [1]. Remove it from our documentation. SSO with Keycloak was successfully tested without it. Keep documentation about keystone_federation_oidc_additional_options by using OIDCOutgoingProxy instead. [1] https://github.com/OpenIDC/mod_auth_openidc/commit/f9a52507acee0817b9cc91ec194bcea894f77ee0 Change-Id: Icfe4ef0f6070a97c4e43f691643169e71cc2772a Signed-off-by: Pierre Riteau (cherry picked from commit 2e9f2caaf8a8eb19563a1085e6a23d778b279dbc)

CI: Add codespell to pep8

2024-04-22T13:19:23+00:00

Fix existing spelling errors Change-Id: Ie689cf5a344aaa630a4860448b09242333a8e119

keystone: Add support for OIDC options

2023-11-15T14:49:35+00:00

Introduce keystone_federation_oidc_additional_options variable Change-Id: I39b9f35dab6f4e3ac2fcb505aabd2589e6e2ca69

Keystone OIDC JWKS fix

2022-10-03T10:36:11+00:00

JWT failed to validate on auth-oidc endpoint used by openstack cli with "could not find key with kid: XX" error. To fix this we need to use jwks provided in "jwks_uri" by OIDC metadata endpoint. Missing "ServerName" directive from vhost config causes redirection to fail in some cases when external tls is enabled. - added "keystone_federation_oidc_jwks_uri" variable - added "OIDCOAuthVerifyJwksUri" to keystone vhost config - added "ServerName" to keystone vhost config - jinja templating additional whitespace trimmed to correct end result indentation and empty newlines Closes-bug: 1990375 Change-Id: I4f5c1bd8be8e23cf6299ca4bdfd79e9d98c9a9eb

Delete keystone_token_provider variable

2022-05-17T13:53:23+00:00

In the last PTG it was decided to drop the keystone_token_provider variable, because there is no other option anymore. Signed-off-by: Ramona Rautenberg Change-Id: I1ee2c3f9b7dbbbf4633c5874cdbb3c4f8c09e277

OpenID Connect certifiate file is optional

2022-01-09T21:55:34+00:00

Some ID provider configurations do not require a certificate file. Change the logic to allow this, and update documentation accordingly. Change-Id: I2c34a6b5894402bbebeb3fb96768789bc3c7fe84

Add support to OpenID Connect Authentication flow

2021-02-15T19:57:47+00:00

This pull request adds support for the OpenID Connect authentication flow in Keystone and enables both ID and access token authentication flows. The ID token configuration is designed to allow users to authenticate via Horizon using an identity federation; whereas the Access token is used to allow users to authenticate in the OpenStack CLI using a federated user. Without this PR, if one wants to configure OpenStack to use identity federation, he/she needs to do a lot of configurations in the keystone, Horizon, and register quite a good number of different parameters using the CLI such as mappings, identity providers, federated protocols, and so on. Therefore, with this PR, we propose a method for operators to introduce/present the IdP's metadata to Kolla-ansible, and based on the presented metadata, Kolla-ansible takes care of all of the configurations to prepare OpenStack to work in a federated environment. Implements: blueprint add-openid-support Co-Authored-By: Jason Anderson Change-Id: I0203a3470d7f8f2a54d5e126d947f540d93b8210

doc: Start using openstackdoctheme's extlink extension

2019-06-17T15:00:42+00:00

This ensures we have version-specific references to other projects [1]. Note that this doesn't mean the URLs are actually valid - we need to do more work (linkcheck?) here, but it's an improvement nonetheless. [1] https://docs.openstack.org/openstackdocstheme/latest/#external-link-helper Change-Id: I118e4d211617c5df66ff04dc04e308a1d2fc67ad

Fix keystone fernet key rotation scheduling

2019-05-17T13:05:48+00:00

Right now every controller rotates fernet keys. This is nice because should any controller die, we know the remaining ones will rotate the keys. However, we are currently over-rotating the keys. When we over rotate keys, we get logs like this: This is not a recognized Fernet token TokenNotFound Most clients can recover and get a new token, but some clients (like Nova passing tokens to other services) can't do that because it doesn't have the password to regenerate a new token. With three controllers, in crontab in keystone-fernet we see the once a day correctly staggered across the three controllers: ssh ctrl1 sudo cat /etc/kolla/keystone-fernet/crontab 0 0 * * * /usr/bin/fernet-rotate.sh ssh ctrl2 sudo cat /etc/kolla/keystone-fernet/crontab 0 8 * * * /usr/bin/fernet-rotate.sh ssh ctrl3 sudo cat /etc/kolla/keystone-fernet/crontab 0 16 * * * /usr/bin/fernet-rotate.sh Currently with three controllers we have this keystone config: [token] expiration = 86400 (although, keystone default is one hour) allow_expired_window = 172800 (this is the keystone default) [fernet_tokens] max_active_keys = 4 Currently, kolla-ansible configures key rotation according to the following: rotation_interval = token_expiration / num_hosts This means we rotate keys more quickly the more hosts we have, which doesn't make much sense. Keystone docs state: max_active_keys = ((token_expiration + allow_expired_window) / rotation_interval) + 2 For details see: https://docs.openstack.org/keystone/stein/admin/fernet-token-faq.html Rotation is based on pushing out a staging key, so should any server start using that key, other servers will consider that valid. Then each server in turn starts using the staging key, each in term demoting the existing primary key to a secondary key. Eventually you prune the secondary keys when there is no token in the wild that would need to be decrypted using that key. So this all makes sense. This change adds new variables for fernet_token_allow_expired_window and fernet_key_rotation_interval, so that we can correctly calculate the correct number of active keys. We now set the default rotation interval so as to minimise the number of active keys to 3 - one primary, one secondary, one buffer. This change also fixes the fernet cron job generator, which was broken in the following cases: * requesting an interval of more than 1 day resulted in no jobs * requesting an interval of more than 60 minutes, unless an exact multiple of 60 minutes, resulted in no jobs It should now be possible to request any interval up to a week divided by the number of hosts. Change-Id: I10c82dc5f83653beb60ddb86d558c5602153341a Closes-Bug: #1809469