2023.1 Series Release Notes¶

23.0.2-1¶

Added a new command to the admin cli tool: keystone-manage reset_last_active. This new command updates the database to overwritet any NULL values in last_active_at in the user table to the current time. This is a necessary step to fix Bug #2074018. See launchpad for details.

The new keystone-manage rest_last_active command resets all NULL values in last_active_at in the user table to help fix Bug #2074018. Running this command may be necessary in environments that have been deployed for a long time and later decide to adopt the [security_compliance disable_user_account_days_inactive = X option. See Bug #2074018 for details.

A side-effect of this command is that it resets the amount of time that an unused account is active for. Unused accounts will remain active until the configured days have elapsed since the day the command is run.

Fixed Bug #2074018: Changed the user model to always save the date of the last user activity in last_active_at. Previous to this change, the last_active_at field was only updated when the option for [security_compliance] disable_user_account_days_inactive was set. If your deployment is affected by this bug, you must run keystone-manage reset_last_active before setting the disable_user_account_days_inactive option.

A new option ‘randomize_urls’ can be used to randomise the order in which Keystone connects to the LDAP servers in [ldap] ‘url’ list. It is false by default.

Passwords that are hashed using bcrypt are now truncated properly to the maximum allowed length by the algorythm. This solves regression, when passwords longer then 54 symbols are getting invalidated after the Keystone upgrade.

[blueprint support-oauth2-mtls] Provide the option for users to proof-of-possession of OAuth 2.0 access token based on RFC8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens. Users can now use the OAuth 2.0 Access Token API to get an OAuth 2.0 certificate-bound access token from the keystone identity server with OAuth 2.0 credentials and Mutual-TLS certificates. Then users can use the OAuth 2.0 certificate-bound access token and the Mutual-TLS certificates to access the OpenStack APIs that use the keystone middleware to support OAuth 2.0 Mutual-TLS client authentication.

Passwords will now be automatically truncated if the max_password_length is greater than the allowed length for the selected password hashing algorithm. Currently only bcrypt has fixed allowed lengths defined which is 54 characters. A warning will be generated in the log if a password is truncated. This will not affect existing passwords, however only the first 54 characters of existing bcrypt passwords will be validated.

[bug 1992183] [CVE-2022-2447] Tokens issued with application credentials will now have their expiration validated against that of the application credential. If the application credential expires before the token the token’s expiration will be set to the same expiration as the application credential. Otherwise the token will use the configured value.