2

I have been been playing with spring boot and been successful in using Keycloak and Vaadin separately in different projects. Now, I wanted to combine both to avoid having to implement my own security using Vaadin. The result I have so far can be found here: github project.

I started from the shared security example given by vaadin4spring. I then added the Keycloak configuration as given by the keycloak-spring-security-adapter and the keycloak-spring-boot-adapter.

I have now hit a wall in getting both to work together. When everything is up and running and I navigate to localhost:8080, I get the following error:

{"timestamp":...,"status":401,"error":"Unauthorized","message":"Unauthorized","path":"/"}

No redirect is triggered to authenticate with Keycloak. However, if I navigate to any other url not managed by Vaadin, e.g. localhost:8080/login, the redirect is triggered.

After logging in successfully, I can navigate to localhost:8080 without an error. However, any operation remains restricted and the secured views remain hidden.

Any ideas how to fix my configuration? I am thinking it is due to Vaadin handling CORS.

chvndb
  • 615
  • 8
  • 18

2 Answers2

3

I use the Keycloak Spring Security Adapter and had some problems when securing the root path ("/") for the UI service too.

I ended up configuring Spring MVC to send a redirect when user tries to access the root path in the UI:

@Bean
public WebMvcConfigurerAdapter forwardToEquipmentManager() {
    return new WebMvcConfigurerAdapter() {
        @Override
        public void addViewControllers(ViewControllerRegistry registry) {
            registry.addViewController("/").setViewName("redirect:/ui/home");
        }
    };
}

This way the browser is redirected to the home path when asking for the root path and it fires the adapter logic. It just works.

Aritz
  • 30,971
  • 16
  • 136
  • 217
1

Apparently, in my setup, upon startup the system would register the user as being anonymous instead of trying to actually authenticate.

http.anonymous().disable();

Adding the above snippet to the security configuration prevents this from happening and the system correctly redirects the user to KC login.

Once I got this working, I noticed my views were also broken. This was due to method security proxy settings affecting all beans. Vaadin requires actual run-time classes instead of proxies to e.g. find views.

@EnableGlobalMethodSecurity(securedEnabled = true, prePostEnabled = true, proxyTargetClass = true)

Changing proxyTargetClass to true ensures subclass proxies are created avoiding any conflict with Vaadin.

I pushed all changes to the github project.

chvndb
  • 615
  • 8
  • 18
  • I guess this could be tuned in some way for projects that have some kind of anonymously accessible view (such as a user registration form). Kind regards ;-) – Aritz May 14 '17 at 15:03
  • Yes, if you would want this. I require by default that a user is registered before the application can be accessed. This can be changed to by default permit all access and then do more fine grained access control on views and methods. – chvndb Jun 30 '17 at 07:38