TideCloak 0.10.0
An important upgrade to underlying Keycloak and security/performance improvement.
Highlights:
- Keycloak upgrade to 26.2.5
- First rollout of a decentralized database migration process.
- Tide themeing for TideCloak.
Cybersecurity Fabric changes
ORK shared database indexing
Increase use of Tide Cybersecurity Fabric, together with load testing experimentation has revealed several performance bottlenecks that were addressed this release. The most critical performance bottleneck was found to be an inefficient database query in one of the fabric's core distributed database tables linking many key entires with many ORK nodes hosting it. A more efficient indexing and retrival mechanism was implemented and fixed that issue.
Keycloak 26.2.5 release notes
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 Token exchange specification. It does not yet cover use cases related to identity brokering or subject impersonation.
Guides for metrics and Grafana dashboards
In addition to the list of useful metric names the Observability guides category now also contains a guide on how to display these metrics in Grafana. 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, TideCloak 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.
Additional Tide IdP Themeing support
Additional default use cases are now covered by the basic themeing customization options available under the Tide IdP, such as the user onboarding, single-sign-on logout and new user invite use cases.
Rolling updates for optimized and customized code images
When using an optimized or customized image, the TideCloak Operator can now perform a rolling update for a new image if the old and the new image contain the same version of TideCloak. 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. Read the section Managing Rolling Updates in the Keycloak Operator Advanced Configuration guide for more details on this functionality.
Metrics on user activities
Event metrics provide admins an aggregated view of the different user activities in a TideCloak instance. For now, only metrics for user events are captured. For example, you can monitor the number of logins, login failures, or token refreshes performed. For more information, see Monitoring user activities with event metrics.
Additional query parameters in Admin Events API
The Admin Events API now supports filtering for events based on Epoch 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
.
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 TideCloak’s observability story and centralized logging.
For more details, see the Logging guide.
Operator creates NetworkPolicies to restrict traffic
The TideCloak Operator now creates by default a NetworkPolicy to restrict traffic to internal ports used for TideCloak’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 Operator Advanced configuration.
JWT Client authentication aligned with the latest OIDC specification
The latest version of the OpenID Connect Core Specification tightened the rules for audience validation in JWT client assertions for the Client Authentication methods private_key_jwt
and client_secret_jwt
. TideCloak now enforces by default that there is single audience in the JWT token used for client authentication.
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.
In order to check if a credential is local - managed by TideCloak - 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 TideCloak outgoing 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.
Enhancements:
- Upgrade to Quarkus 3.15.4
- Possibility to log details and representation to the jboss-logging listener
- Prevent Email server credentials to be harvested through host/port manipulation
- Sessions from Infinispan are be mapped lazily for the Admin UI
- Infinispan list of all sessions remove old client sessions faster
- When logging in, relevant OIDC client sessions are reloaded only when needed