Current Series Release Notes¶

30.0.0-16¶

Keystone now transparently upgrades stored password hashes on successful authentication when the stored hash uses a different algorithm than [identity] password_hash_algorithm, or a weaker work factor than the currently configured value. This applies to bcrypt, bcrypt_sha256, scrypt, and PBKDF2-SHA512. Operators can raise password_hash_rounds or change algorithm without requiring users to reset their passwords. The rehash preserves password metadata (created_at, expires_at, history) and only updates the hash itself. See the administrator guide on password hashing for details.

EC2 and S3 token requests that omit a timestamp (Timestamp query parameter, X-Amz-Date, or the date embedded in the string-to-sign) are now rejected with HTTP 401. All AWS-compliant clients include a timestamp by default; only non-standard or hand-crafted requests are affected.

The [credential] auth_ttl configuration option (default 15 minutes) is now reliably applied to all EC2/S3 authentication requests. Previously it was silently ignored for requests that did not include an explicit timestamp field. Operators who have set a custom auth_ttl value will see it take effect as documented.

The deprecated [oslo_policy] enforce_scope configuration option has been removed in oslo.policy version 6.0.0 which will impact Keystone as there is no longer any way to disable RBAC policy scope enforcement; scope checks are now always enforced regardless of configuration.

If you are not upgrading the oslo.policy to 6.0.0, then there will not be any change in scope enforcement behaviour.

[bug 2165281] POST /v3/credentials no longer persists client-supplied trust_id, app_cred_id, or access_token_id values in an EC2 credential blob. Those fields are server-managed: they are stripped from the request and only stamped from the caller’s auth context when present. Previously a primary-auth user who learned an unrelated impersonation trust_id could forge it into their own EC2 blob and later exchange it via POST /v3/ec2tokens or POST /v3/s3tokens for a project-scoped token as the trustor.

Independently, the EC2/S3 authentication path now requires the credential’s user_id to be a party to the referenced trust (trustor or trustee), and to match the owning user of a referenced application credential or OAuth1 access token. This closes the auth-time gap for any EC2 credentials that already carry a forged delegation id in their blob.

EC2 and S3 signed token requests now require a timestamp. Previously, requests that omitted the timestamp field bypassed the [credential] auth_ttl replay-protection window entirely. Keystone now enforces that every signed EC2/S3 request carries a verifiable timestamp and rejects those that do not with HTTP 401 Unauthorized.

For requests forwarded by Swift’s s3token middleware the timestamp is extracted from the signature-verified string-to-sign (SigV2 Date / x-amz-date / Expires, or SigV4 X-Amz-Date), using the same urlsafe-base64 decoding as signature verification. Extraction failures fail closed.

Fixed identity provider remote_ids JSON schema validation rejecting values longer than 64 characters. The database column allows 255 characters; the incorrect limit was introduced when federation protocol schema validation reused a 64-character string type for IdP remote IDs. Typical OIDC issuer URLs often exceed 64 characters.

[bug 2154808] Fixed an issue where renaming a project to a name already in use within the same domain via PATCH /v3/projects/{project_id} returned HTTP 500 instead of the documented HTTP 409 Conflict. The conflict-message helper assumed the project payload always carried an id key, which is never the case for the update API (the schema forbids id in the request body). The helper now derives the project id from the surrounding context, and the correct 409 Conflict response is returned.

Fixed federation protocol PATCH JSON schema incorrectly requiring mapping_id on every update. PATCH now accepts a body that changes only remote_id_attribute, matching the API behavior before federation protocol request validation was tightened.