Repository navigation
Replies: 5 comments
|
I'm a relative newcomer to Keycloak myself. We've been using it internally in our company for some time and now we're about to introduce a new version of our user-facing platform that will be using Keycloak for authentication. While I have become a fan of the Keycloak functionality and extensibility, I have come to dread upgrades and lack of visibility to session management. The documentation out there regarding integration with Infinispan and configuration of caching is indeed fragmented and sometimes too sketchy for my taste. For session storage in particular I feel I'm flying blind in terms of monitoring. Regarding the ever-closing go-live of our new platform, I find myself sometimes pondering unrealistic and potentially dangerous solutions such as never upgra 8000 ding Keycloak once it goes live, something that I'm not fond of since I favor staying close to the latest version as much as possible. So I very much appreciate this conversation starter. |
|
There has been some documentation released about multi-site deployments following the release of Additionally, I found a guide regarding setting up Keycloak with external Infinispan, using the operators. However @nickntg as you said, it's somewhat "sketchy" and not particularly complete. https://www.keycloak.org/high-availability/connect-keycloak-to-external-infinispan It's great to see that there is "official" documentation and effort going into reliability, but the quality that both of these documentation sets seems to have is making Keycloak more complex to operate reliably rather than less. I guess the distinction I'm after is this: It was already true if you have a dedicated, well-informed team, and lots of time/resources to plan, to set up and operate Keycloak in a way that mitigates the problems listed above. I'm interested in understanding if there are ways that Keycloak can be updated so that a smaller operation that doesn't have expertise can set it up and operate it in a way that doesn't lose sessions, and doesn't tempt "unrealistic and potentially dangerous solutions such as never upgrading Keycloak once it goes live" (love that way of describing the problem, btw). Multi-site deployments are great if you're a Fortune 500, have a large budget, great observability, and a team dedicated to ops, but isn't realistic otherwise. I think these problems can be solved in a way that both reduces complexity and increases reliability. |
|
Hey, we are the authors of https://github.com/opdt/keycloak-cassandra-extension and would like to give our cents to this topic. We are one of the biggest federal agencies in Europe and are currently migrating our internal IAM-solution from a proprietary one to Keycloak. We think that integrating Infinispan this deeply into Keycloak is a problem and alternative caching solutions (including no caching, which is often good enough) would simplify the Keycloak setup substantially for a lot of people.
Note that the choice of technology doesnt matter here. Others might find a solution like lets say Redis or even a fast SQL-database for caching a better option for their environment. Keeping the |
|
Looks to see some interesting progress here. Keycloak team have implemented persistent User Sessions in Also, we've been working on a full replacement for anything that was stored in Infinispan: https://github.com/xgp/keycloak-jpa-cache |
|
As one step towards more seamless upgrades, there is an effort in #28271 to allow storing user session (aka information about currently logged in users) in the database to make that information survive restarts and upgrades. Please join the discussion over there if you are interested in persistent user sessions, and subscribe there to get updates once the features appear in the main branch. All other topics not related to persistent users sessions should still be discussed here. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
(FYI I tried searching through issues and discussions for this topic, and I apologize if I missed something)
After watching the Keycloak presentations at Kubecon this week, I've been reminded of the amazing progress by the team and outside contributors. There have been substantial changes driven by user request, and the regular pace of releases has been great. 🎉
Problem
Since the announcement that the Map Store project would be removed and abandoned (https://www.keycloak.org/2023/10/map-store-removal.html), I've been curious about the future of some of its goals.
Specifically, in hundreds of customer calls, the one thing that causes people's jaw to hit the floor is when I tell them that Keycloak upgrades may not be seamless (e.g. without downtime), and there is a risk of losing sessions. We've found that many companies abandon plans to use Keycloak at this point, even if they were 99% sold on every other aspect. In many ways, it's the only feature that matters, as Keycloak provides feature parity (and in many cases superior functionality) to most other tools it is evaluated against.
Questions
Previously to abandoning the Map Store, my assumption had been that this was a significant priority of that project. However, now that it has been stopped, I didn't see any mention of seamless upgrades as a priority for the future. In the announcement, there is mention of "cross-DC" features. Does this include seamless upgrades? If not, is there a roadmap somewhere for the feature?
It's always tough when a significant, time consuming project gets scrapped. However, one thing I've seen (and failed to learn) over and over in my career is that big, "boil the ocean", second-system projects tend to fail because of inflated expectations and scope. It becomes impossible to decompose atoms of functionality and effectively prioritize. While not always possible, incremental development has the ability to limit scope to core needs, and manage expectations through a continuous improvement and feedback cycle.
Is it possible to create a simple scope for the seamless upgrades that would lend itself to incremental development? This also has the potential to engage the support and contribution of the community, as it would be a project that doesn't require massive surgery to Keycloak's internals.
Notes for consideration
Current barriers to seamless upgrades:
(I'm aware that some installations are using external infinispan to solve 3 and 4 (we do this for our hosting and several customers), but we've found that getting this running is error-prone, tends to require a lot of maintenance and changes betwee versions, and not documented well (or really at all). Furthermore, it does not succeed in solving 2 for all upgrades, and leaves 1 untouched.)
Current projects to address seamless upgrades:
What am I missing? What did I get wrong?
Next steps
I'd like to use this discussion to accumulate more information about this topic, as I know it's important to many users, but that information and discussion is currently fragmented.
All reactions