Repository navigation
Redis #48577
Replies: 1 comment
|
We've been working on a Redis cache backend for Keycloak for a while (it started with a specific high-availability use case and multi-region requests from some customers), and we've packaged it as Locke, an Apache 2.0 distribution of Keycloak (same idea as RHBK), not an extension, since the current cache SPI doesn't cleanly support swapping the backend that way. It ships with both cache backends and the operator chooses at boot with If it's something others in the community have needed, feedback and critique is very welcome. It's complementary to Phase Two's work, not a replacement: they put sessions on Redis as an extension; Locke takes the whole cache layer off JGroups as a distribution, because the cache mechanism isn't cleanly swappable via the current SPI. Repo: https://github.com/sky-cloak/locke (architecture and benchmark are linked in the README) |
Uh oh!
There was an error while loading. Please reload this page.
Since Keycloak was created many years ago there has been a limited number of requests for adding support for Redis to Keycloak. Most of these requests have been motivated by problems with the existing caches in Keycloak. We have continued to improve on caches in Keycloak, fixing a number of issues over the years, but also general improvements and simplifying the configuration and management of caches.
As a collective decision by all Keycloak maintainers we have agreed to not add support for Redis, instead focusing on continuing to improve our current caching strategy. Our vision for Keycloak is that caches should be managed by Keycloak, and not be an additional dependency that has to be configured and managed. In this regard we are continuously making it easier to manage caches in Keycloak, without requiring deep knowledge of Infinispan. Some great examples in this regard have been the switch to a single ping mechanism and automatic configuration of encryption of cluster communication.
At the same time we appreciate that there may not be a single approach for everyone, which is why we would like to encourage the community to build open extensions and have a vision for a wider ecosystem around extensions.
We do encourage everyone that is interested in having support for Redis to read our vision for Keycloak caches and to provide us feedback with what challenges you have. The more feedback we receive the better we can understand the challenges you are facing, resulting in better and more targeted improvements to Keycloak caches in the future.
All reactions