[keycloak-dev] AdapterDeploymentContextBean with custom location

[Andrzej Goławski]

Thank you for explanation !

In that case you could replace Resource with List<Resource> and provide
config files via propery file.

exemple for yml:

keycloak.configFiles:
       - file:/../first-keycloak.json
       - classpath:/../second-keycloak.json

Ofcourse you are the designer of this adapter so decision is yours :)

Best Regards,
 Andrzej

2015-09-29 1:38 GMT+02:00 Scott Rossillo <srossillo at smartling.com>:

> 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
>
> [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 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>:
>
>> 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
>> srossillo at 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 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>:
>>
>>>
>>> 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
>>>
>>> [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 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
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150929/7363cc65/attachment-0001.html