.svg)
.svg)
On October, Keycloak unveiled its 26th iteration, which is now available on Cloud-IAM deployments. In this article, we will present the main new features of version 26, perform a performance test under the same conditions as the one we carried out for the release of version 25, and compare performance.
Previewed in version 25, persistent-user-session is enabled by default in version 26. Sessions are stored in the database, which means that when you migrate from version 25 to 26, you will no longer lose your sessions. Since version 25, we've already been storing sessions in the database during migrations; now this behavior is the default.
This behavior may have an impact on your deployment, let’s do some tests on a Cloud-IAM deployment on Keycloak v26 on the response time and CPU usage.
As we’ve done in our previous article for the v25 release, we conducted a series of performance tests, with the same parameters and configuration. Below are the results.
We tested the creation of 1000 users without concurrency. In the previous version, this process, with the session stored in the database, took around 8 minutes.
With Keycloak v26, the process also took 8 minutes, as the session-in-database feature, previously in preview, is now fully integrated into the platform.
During this phase, the average response time was about 200ms.
We tested Keycloak v25 in a high-activity cluster using the aforementioned scenarios. The key metrics observed on both instances include CPU usage and response times:
First of all we made a 50 rps activity to match the performance tests we did for the v25 release.
These tests show us that this version is more performant than the v25. The response time is decent (average of 200ms) and the two nodes cluster used for these tests has a great behavior on the CPU usage.
Let’s try now to expose the deployment to a higher activity (70 requests per seconds).
.png)
The deployment performed well, even with 70 requests per second, the cluster managed well the requests sent as the repartition highlight that the CPU usage is lower than 80% with a 130 ms response time. We are confident that upgrading to Keycloak v26 will not negatively impact your deployment's performance.
Already a Cloud-IAM customer ? Let us know if you want to update your deployment to the latest Keycloak version. Check first our documentation to be aware of all the prerequisites needed for this improvement and contact our support to perform this update.
OpenID for Verifiable Credential Issuance (OID4VCI) is still an experimental Keycloak feature, but has been implemented in this release.
The DPoP (OAuth 2.0 Demonstrating Proof-of-Possession) functionality has been enhanced. DPoP is now supported for all grant types, whereas in previous versions, it was only supported for the authorization_code grant type. The DPoP token type is also supported in the UserInfo endpoint.
Lightweight access tokens can now be used on the Administration REST API. The security-admin-console and admin-cli clients now use lightweight access tokens by default, so the “Always Use Lightweight Access Token” and “Full Scope Allowed” options are now enabled on these two clients. However, the behavior in the administration console should remain the same.
The user is automatically redirected to the path where Keycloak is hosted when the http-relative-path property is specified. This means that when the relative path is /auth, and the user accesses localhost:8080/, the page is redirected to localhost:8080/auth.
java-keystore key provider supports more algorithms and vault secretsjava-keystore key provider supports more algorithms and vault secrets
The java-keystor key provider can handle all Keycloak algorithms. In addition, the keystore and key secrets required to retrieve the current key from the store can be configured using the storage space. As a result, a Keycloak domain can externalize any key in the encrypted file without sensitive data being stored in the database.
Keycloak now supports the configuration of ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW or ECDH-ES+A256KW as encryption key management algorithms for customers. The ECDH-ES (Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static) specification introduces three new header parameters for JWT: epk, apu and apv. Currently, the Keycloak implementation only supports the mandatory epk parameter, while the other two (which are optional) are never added to the header.
In addition, a new key provider, ecdh-generated, is available for generating realm keys, and support for ECDH algorithms is added to the Java KeyStore provider.
Thanks to the introduction of the organization function, it should be possible to link different instances of the same social broker to different organizations.
When creating a social broker, you must now provide an alias and possibly a display name, as for any other broker.
There are now generalized events for updating (UPDATE_CREDENTIAL) and removing (REMOVE_CREDENTIAL) a credential. The credential type is described in the credential_type attribute of the events. The new event types are supported by the Email Event Listener.
The template.ftl file in the base/login and the keycloak.v2/login theme now allows to customize the footer of the login box. This can be used to show common links or include custom scripts at the end of the page.
The new footer.ftl template provides a content macro that is rendered at the bottom of the "login box".
Marshalling is the process of converting Java objects into bytes and sending them over the network between Keycloak servers. With Keycloak 26, the marshaling format from JBoss Marshalling to Infinispan Protostream has changed.
JBoss Marshalling and Infinispan Protostream are not compatible with each other, and incorrect use may result in data loss. Consequently, all caches are cleared when upgrading to this version.
Infinispan Protostream is based on Protocol Buffers (proto 3), which offers the advantage of upward/downward compatibility.
They are deleted directly from the database when a domain is deleted. Group events, such as the GroupRemovedEvent, are no longer triggered when a domain is deleted.
The realm representation no longer holds the list of identity providers, when they have many identity providers. However, they are still available from the realm representation when exporting a realm.
Features removed :
Options added :
Modifications :
