How to do impersonation using spring security?

General
1

I’ve got the whole impersonation setup: filter, authentication, and I have a Vaadin menu with the users that can be impersonated (only shown to admin of course). Then I use UI.getCurrent().getPage().setLocation(…) to redirect to the appropriate URL. That works and I see the execution enter SwitchUserFilter and attempting to switch user (createSwitchUserToken). Great.

But then Spring’s ThreadLocalSecurityContextHolderStrategy thinks there is no current user logged in because its contextHolder contains null, gets populated with an EmptyContext and the user switching fails in SwitchUserGrantedAuthority because of null checks.

Why would there not be a context populated? Is Vaadin influencing that?

    @Bean
    public SwitchUserFilter switchUserFilter() {
        SwitchUserFilter filter = new SwitchUserFilter();
        filter.setUserDetailsService(userDetailsService);
        filter.setSwitchUserMatcher(new AntPathRequestMatcher("/impersonate", "GET"));
        filter.setExitUserUrl("/deimpersonate");
        filter.setTargetUrl("/");
        return filter;
    }
2

I don’t understand your use case.
Can you tell use a bit more about it?

3

It is quite simple: I have an employee scheduling application, I do not know the employee’s passwords, so I login as administrator and then need to impersonate one of the employees. Spring has a default approach for that. E.g. User impersonation with Spring Security

It essentially is working, except that it does not find a logged in user (administrator) when trying to setup the impersonation. Since none of the Spring examples menion anything more that what is described in the link, I’m wondering if Vaadin is doing something so things are different.

4

I’ve found this. vaadin - User Impersonation with Spring Security - Stack Overflow

5

Yes, found that one too; you see the authentication and the filter setup. That is what I have as well. As said: it works from a configuration perspective, what you see in that post, it tries to impersonate but then it fails.

6

There is a thing as a VaadinAwareSecurityContextHolderStrategy, Vaadin does seem to do something different there.

7

What may be a/the cause is that the SwitchUserFilter (which is responsible for the impersonation) sits before the VaadinService (which sets the value in CurrentInstance, which is used by the context to determine the Authorization) in the request chain. So the moment the SwitchUserFilter tries to determine the current logged in user prior to switching, the Authorization appears not to have been initialized.

Has impersonation ever been tried in a Vaadin-on-spring application? The StackOverflow article approves the answer for the POST vs GET issue, but it is unclear if the impersonation actually worked.

8

Given that the Authorization is the problem, I’ve hacked around this issue by creating a local instance of SwitchUserFilter and calling the attempSwitchUser directly, using the active request (which has the Authorization setup), spoofing the username parameter.

That works, but it binds my code to the implementation of SwitchUserFilter instead of using the formal API, which is not okay. So the question remains: has this ever been tried with Vaadin-on-Spring?

9

I had time to look into it. And I double your assumption that you are probably the first trying to do that with Vaadin Flow.

I recommend to open an issue: Issues · vaadin/flow · GitHub

1 Like
10
4 Likes