Keycloak.X Update

As mentioned previously a lot more attention will be put on your experience with Keycloak. With this in mind we have identified a few experiences that we believe cover a wide range of different use-cases:

We’re switching to Quarkus as the platform to build Keycloak. Compared to WildFly this gives faster startup-time and lower memory footprint. It also provides a much simpler approach to configuring Keycloak, with command-line arguments and environment variables instead of complicated XML files. Another great aspect of Quarkus is that it gives us a lot more control over what external libraries are included in the distribution, including faster upgrades of dependencies, which should significantly improve on situation around CVEs.

We’re doing a significant re-architecture of the storage layer as part of Keycloak.X to address a number of shortcomings that where discovered in the current architecture. Zero downtime upgrade, scalability, and availability will be key topics of this new architecture, as well as making it a lot easier to support additional storage types in the long run.

With the current approach to configuration in Keycloak creating a good experience around a container is problematic as the container has to convert from environment variables to complicated XML configuration files. With the work we’re doing around Quarkus configuring Keycloak with environment variables becomes a native thing, making it a lot simpler to provide a great container experience.

Similarly, the Operator can also be made simpler as it will be easier to configure Keycloak, as well as having better opinionated configuration from the base distribution, which trickles through from the Zip distribution, to the container, and finally to the Operator. To align the codebase more we’re also re-writing the Operator from scratch using the Java SDK and Quarkus.

Metrics, tracing, logging, and health-checks are all important aspect of a cloud native application. These are all important capabilities to manage and debug Keycloak in production, especially when running on Kubernetes or OpenShift.

In a GitOps or CI/CD environment it can be problematic to manage the runtime configuration within Keycloak. As all configuration such as realms and clients live in the database and can only be managed through REST APIs it is hard to reliably manage as part of a GitOps process.

Along with the storage re-architecture comes a very powerful capability that can federate configuration from multiple sources, and we plan to take advantage of this with a file-based store, where Keycloak can read more static/immutable configuration from the file-system (YAML of course), and combine this with dynamic/mutable configuration from the DB.

Further, this enables checking in your static configuration in a Git repository, and deploy it to your development, stage and production environments as needed.

Keycloak has a large number of extension points today, called SPIs. With Java (and in some cases JavaScript) it is possible to customize Keycloak with custom providers for these SPIs. Although, highly powerful and flexible, this is not ideal in a modern Kuberetes centric architecture. As the extensions are co-located with Keycloak it is harder to deploy, upgrade, and scale extensions. Extensions can also not be written in any language or framework making it more costly for non-Java developers to extend Keycloak.

With this in mind we are planning more focus on the ability to extend and integrate with Keycloak through remote extensions, and are looking at REST, gRPC, Knative, Kafka, etc. as vehicles to achieve this. In addition we would also like to get to a point where we can have a "headless" Keycloak allowing a frontend to be built in any way you want, which would bring a great addition to the current themes approach to customising the UI.

Last, but not least. We are also planning on ability to decompose Keycloak as well as bring better isolation on Keycloak’s code base and capabilities. We’re not planning to go full micro-service architecture here, but rather a sensible compromise allowing everything to run as a single process, with the ability to separate some parts of Keycloak into external services.