On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <thomas.raehalme(a)aitiofinland.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On Sep 28, 2015, at 5:04 PM, Andrzej Goławski <andipansa(a)gmail.com&gt; 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(a)smartling.com <mailto: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 srossillo(a)smartling.com <mailto:srossillo@smartling.com> <https://app.sigstr.com/uc/55e5d41c6533390d03580000> <http://www.sigstr.com/> > On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <thomas.raehalme(a)aitiofinland.com <mailto: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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev> _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>

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/springf... Scott Rossillo Smartling | Senior Software Engineer srossillo(a)smartling.com [image: Latest News + Events] <https://app.sigstr.com/uc/55e5d41c6533390d03580000> [image: Powered by Sigstr] <http://www.sigstr.com/> On Sep 28, 2015, at 5:04 PM, Andrzej Goławski <andipansa(a)gmail.com&gt; 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(a)smartling.com&gt;: > > 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 > srossillo(a)smartling.com > > [image: Latest News + Events] > <https://app.sigstr.com/uc/55e5d41c6533390d03580000> > [image: Powered by Sigstr] <http://www.sigstr.com/> > > On Sep 25, 2015, at 9:21 AM, Thomas Raehalme < > thomas.raehalme(a)aitiofinland.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

The other adapters support the concept of Multi Tenancy[0]: “That one single target application (WAR) can be secured by a single (or clustered) Keycloak server, authenticating its users against different realms. In practice, this means that one application needs to use different keycloak.json files" [0]: http://keycloak.github.io/docs/userguide/html/ch08.html#multi_tenancy Scott Rossillo Smartling | Senior Software Engineer srossillo(a)smartling.com [image: Latest News + Events] <https://app.sigstr.com/uc/55e5d41c6533390d03580000> [image: Powered by Sigstr] <http://www.sigstr.com/> On Sep 28, 2015, at 6:10 PM, Andrzej Goławski <andipansa(a)gmail.com&gt; wrote: Sorry if it is a stupid question, but what do you mean by multi-tenant in this case? 2015-09-28 23:56 GMT+02:00 Scott Rossillo <srossillo(a)smartling.com&gt;: > 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/springf... > > > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo(a)smartling.com > > [image: Latest News + Events] > <https://app.sigstr.com/uc/55e5d41c6533390d03580000> > [image: Powered by Sigstr] <http://www.sigstr.com/> > > On Sep 28, 2015, at 5:04 PM, Andrzej Goławski <andipansa(a)gmail.com&gt; > 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(a)smartling.com&gt;: > >> >> 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 >> srossillo(a)smartling.com >> >> [image: Latest News + Events] >> <https://app.sigstr.com/uc/55e5d41c6533390d03580000> >> [image: Powered by Sigstr] <http://www.sigstr.com/> >> >> On Sep 25, 2015, at 9:21 AM, Thomas Raehalme < >> thomas.raehalme(a)aitiofinland.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > >