Based on the other feedback and the Spring way of providing as many configuration options as possible, I think we should refactor AdapterDeploymentContextBean.
However, I rather like the way Spring that divides behavior up into an interface and multiple implementations. I think we should:
1. Refactor the current AdapterDeploymentContextBean to be an interface and maybe rename it AdapterDeploymentContextFactory.
2. Split the current implementation into:
a. ClasspathAdapterDeploymentContextFactory > loads from class path
b. WebApplicationAdapterDeploymentContextFactory > loads from WEB-INF
c. JndiAdapterDeploymentContextFactory > load from JNDI
3. The above implementations should extend AbtractAdapterDeploymentContextFactory with something like:
protected loadKeycloakDeployment(Resource resource) {
return KeycloakDeploymentBuilder.build(resource.getInputStream());
}
That would allow anyone to provide a custom AdapterDeploymentContextFactory to load the keycloak.json from “anywhere."
What do you think? Since we’re refactoring, I’d also like to take into account design multi-tentant support. I think this approach is flexible enough to add that in the future.
If we agree this is a good approach you want to take a stab at it Thomas or should I?
Best,
Scott
Scott Rossillo
Smartling | Senior Software Engineer
Hi!
We have written a custom subclass of org.keycloak.adapters.springsecurity.AdapterDeploymentContextBean to enable custom location for keycloak.json. The use of custom location is optional and defaults to the standard /WEB-INF/keycloak.json.
Our use case is that for developers we have a default keycloak.json included in the application. In production, however, we override the default by using a file that is external to the application. The location of the file is specified in JNDI settings and injected to our subclass with the help of Spring.
What do you think would such an extension to AdapterDeploymentContextBean be of general use? I'd be happy to merge our subclass to AdapterDeploymentContextBean and submit a pull request.
Best regards,
Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev