This sounds to me more like an enhancement, however, we have to double check our integration with Spring Security, maybe there is something blocking this feature to work.

Assuming the integration with Spring security is supposed to encompass all standard functionality, than this should be supported IMHO.

@tbee JFYI, impersonation worked for me on V14 and V23, but I can't make it work on V24 too.

I did a quick example project based on Vaadin 23 that uses Spring Security and SwitchUserGrantedAuthority, but doesn't use SwitchUserFilter which makes it possible to impersonate user by just clicking on a button.

First commit in this branch uses SwitchUserFilter and it also works good.

Next step is to rebase this to Vaadin 24 and figure out why we got an exception - random clues are major version jump of the Spring Security (Spring 5 -> Spring 6) or some new features in Vaadin 24 that added more logic to Spring Security integration.

Hm, personally I'd probably prefer the solution with just a button. But it seems to be a lot of spring code of which I'm not certain how standard it is. Just redirecting to an URL is the approach with the lower coupling.

It looks like SwitchUserFilter does not use same security context configuration as defined in VaadinWebSecurity (specifically requireExplicitSave(false)) . For now, I managed to achieve impersonation by defining CustomSwitchUserFilter that extends SwitchUserFilter and overriding needed methods. In method attemptSwitchUser after publishing event i added this code SecurityContextHolder.getContext().setAuthentication(targetUserRequest); and it is working as before. It is probably misconfiguration of spring security, but I have not found any other way of achieving this for now.

What I found out was that with v24.6 the userFilter uses the wrong securityContextHolderStrategy.
Making the following setup in crm tutorial has impersonation working ok.

In short the changes are:
add into VaadinWebSecurity config

  @Autowired
  private ApplicationContext applicationContext;

  @Bean
  public SwitchUserFilter switchUserFilter() {
    SwitchUserFilter filter = new SwitchUserFilter();
    filter.setSecurityContextHolderStrategy(
            applicationContext.getBean(VaadinAwareSecurityContextHolderStrategy.class));
    filter.setUserDetailsService(userDetailsService());
    filter.setSwitchUserMatcher(antMatcher(HttpMethod.GET, "/impersonate"));
    filter.setSwitchFailureUrl("/switchUser");
    filter.setExitUserMatcher(antMatcher(HttpMethod.GET, "/impersonate/exit"));
    filter.setTargetUrl("/");
    return filter;
  }

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(auth -> auth.requestMatchers(new AntPathRequestMatcher("/impersonate")).hasAnyRole("ADMIN", "PREVIOUS_ADMINISTRATOR"));
    http.authorizeHttpRequests(auth -> auth.requestMatchers(new AntPathRequestMatcher("/impersonate/exit")).hasRole("PREVIOUS_ADMINISTRATOR"));
    ...
  }

Impersonation of use

        Button impersonate = new Button("Impersonate user", e -> {
            getUI().ifPresent(ui -> ui.getPage().setLocation("/impersonate?username=user"));
        });

Exit impersonation

        Button exitImpersonation = new Button("Exit impersonation", e ->
                getUI().ifPresent(ui -> ui.getPage().setLocation("/impersonate/exit")));

A possible solution could be modifying the SwitchUserFilter if it's present in the project's config:

@Bean
@ConditionalOnBean(SwitchUserFilter.class)
public SwitchUserFilter customizedSwitchUserFilter(SwitchUserFilter existingFilter) {
    // set Vaadin security context
    return existingFilter;
}

But would be good to figure out why the Vaadin context is not injected without this hack.

The main issue is that when the Filter initializes the securitycontextholderstrategy gets chosen by default as ThreadLocalSecurityContextHolderStrategy which doesn't contain any authentication as vaadin stores that in the VaadinAwareSecurityContextHolderStrategy.

Also it seems it's a timing issue from #14631 where the security context was moved from a set during configuration to being a Bean.

Seems the correct fix for this would be to set up the userFilter as:

  @Bean
  @DependsOn("VaadinSecurityContextHolderStrategy")
  public SwitchUserFilter switchUserFilter() {
    SwitchUserFilter filter = new SwitchUserFilter();
    filter.setUserDetailsService(userDetailsService());
    filter.setSwitchUserMatcher(antMatcher(HttpMethod.GET, "/impersonate"));
    filter.setSwitchFailureUrl("/switchUser");
    filter.setExitUserMatcher(antMatcher(HttpMethod.GET, "/impersonate/exit"));
    filter.setTargetUrl("/");
    return filter;
  }

This way the context is correct when the switch user filter is generated.

How about combining these two annotations together to embed this fix to the framework? (not tested though)

@Bean
@ConditionalOnBean(SwitchUserFilter.class)
@DependsOn("VaadinSecurityContextHolderStrategy")  // Ensure it initializes after VaadinSecurityContextHolderStrategy
public SwitchUserFilter projectSwitchUserFilter(SwitchUserFilter switchUserFilter) {
    // no modifications, just return
    return switchUserFilter;
}

I would perhaps just go with documentation and an it test module in Flow so we catch any change to functionality on updates.