[keycloak-dev] AdapterDeploymentContextBean with custom location

[Scott Rossillo]

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 at smartling.com

 <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
 <http://www.sigstr.com/>
> On Sep 28, 2015, at 6:10 PM, Andrzej Goławski <andipansa at gmail.com> 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 at smartling.com <mailto:srossillo at 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 <http://docs.spring.io/spring-framework/docs/3.2.x/javadoc-api/org/springframework/core/io/Resource.html>
> 
> 
> 
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com <mailto:srossillo at smartling.com>
> 
>  <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
>  <http://www.sigstr.com/>
>> On Sep 28, 2015, at 5:04 PM, Andrzej Goławski <andipansa at gmail.com <mailto:andipansa at 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 at smartling.com <mailto:srossillo at 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 at smartling.com <mailto:srossillo at smartling.com>
>> 
>>  <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
>>  <http://www.sigstr.com/>
>>> On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <thomas.raehalme at aitiofinland.com <mailto:thomas.raehalme at 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 at lists.jboss.org <mailto:keycloak-dev at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150928/ff0d5291/attachment-0001.html