mirror of
https://github.com/keycloak/keycloak.git
synced 2026-01-10 15:32:05 -03:30
105 lines
7.6 KiB
Plaintext
105 lines
7.6 KiB
Plaintext
= Supported Standard Token Exchange
|
|
|
|
In this release, we added support for the Standard token exchange! The token exchange feature was in preview for a long time, so we are glad to finally support the standard token exchange.
|
|
For now, this is limited to exchanging the Internal token to internal token compliant with the https://datatracker.ietf.org/doc/html/rfc8693[Token exchange specification]. It does not yet cover use
|
|
cases related to identity brokering or subject impersonation. We hope to support even more token exchange use cases in subsequent releases.
|
|
|
|
For more details, see the link:{securing_apps_token_exchange_link}#_standard-token-exchange[Standard token exchange].
|
|
|
|
For information on how to upgrade from the legacy token exchange used in previous {project_name} versions, see the link:{upgradingguide_link}[{upgradingguide_name}].
|
|
|
|
= Guides for metrics and Grafana dashboards
|
|
|
|
In addition to the list of useful metric names link:{observablitycategory_link}[the Observability guides category] now also contains a guide on how to display these metrics in Grafana.
|
|
link:{grafanadashboards_link}[The guide] contains two dashboards.
|
|
|
|
* Keycloak troubleshooting dashboard - showing metrics related to service level indicators and troubleshooting.
|
|
* Keycloak capacity planning dashboard - showing metrics related to estimating the load handled by Keycloak.
|
|
|
|
= Zero-configuration secure cluster communication
|
|
|
|
For clustering multiple nodes, {project_name} uses distributed caches.
|
|
Starting with this release for all TCP-based transport stacks, the communication between the nodes is encrypted with TLS and secured with automatically generated ephemeral keys and certificates.
|
|
|
|
This strengthens a secure-by-default setup and minimizes the configuration steps of new setups.
|
|
|
|
For more information, check the link:https://www.keycloak.org/server/caching#_securing_transport_stacks[Securing Transport Stacks] in the distributed caches guide.
|
|
|
|
= Rolling updates for optimized and customized images
|
|
|
|
When using an optimized or customized image, the {project_name} Operator can now perform a rolling update for a new image if the old and the new image contain the same version of {project_name}.
|
|
This is helpful when you want to roll out, for example, an updated theme or provider without downtime.
|
|
|
|
To use the functionality in the Operator, enable the `Auto` update strategy and the {project_name} Operator will on image change briefly start up the old and the new image to determine if a rolling update without downtime is possible.
|
|
Read the section https://www.keycloak.org/operator/rolling-updates[Managing Rolling Updates] in the {project_name} Operator Advanced Configuration guide for more details on this functionality.
|
|
|
|
The checks to determine if a rolling update is possible are also available on the {project_name} command line so you can use them in your deployment pipeline. Continue reading in the https://www.keycloak.org/server/update-compatibility[Update Compatibility Tool] guide for more information about the functionality available on the command line.
|
|
|
|
= Additional query parameters in Admin Events API
|
|
|
|
The Admin Events API now supports filtering for events based on Epoc timestamps in addition to the previous
|
|
`yyyy-MM-dd` format. This provides more fine-grained control of the window of events to retrieve.
|
|
|
|
A `direction` query parameter was also added, allowing controlling the order of returned items as `asc` or
|
|
`desc`. In the past the events where always returned in `desc` order (most recent events first).
|
|
|
|
Finally, the returned event representations now also include the `id`, which provides a unique identifier for
|
|
an event.
|
|
|
|
= Logs support ECS format
|
|
|
|
All available log handlers now support *ECS* (Elastic Common Schema) JSON format.
|
|
It helps to improve {project_name}'s observability story and centralized logging.
|
|
|
|
For more details, see the https://www.keycloak.org/server/logging[Logging guide].
|
|
|
|
= New cache for CRLs loaded for the X.509 authenticator
|
|
|
|
Now the Certificate Revocation Lists (CRL), that are used to validate certificates in the X.509 authenticator, are cached inside a new infinispan cache called `crl`. Caching improves the validation performance and decreases the memory consumption because just one CRL is maintained per source.
|
|
|
|
Check the `crl-storage` section in the link:https://www.keycloak.org/server/all-provider-config[All provider configuration] {section} to know the options for the new cache provider.
|
|
|
|
= Operator creates NetworkPolicies to restrict traffic
|
|
|
|
The {project_name} Operator now creates by default a NetworkPolicy to restrict traffic to internal ports used for {project_name}'s distributed caches.
|
|
|
|
This strengthens a secure-by-default setup and minimizes the configuration steps of new setups.
|
|
|
|
You can restrict the access to the management and HTTP endpoints further using the Kubernetes NetworkPolicies rule syntax.
|
|
|
|
Read more about this in the https://www.keycloak.org/operator/advanced-configuration[Operator Advanced configuration].
|
|
|
|
= Option to reload trust and key material for the management interface
|
|
|
|
The `https-management-certificates-reload-period` option can be set to define the reloading period of key store, trust store, and certificate files referenced by `https-management-*` options for the management interface.
|
|
Use -1 to disable reloading. Defaults to `https-certificates-reload-period`, which defaults to 1h (one hour).
|
|
|
|
For more information, check the link:https://www.keycloak.org/server/management-interface#_tls_support[Configuring the Management Interface] guide.
|
|
|
|
= Dynamic Authentication Flow selection using Client Policies
|
|
|
|
Introduced the ability to dynamically select authentication flows based on conditions such as requested scopes, ACR (Authentication Context Class Reference) and others.
|
|
This can be achieved using link:{adminguide_link}#_client_policies[Client Policies] by combining the new `AuthenticationFlowSelectorExecutor` with conditions like the new `ACRCondition`. For more details, see the link:{adminguide_link}#_client-policy-auth-flow[{adminguide_name}].
|
|
|
|
= Federated credentials are available now when fetching user credentials
|
|
|
|
Until now, querying user credentials using the User API will not return credentials managed by user storage providers and, as a consequence,
|
|
prevent fetching additional metadata associated with federated credentials like the last time a credential was updated.
|
|
|
|
In this release, we are adding a new method `getCredentials(RealmModel, UserModel)` to the `org.keycloak.credential.CredentialInputUpdater` interface so that
|
|
user storage providers can return the credentials they manage for a specific user in a realm. By doing this, user storage providers can indicate
|
|
whether the credential is linked to it as well as provide additional metadata so that additional information can be shown when managing users through the administration console.
|
|
|
|
For LDAP, it should be possible now to see the last time the password was updated based on the standard `pwdChangedTime` attribute or, if
|
|
using Microsoft AD, based on the `pwdLastSet` attribute.
|
|
|
|
In order to check if a credential is local - managed by {project_name} - or federated, you can check the `federationLink` property available from both
|
|
`CredentialRepresentation` and `CredentialModel` types. If set, the `federationLink` property holds the UUID of the component model associated with a given
|
|
user storage provider.
|
|
|
|
= Token based authentication for SMTP (XOAUTH2)
|
|
|
|
The Keycloak outgoing link:{adminguide_email_name}[SMTP mail configuration] now supports token authentication (XOAUTH2).
|
|
Many service providers (Microsoft, Google) are moving towards SMTP OAuth authentication and end the support for basic authentication.
|
|
The token is gathered using Client Credentials Grant.
|