Skip to content

Instantly share code, notes, and snippets.

@snicoll
Last active April 14, 2017 08:36
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save snicoll/0f3d2d7ee0fd12336f82b3baa91fd06e to your computer and use it in GitHub Desktop.
Save snicoll/0f3d2d7ee0fd12336f82b3baa91fd06e to your computer and use it in GitHub Desktop.
Keycloack Auto-configuration brain dump

Here is a proposal based on a quick overview of the code with, I hope, enough explanations so that it makes sense.

Spring Boot adapter

The keycloak-spring-boot-adapter is the code that holds the auto-configuration as far as I can see so it would be nicer to name it that way. I'd suggest keycloack-spring-boot-autoconfigure but it's really not important.

KeycloakSpringBootConfiguration should be renamed to KeycloakAutoConfiguration

What is important is that rather than taking dependencies and patching them in a shaded jar at that level, you should take that decision in the starter, leaving all that business out of the autoconfigure module. Here is what I suggests:

  1. The web container adapter must be with optional scope
  2. All the provided-scoped dependencies are wrong. These are not provided, these "might" be available at runtime and the auto-configuration will react to it

Questions:

  • What is keycloak-undertow-adapter-spi and why is it explicitely defined there as provided? Who's providing it?

Web Container adapter

I'd create a separate project whose purpose is to contain the various servlet container integrations. It can be named whatever you want but something like keycloack-container-adapters might work. Just depend on the adapters you want to ship, mark them provided and build a jar that contains them. This module shouldn't have any code in it.

Spring Security adapter

Now that I see keycloak-spring-security-adapter, I understand the problem. You really have two integrations. One that is purely based on spring security (and doesn't seem to use spring boot at all) and one thing that bootstraps everything.

It's totally unclear to me how you auto-configure the security part of Keycloack but, looking at the dependencies, it looks pretty obvious that you can pretend spring-security is an optional dep. Not only you'll break existing use cases but there are much more dependencies that are required there.

So you should probably keep what you have on master at the moment

Starter

So keycloack-default-spring-boot-starter should do the following IMO bring keycloack-spring-boot-autoconfigure, keycloack-container-adapters and keycloack-spring-security-adapter in compile scope.

Use cases that should work:

  • If you add spring-boot-starter-web and any of the supporter containers, it should work with the Spring Security integration
  • If you exclude keycloack-spring-security-adapter then you should have the "Keycloack without Spring Security" use case
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment