We are looking to replace our internal IDP. We are evaluating leveraging KeyCloak. Based on what I’m seeing, it seems as if Keycloak.x might be the direction we should head. We’re pretty much going to need to implement a User Storage SPI. I’ve been digesting this chunk of documentation:
Is this exactly how we will implement User Storage SPI using KeyCloak.x/quarkus? I’m seeing references to Wildfly in this document, hence the question.
Keycloak-X is not yet fully supported, it’s still preview.
Once it is supported, I guess the docs will reflect it.
See Keycloak - Blog - Keycloak.X Update for more about the roadmap.
But I don’t see big issues here. My tests and demo user providers all running with “legacy” (Wildfly-based) Keycloak and Keycloak-X (Quarkus-based). No code changes needed so far.
Why tear it down?
If you are fine with running a tool in current state, ok.
I wouldn’t prefer it to use it in production, but for testing and evaluating, why not!? It’s not long until Keycloak 17…
well, I need to write a User Storage SPI that works with keycloak.x. Are you saying use the doc I referenced above, create a JAR and it should just work with keycloak.x?
I’m saying that it works in my tests and demos, nothing more, nothing less.
Keycloak is not changing all of the things and how it works, mostly it’s the underlying server architecture, how it will be deployed and configured. But I cannot give you any guarantees.
Write your SPI, test it with current Keycloak-X, when v16 is out, test it again with v16, then, same with 17, which will be the first “release” for X.
Niko,
We’ve rolled forward a bit on this one. I’ve had one of my devs dig in on this one and he’s getting an error when attempting to run kc.sh config with a JAR file in place. This is his post: