mirror of
https://github.com/keycloak/keycloak.git
synced 2026-01-10 15:32:05 -03:30
e09ce9e18d
closes #42728 Signed-off-by: mposolda <mposolda@gmail.com> Signed-off-by: Marek Posolda <mposolda@gmail.com> Co-authored-by: andymunro <48995441+andymunro@users.noreply.github.com>
172 lines
10 KiB
Plaintext
172 lines
10 KiB
Plaintext
// Release notes should contain only headline-worthy new features,
|
|
// assuming that people who migrate will read the upgrading guide anyway.
|
|
|
|
Read on to learn more about each new feature, and https://www.keycloak.org/docs/latest/upgrading/index.html[find additional details in the upgrading guide] if you are upgrading from a previous release of {project_name}.
|
|
|
|
= Federated client authentication preview
|
|
|
|
Identity providers are now able to federate client authentication. This allows clients to authenticate with SPIFFE JWT SVIDs,
|
|
Kubernetes service accounts, or tokens issued by a OpenID Connect identity provider.
|
|
|
|
This feature is currently preview, and expected to become supported in 26.5.
|
|
|
|
= Update Email Workflow is now supported
|
|
|
|
This feature provides a more secure and consistent flow to update user
|
|
emails. Accounts are forced to both re-authenticate and verify their
|
|
emails before any account updates.
|
|
|
|
For more information, see link:{adminguide_link}#_update-email-workflow[Update Email Workflow].
|
|
|
|
= Passkeys integration is now supported
|
|
|
|
This feature integrates passkeys seamlessly in the {project_name} forms using both conditional and modal UIs. To activate the integration in the realm, go to *Authentication*, *Policies*, *Webauthn Passwordless Policy* and switch *Enable Passkeys* to enabled.
|
|
|
|
For more information, see link:{adminguide_link}#passkeys_server_administration_guide[Passkeys].
|
|
|
|
= New conditional authenticator `Conditional - credential`
|
|
|
|
The *Conditional - credential* is a new authenticator that checks if a specific credential type has been used (or not used) during the authentication process. This condition is related to the *Passkeys* feature. It is added by {project_name} to the default *browser* flow to skip 2FA in case a passkey was used to log in as the primary credential.
|
|
|
|
For more information about conditional flows, see link:{adminguide_link}#conditions-in-conditional-flows[Conditions in conditional flows].
|
|
|
|
= DPoP is now supported
|
|
|
|
{project_name} has support for OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP), which was a preview feature since {project_name} 23. Also, the supported version includes some improvements and minor capabilities of the DPoP feature such as the following:
|
|
|
|
* Possibility to make just refresh tokens of a public client to be DPoP bound and omit the binding of an access tokens
|
|
* All {project_name} endpoints that are secured by bearer token can now handle DPoP tokens. This includes for example admin REST API and account REST API
|
|
* Possibility to require the `dpop_jkt` parameter in the OIDC authentication request
|
|
|
|
ifeval::[{project_community}==true]
|
|
Thanks to
|
|
https://github.com/tnorimat[Takashi Norimatsu] and https://github.com/dteleguin[Dmitry Telegin] for their contributions to the DPoP feature.
|
|
endif::[]
|
|
|
|
For more information, see the link:{adminguide_link}#_dpop-bound-tokens[DPoP section] in the documentation.
|
|
|
|
= FAPI 2 Final support
|
|
|
|
{project_name} has support for the latest versions of FAPI 2 specifications. Specification *FAPI 2.0 security profile* is already promoted to Final and {project_name} supports it.
|
|
Specification *FAPI 2.0 Message Signing* was not yet promoted at this time, but the latest draft is expected to be promoted to the Final version soon. {project_name} client policies support
|
|
the final versions and corresponding client profiles for FAPI 2 are passing the FAPI conformance test suite.
|
|
|
|
Apart from some very minor polishing of existing policies, {project_name} has new client profiles (`fapi-2-dpop-security-profile` and `fapi-2-dpop-message-signing`) for the clients that use DPoP and are intended to be FAPI 2 compliant.
|
|
|
|
ifeval::[{project_community}==true]
|
|
Thank you to https://github.com/tnorimat[Takashi Norimatsu] for contributing this.
|
|
endif::[]
|
|
|
|
For more details, see the link:{securing_apps_base_link}/oidc-layers#_fapi-support[{securing_apps_name}].
|
|
|
|
= Option to force management interface to use HTTP
|
|
|
|
A new option, `http-management-scheme`, may be set to `http` to force the management interface to use HTTP rather than inheriting the HTTPS settings of the main interface.
|
|
|
|
= Option to expose health endpoints on the main HTTP(S) port
|
|
|
|
With `health-enabled` set to true, you may set the `http-management-health-enabled` to `false` to indicate that health endpoints should be exposed on the main HTTP(s) port instead of the
|
|
management port. When this option is `false` you should block unwanted external traffic to `/health` at your proxy.
|
|
|
|
= Additional context information for log messages (preview)
|
|
|
|
You can now add context information via the mapped diagnostic context (MDC) to each log message like the realm or the client that initiated the request.
|
|
This helps you to track down a warning or error message in the log to a specific caller or environment
|
|
ifeval::[{project_community}==true]
|
|
Thank you to https://github.com/eicki[@eicki] for contributing this.
|
|
endif::[]
|
|
|
|
For more details on this opt-in feature, see https://www.keycloak.org/server/logging[Configuring logging].
|
|
|
|
= Ability to specify a `tlsSecret` on the Keycloak CR `ingress` spec
|
|
|
|
To support basic TLS termination (edge) deployments by the operator, you may now set the Keycloak CR `spec.ingress.tlsSecret` field to a TLS Secret name in the namespace.
|
|
|
|
= HTTP access logging of incoming HTTP requests
|
|
|
|
{project_name} supports HTTP access logging to record details of incoming HTTP requests.
|
|
While access logs are often used for debugging and traffic analysis, they are also important for security auditing and compliance monitoring.
|
|
|
|
For more information, see https://www.keycloak.org/server/logging[Configuring logging].
|
|
|
|
== Possibility to hide identity providers from the Account Console
|
|
|
|
You can now control which identity providers appear in the Account Console based on different options using
|
|
the `Show in Account console` setting. You can choose to show only those linked with a user or hide them completely.
|
|
|
|
For more information, see link:{adminguide_link}#_general-idp-config[General configuration].
|
|
|
|
= Email domain for organizations is now optional
|
|
|
|
In earlier versions, each organization required at least one email domain, which was a limitation for some scenarios.
|
|
Starting with this release, an email domain is optional.
|
|
ifeval::[{project_community}==true]
|
|
Thank you to https://github.com/SferaDev[@SferaDev] for contributing this.
|
|
endif::[]
|
|
|
|
When no domain is specified, organization members will not be validated against domain restrictions during authentication and profile validation.
|
|
|
|
= Enhancements for single-cluster and multi-cluster setups
|
|
|
|
This release renamed multi-site to multi-cluster.
|
|
The updated documentation describes
|
|
how {project_name} clusters can be optionally distributed across multiple availability-zones within a region for increased availability.
|
|
The {project_name} Operator now deploys {project_name} across multiple availability zones within a Kubernetes cluster by default. {project_name} also detects split-brains within a cluster.
|
|
|
|
This change should provide better availability for users who are running {project_name} in Kubernetes clusters that span multiple availability zones.
|
|
|
|
ifeval::[{project_community}==true]
|
|
= Translations managed by Weblate
|
|
|
|
The {project_name} distribution now includes 35 community translations. With Kazakh, Azerbaijani and Slovenian added in this release.
|
|
Community volunteers now maintain some of the translations in https://hosted.weblate.org/projects/keycloak/[Weblate] to keep them up to date.
|
|
|
|
If you want to volunteer to maintain an existing or a new translation via Weblate, you can find the necessary steps in the https://github.com/keycloak/keycloak/blob/main/docs/translation.md[translation guidelines].
|
|
endif::[]
|
|
|
|
= Enforce set up of recovery codes after setting up OTP
|
|
|
|
If you have enabled OTPs and recovery codes as a second factor for authentication, you can configure the OTP required action to ask users to set up recovery codes once they set up an OTP.
|
|
ifeval::[{project_community}==true]
|
|
Thank you to https://github.com/dasniko[@dasniko] for contributing this.
|
|
endif::[]
|
|
|
|
= Supported OAuth standards listed on one page
|
|
|
|
A new guide exists with a list of https://www.keycloak.org/securing-apps/specifications[all implemented OpenID Connect related specifications].
|
|
ifeval::[{project_community}==true]
|
|
Thank you to https://github.com/tnorimat[@tnorimat] for contributing this.
|
|
endif::[]
|
|
|
|
= Automatic certificate management for SAML clients
|
|
|
|
The SAML clients can now be configured to automatically download the signing and encrypting certificates from the SP entity metadata descriptor endpoint. In order to use this new feature, in the client *Settings* tab, section *Signature and Encryption*, configure the *Metadata descriptor URL* option (the URL where the SP metadata information with the certificates is published) and activate *Use metadata descriptor URL*. The certificates will be automatically downloaded and cached in the `public-key-storage` SPI from that URL.
|
|
|
|
For more information, see link:{adminguide_link}#_client-saml-configuration[Creating a SAML client] in the {adminguide_name}.
|
|
|
|
= Operator creates a ServiceMonitor automatically
|
|
|
|
The Operator now provisions a `ServiceMonitor` for the management endpoint if metrics are enabled and the
|
|
`monitoring.coreos.com/v1:ServiceMonitor` Custom Resource Definition is present on the Kubernetes cluster. The
|
|
specification of the `ServiceMonitor` takes into account the various management endpoint configurations, to ensure that
|
|
metrics can be scraped without any additional configuration. If you do not want a `ServiceMonitor` to be created, you can disable
|
|
this by setting `spec.serviceMonitor.enabled: false`. For more details, see the link:{operatorguide_link}[{operatorguide_name}].
|
|
|
|
== {project_name} automatically creates the necessary caches on the first startup if they do not exist
|
|
|
|
You no longer need to manually create caches in your external Infinispan cluster.
|
|
|
|
When using the `multi-site` or `clusterless` features, {project_name} now automatically creates the necessary caches during startup if they do not already exist on the Infinispan server.
|
|
|
|
Any existing caches, manually created before {project_name} startup, will be preserved, and their configuration will not be modified.
|
|
|
|
For high availability, you can now easily configure cross-site replication.
|
|
Simply set the backup site name (e.g., availability zone) using the following option:
|
|
|
|
[source,bash]
|
|
----
|
|
--cache-remote-backup-sites=<name>
|
|
----
|
|
|
|
When this option is set, Infinispan will automatically replicate the cache data to the specified location.
|