Repository navigation
Replies: 6 comments 4 replies
|
In general I think the API surface for extensions should only be interfaces, no class, static methods, utility classes, or anything like that |
|
Fyi, I'm offering a custom public SPI BOM, where I align the dependencies with the major and minor Keycloak runtime libs: https://github.com/dasniko/keycloak-spi-bom It's not only me using this BOM, there are several other projects using it. So, there is demand among the developers. |
|
I have been curious about how to build Keycloak extensions for a long time... When I started, I would use the pom.xml and general structure from https://github.com/dasniko/keycloak-user-spi-demo as the base for my extension. I had some difficulties upgrading the extension over time to keep up with Keycloak upgrades, but I managed overall until I was trying to do an extension for 26.7.3. I'm not much of a Java dev, so I scratched my head a bit and then looked at https://github.com/dasniko/keycloak-extensions-demo/tree/main/flintstones-userprovider but it seemed overly complicated for what I was trying to achieve, so I looked elsewhere. Eventually, I found https://github.com/keycloak/keycloak-quickstarts/tree/main/extension/user-storage-simple but it wouldn't even build. But I started hacking away at the testing in pom.xml and then I could get it to build. Started comparing with my original extension based off keycloak-user-spi-demo and then looked at the user-storage-jpa quickstart. |
|
I'm still in the process of whittling away at unnecessary dependencies and the like, which has gotten me to a fairly lean pom.xml which is nice. I'm going to see just how minimal I can make it while still having the necessary extension functionality. I'm a bit confused by the difference between https://mvnrepository.com/artifact/org.keycloak.bom/keycloak-spi-bom and https://github.com/dasniko/keycloak-spi-bom/blob/main/pom.xml At the moment, https://mvnrepository.com/artifact/org.keycloak.bom/keycloak-spi-bom seems like all I'd need. I'm just in the process now of trying to examine that to see what I really do need in my dependencies... |
|
Would I be right in assuming that keycloak-spi-bom is basically a sort of metapackage that specifies keycloak-core and keycloak-server-spi? Would it be useful to have a keycloak-spi-storage-bom which specifies keycloak-core, keycloak-server-spi, and keycloak-model-storage? |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
When it comes to building Keycloak extensions it can be difficult to know what is supported and what is not.
In general if the
Providerinterface is inserver-spian extension can call the provider, and if theProviderFactoryinterface is inserver-spi-privateit is supported to implement a custom provider. In many cases you're not really supposed to call providers directly, but rather through managers. Where managers don't really have a standard way to discover them. Some are available on KeycloakSession while some are not. Maybe there's also a need for a public Provider interface, and a private Provider interface?However, which of all the other modules are supported APIs, and which are not? There's a lot of utility classes around, and wrappers like
TokenManagerfor instance. These are hard to find, and often the APIs are not great at all.Then comes the next question around dependencies? Should one add custom dependencies? If so how do you make sure they don't conflict with the dependency versions from the distribution? There's no really easy way to include all dependencies for Keycloak into your extension. Did anyone say a BOM?
One thing I had in mind is that we would create a new KeycloakSession interface or something that contains supported APIs to build extensions on top of. And essentially anything you can do through KeycloakSession is supported, but anything else is not supported. Want to decode a JWT for instance? Well, then call
KeycloakSession.apis().jwt().decodeToken(...)or something along those lines. Everything would be discoverable through theKeycloakSession, and there would not be any static utilities, managers, or anything else dangling around.The other thing would be to add an BOM with supported dependencies to build an extension on top of. This would be a subset of the dependencies in the distribution, and only contain dependencies you should be calling (for example not Quarkus APIs directly).
A final thing to note here is that some things in the Keycloak code base is incredibly complex to deal with as the API is not great. For example doing something as basic as generating or validating a JWS is really messy and complex.
All reactions