Failed to authorize user/application ‘anonymousUser’ for request to /ui/VAADIN/push. Granted permissions [ROLE_ANONYMOUS] are insufficient.
This happens when clients lose connection because our servers/pods got restarted. In those cases clients need a “hard” reconnect with full OAuth2 (Azure) authentication.
When we add "/ui/VAADIN/push" to the permitted and authenticated requests in our Spring SecurityFilterChain however, the log entries disappear and clients can auto-reconnect.
But obviously we are reluctant to just add "/ui/VAADIN/push" to the list of permitAll().fullyAuthenticated() requestMatchers - this looks dodgy security-wise.
Are you using VaadinWebSecurity? If yes, no extra config for Push needed, it should be included in the configuration already there.
Are you using Kubernetes Kit? If yes, use version 2.4.1, as there was recently a bug fix regarding similar scenario.
Namely VaadinWebSecurity will use custom context security holder strategy storing security context in Vaadin session. This means that Vaadin session needs to be de-serialized before Spring Security request filter kicks in. If these are not in correct order, the security context is not found and user will be asked to relogin.
We use neither VaadinWebSecurity nor KubernetesKit, no.
We have a WebSecurity implementation based on com.azure.spring.cloud.autoconfigure.implementation.aad.security.AadWebApplicationHttpSecurityConfigurer.
There we have taken over the
// Vaadin has its own CSRF protection.
// Spring CSRF is not compatible with Vaadin internal requests
http.csrf(cfg -> cfg.ignoringRequestMatchers(
requestUtil::isFrameworkInternalRequest));
part of VaadinWebSecurity.
What else would we need to do/configure in order to emulate the VaadinWebSecurity behavior?
That would indeed do the trick. Problem is that our app uses a custom permission service which is not based on the jakarta.annotation.security annotations that VaadinWebSecurity expects.
So we would basically need VaadinWebSecurity with custom Roles handling.
That’s why we currently extend AadWebApplicationHttpSecurityConfigurer rather then VaadinWebSecurity. That works - besides the problem described above.
Disabling Vaadin navigation access somehow leads to getAuthentication().getPrincipal() returning “anonymousUser” rather than the authenticated AAD user, once the reconnect push has been done.
We’ll look further into the specifics, at least we now have an idea where to look.
