[keycloak-dev] AdapterDeploymentContextBean with custom location

[Andrzej Goławski]

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/d46b8a2f/attachment-0001.html