I’m Lama, a Software Engineer with roughly 2 years of experience with Keycloak as a user and developer extending its capabilities by adding custom made extensions and modifying the core components.
In my experience with Keycloak Server I noticed that we can enhance the keycloak’s developer experience by adding a custom cli tool to (install/uninstall/deploy/undeploy) a third party extension using only the extension GitHub’s url instead of making the user doing it manually by downloading the repo, building it, move it the desired directory in our case which is providers directory. I already did some work on the cli tool here and used Golang for it. And I would like your advice if already someone did something similar like this so I can drop this project and if not you can adopt this cli tool as part of Keycloak’s umprealla instead of me. If you are ok with this project please let me know because it would be fantastic on my resume to work with talented people like you from keycloak.
Feature requests, especially if you want feedback from the Keycloak Devs are better located in a GitHub discussion. This is mostly a community forum with little to no input from the dev team.
For the feature itself I have some concerns, as there are quite a few moving parts. Some extensions use maven, others use gradle, others are multi-module projects with different build requirements or asset paths.
Some allow to specify the target Keycloak version as build property, others don’t.
Some shared standard or conventions would be necessary to make this work across several extensions.
Another issue is the requirement of a Java compiler in the runtime environment, which is probably not desirable.
Personally I usually avoid this issue by using multi-staged docker builds with separate build stages for each plugin.
I think something like this is a really good idea. Keep in mind that there are a variety of ways that people build and package Keycloak. It is becoming increasingly more common since the Quarkus distribution to create an optimized Docker image that runs the build step to optimize startup time. In that case, it would be useful to have a tool that output the versions of the extensions you could use, which a script could use to download and put the jars in the right place before the build step.
We’ve built, used, forked, updated, etc. lots of extensions, and the core problems are:
Understanding if an extension works with the Keycloak version we’re targeting. And, if so, where’s the jar for that version?
Keeping the extensions updated as issues are found/fixed and as we update the Keycloak version.
Knowing about any dependencies (e.g. jars, --spi-* flags that have to be set, other configuration, etc.)
@thomasdarimont and I had a quick discussion back at Keycloak Dev Day about the idea of a “Keycloak Extension Repository”, which could just start with a simple manifest that could be published for an extension, and collected for use by a tool like this. This would give extension developers the ability to express compatibility and dependency information. It would also collect metadata about extensions in a single place so that a website for extension discovery could be generated.
Anyway, great work so far, but I really think that getting clean, updated data about extensions should be the highest priority.
