Repository navigation
Replies: 4 comments
One of the nice things about the Wildfly version of Keycloak was the ability to package everything as an EAR file, when you had dependencies you wanted to package. With the change to Quarkus and the fact that there is no longer an isolated classloader, there is always the question of how an extension should specify and package its dependencies. Sometimes we take the path of making a fat jar with shaded inclusion of dependencies. Other times we just specify jars and versions that must be packaged with the extension. Either one of these introduces the problem of conflict with dependencies of another extension. This is a long way of saying that some standardization and specification would be welcome in packaging extensions. |
|
Hey community, The core ideas are as follows:
Please note that the current live deployment at kcer.dev still uses an older Docker-based approach involving pre-built provider images per extension. The Maven-based installation model described above is the new direction and is actively being developed. This approach was discussed at the Keycloak Dev Day in Germany, where most attendees seemed to prefer it. This project is a proof of concept, so please do not use it in production. It may be completely replaced in the future. We would be happy to share more information and discuss how any of this could align with your vision. As a community project, this initiative requires the involvement of its members to shape and develop it. Please get in touch 😄 |
|
I built a lot of extensions for my customers in the public sector, and one of them is already open sourcing them all under Apache 2.0 license: https://github.com/ba-itsys Keycloak's extensibility is a major factor why it is used there, because it enables extensive customization and features that other IAM solutions do not support. The new Keycloak Testframework already eliminated a lot of pain points here, in that it allows to easily test those extensions as part of Keycloak in automated integration tests. For the Keycloak-team, this could also be a way to have experimental stuff outside of Core Keycloak and only integrate those extensions, that are very popular and also mature/production-hardened. So it would provide a natural way from "experiments" to "mature and useful new core features". |
|
At Keymate, we build product capabilities on top of Keycloak through multiple cooperating extensions. Their provider contracts and shared dependencies matter to us as much as each extension's individual behaviour. The KCER direction described in this discussion for packaging, dependency resolution and version compatibility is useful. One additional requirement from our experience is verifying a cooperating set of extensions as one assembled system, rather than proving only that each extension works independently with a Keycloak version. We use container-based integration tests that load multiple provider JARs. Extension tooling should support complete workflows across those extensions, with the result tied to the exact Keycloak, extension, provider-contract and shared-dependency versions installed together. For example, consider one extension accepting an administrative role update and another applying it through Keycloak's native model. A useful test follows the update through both providers, reads the native state independently, and checks the effective roles in a newly issued token. It also verifies removal. Testing each extension with a mocked peer would not establish that the assembled workflow works. Requirements we would find useful are:
Can the proposed testing and registry approach model compatibility for a cooperating extension set, in addition to individual extensions? Is this discussion the preferred place to submit further generic test specifications? |
Uh oh!
There was an error while loading. Please reload this page.
Keycloak has always been intended as a ready-to-use solution, not a framework, while at the same time there is no such thing as a single solution for everyone. As such from the early days Keycloak was built to be highly customizable with an ever growing list of extension points.
As the community is building and innovating on top of Keycloak there has also been a number of cases where contributions to Keycloak has been slowed down due to the capacity of the Keycloak maintainers team. Or, where we simply have not had enough capacity to add features the community is requesting.
Some highlights of extensions and tools for Keycloak includes:
There are many more, check out the list of extensions on keycloak.org for the full list.
Our vision for the future is to build a larger ecosystem of open extensions and tools for Keycloak, including a route to extensions eventually becoming official extensions in some shape, or even added to Keycloak directly.
Part of this vision includes a better registry of extensions that not only simply lists the extensions, but provide more details including:
We also want to make it easier to build and publish extensions, as well as simpler to install extensions, including:
We would encourage everyone that wants to build and innovate on top of Keycloak to continue building, provide us feedback with your struggles, and most importantly build a community around your extension by advertising your extension, being open to contributions, joining forces, and last but not least share the source through an open source license. In this regard we strongly encourage Apache License 2.0 as not only do we think this is a great license, but using the same license as Keycloak significantly simplifies things if you eventually want to have your extension be part of Keycloak.
All reactions