And yes of course you are right :) You can replace String with the Resource and be able to get keycloak.json from classpath, file or http via spring properties file (or yml)

Best Regards,
 Andrzej

2015-09-28 23:56 GMT+02:00 Scott Rossillo <srossillo@smartling.com>:
This could be done if the constructor argument is a Spring Resource[0] instead of a string. It doesn’t help with multi-tenant support but it’s still an improvement.


[0] http://docs.spring.io/spring-framework/docs/3.2.x/javadoc-api/org/springframework/core/io/Resource.html



Scott Rossillo
Smartling | Senior Software Engineer

Latest News + Events
Powered by Sigstr

On Sep 28, 2015, at 5:04 PM, Andrzej Goławski <andipansa@gmail.com> wrote:

Hi

Why not do it via contructor:

public AdapterDeploymentContextBean(String configFile){
  .....
}

and in BasicKeycloakWebSecurityConfigurationAdapter add:

@Value("${keycloak.configFile:WEB-INF/keycloak.json}")
private String keycloakConfigFile;

@Bean
protected AdapterDeploymentContextBean adapterDeploymentContextBean() {
    return new AdapterDeploymentContextBean(keycloakConfigFile);
}

Best Regards,
 Andrzej



2015-09-28 22:51 GMT+02:00 Scott Rossillo <srossillo@smartling.com>:

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

Latest News + Events
Powered by Sigstr

On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <thomas.raehalme@aitiofinland.com> wrote:

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.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev