Long time ago I worked on a project that had a quite powerful feature. There were two roles: user and supervisor. Supervisor could change any document in the system in any way while users were much more limited to workflow constraints. When a normal user had some issue with the document currently being edited and stored in HTTP session, supervisor could step in, switch to special supervisor<\/i> mode and bypass all constrains. Total freedom. Same computer, same keyboard, same HTTP session. Only special flag that supervisor could set by entering secret password. Once the supervisor was done, he or she could clear that flag and enable usual constraints again.<\/p>\n
This feature worked well but it was poorly implemented. Availability of every single input field was dependent on that supervisor mode<\/i> flag. Business methods were polluted in dozens of places with Another interesting use case arises when our application is highly customizable with plenty of security roles. Sooner or later you will face anomaly (OK, bug<\/i>) that you simply can\u2019t reproduce having different privileges. Being able to log in as that particular user and look around might be a big win. Of course you don\u2019t know the passwords of your users (don\u2019t you?<\/i><\/a>). UNIX-like systems found solution to this problem: All you need is declaring custom filter:<\/p>\n and pointing to it in That\u2019s it! Notice that I secure And automagically you become logged in as Indeed with great power\u2026<\/i>. Giving even most trusted user ability to log in as any other arbitrary user sounds quite risky. Imagine such a feature on Facebook, impossible! ( well\u2026<\/a>) Thus tracking and auditing becomes a major requirement.<\/p>\n What I typically do in the first place is adding a small servlet filter right after Spring Security filter that adds user name to MDC<\/a>:<\/p>\n Just remember to add it to See the The second log statement is interesting. If you look at Sometimes you need even stronger auditing system. Luckily Spring framework has built-in event infrastructure and we can take advantage of Of course you can replace simple logging with any business logic you desire, e.g. storing such event in database or sending an e-mail to security officer.<\/p>\n So we know how to log in as a different user for a period of time and then exit such mode. But what if we need \u201c Adding custom HTTP header to denote such a special impersonating request sounds reasonable. It works only for the duration of one request, assuming the client is already authenticating, e.g. using JSESSIONID cookie. Unfortunately this is not supported by Spring Security, but easy to implement on top of The only difference from original And our custom \u201c Of course without Long time ago I worked on a project that had a quite powerful feature. There were two roles: user and supervisor. Supervisor could change any document in the system in any way while users were much more limited to workflow constraints. When a normal user had some issue with the document currently being edited and …<\/p>\n","protected":false},"author":13,"featured_media":240,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[30,125],"class_list":["post-15166","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-enterprise-java","tag-spring","tag-spring-security"],"yoast_head":"\nisSupervisorMode()<\/code> check. And remember that if supervisor simply logged in using normal credentials, this mode was sort of implicit so security constraints were basically duplicated.<\/p>\nsu<\/code><\/a> (switch user<\/i>) and sudo<\/code><\/a> commands. Surprisingly Spring Security<\/a> ships with built-in SwitchUserFilter<\/code><\/a> that in principle mimics su<\/code> in web applications. Let\u2019s give it a try!<\/p>\n<bean id=\"switchUserProcessingFilter\"\r\n class=\"org.springframework.security.web.authentication.switchuser.SwitchUserFilter\">\r\n <property name=\"userDetailsService\" ref=\"userDetailsService\"\/>\r\n <property name=\"targetUrl\" value=\"\/\"\/>\r\n<\/b:bean><\/pre>\n
<http><\/code> configuration:<\/p>\n<http auto-config=\"true\" use-expressions=\"true\">\r\n <custom-filter position=\"SWITCH_USER_FILTER\" ref=\"switchUserProcessingFilter\" \/>\r\n <intercept-url pattern=\"\/j_spring_security_switch_user\" access=\"hasRole('ROLE_SUPERVISOR')\"\/>\r\n ...<\/pre>\n\/j_spring_security_switch_user<\/code> URL pattern. You guessed it, that\u2019s how you log in as a different user, thus we want this resource to be well protected. By default j_username<\/code> parameter name is used. After applying changes above to your web application and logging in with a user having ROLE_SUPERVISOR<\/code> one can simply browse to:<\/p>\n\/j_spring_security_switch_user?j_username=bob<\/pre>\n
bob<\/code> – assuming there exists such a user. No password required here. When you are done impersonating him, browsing to \/j_spring_security_exit_user<\/code> will restore your previous credentials. Of course all these URLs are configurable. SwitchUserFilter<\/code> is not documented in Reference Documentation<\/i><\/a> but it is a very useful tool when used with caution.import org.slf4j.MDC;\r\n \r\npublic class UserNameFilter implements Filter {\r\n \r\n @Override\r\n public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {\r\n final Authentication authentication = SecurityContextHolder.getContext().getAuthentication();\r\n final String userName = authentication.getName();\r\n final String fullName = userName + (realName != null ? \" (\" + realName + \")\" : \"\");\r\n \r\n MDC.put(\"user\", fullName);\r\n try {\r\n chain.doFilter(request, response);\r\n } finally {\r\n MDC.remove(\"user\");\r\n }\r\n }\r\n \r\n private String findSwitchedUser(Authentication authentication) {\r\n for (GrantedAuthority auth : authentication.getAuthorities()) {\r\n if (auth instanceof SwitchUserGrantedAuthority) {\r\n return ((SwitchUserGrantedAuthority)auth).getSource().getName();\r\n }\r\n }\r\n return null;\r\n }\r\n \r\n \/\/...\r\n}<\/pre>\nweb.xml<\/code> after<\/b> Spring Security. At this point you can reference \"user\"<\/code> key e.g. in logback.xml<\/code>:<\/p>\n<pattern>%d{HH:mm:ss.SSS} | %-5level | %X{user} | %thread | %logger{1} | %m%n%rEx<\/pattern><\/pre>\n%X{user}<\/code> snippet? Every time logged in user does something in the system that triggers log statement, you will see that users\u2019 name:<\/p>\n21:56:55.074 | DEBUG | alice | http-bio-8080-exec-9 | ...\r\n\/\/...\r\n21:56:57.314 | DEBUG | bob (alice) | http-bio-8080-exec-3 | ...<\/pre>\n
findSwitchedUser()<\/code> call above it becomes obvious that alice<\/code>, being a supervisor, switched to user bob<\/code> and now browses on behalf of him.<\/p>\nAuthenticationSwitchUserEvent<\/code><\/a> sent both when someone switches user and exits this mode:<\/p>\n@Service\r\npublic class SwitchUserListener\r\n implements ApplicationListener<AuthenticationSwitchUserEvent> {\r\n \r\n private static final Logger log = LoggerFactory.getLogger(SwitchUserListener.class);\r\n \r\n @Override\r\n public void onApplicationEvent(AuthenticationSwitchUserEvent event) {\r\n log.info(\"User switch from {} to {}\",\r\n event.getAuthentication().getName(),\r\n event.getTargetUser().getUsername());\r\n }\r\n}<\/pre>\nsudo<\/code>\u201d, that is making just one HTTP request on behalf of some other user? Of course we can switch to that user, run that request and then exit. But that seems too heavyweight and cumbersome. Such a requirement may pop up when client program accesses our API and wants to see data as another user (think about testing complex ACLs).<\/p>\nSwitchUserFilter<\/code>:<\/p>\npublic class SwitchUserOnceFilter extends SwitchUserFilter {\r\n \r\n @Override\r\n public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {\r\n HttpServletRequest request = (HttpServletRequest) req;\r\n \r\n final String switchUserHeader = request.getHeader(\"X-Switch-User-Once\");\r\n if (switchUserHeader != null) {\r\n trySwitchingUserForThisRequest(chain, request, res, switchUserHeader);\r\n } else {\r\n super.doFilter(req, res, chain);\r\n }\r\n }\r\n \r\n private void trySwitchingUserForThisRequest(FilterChain chain, HttpServletRequest request, ServletResponse response, String switchUserHeader) throws IOException, ServletException {\r\n try {\r\n proceedWithSwitchedUser(chain, request, response, switchUserHeader);\r\n } catch (AuthenticationException e) {\r\n throw Throwables.propagate(e);\r\n }\r\n }\r\n \r\n private void proceedWithSwitchedUser(FilterChain chain, HttpServletRequest request, ServletResponse response, String switchUserHeader) throws IOException, ServletException {\r\n final Authentication targetUser = attemptSwitchUser(new SwitchUserRequest(request, switchUserHeader));\r\n SecurityContextHolder.getContext().setAuthentication(targetUser);\r\n \r\n try {\r\n chain.doFilter(request, response);\r\n } finally {\r\n final Authentication originalUser = attemptExitUser(request);\r\n SecurityContextHolder.getContext().setAuthentication(originalUser);\r\n }\r\n \r\n }\r\n \r\n}<\/pre>\nSwitchUserFilter<\/code> is that if \"X-Switch-User-Once\"<\/code> is present, we switch credentials to user denoted by the value of this header – however only for the duration of one HTTP request.SwitchUserFilter<\/code> assumes user name to switch to is under j_username<\/code> parameter so I had to cheat a bit with SwitchUserRequest<\/code> wrapper:<\/p>\nprivate class SwitchUserRequest extends HttpServletRequestWrapper {\r\n \r\n private final String switchUserHeader;\r\n \r\n public SwitchUserRequest(HttpServletRequest request, String switchUserHeader) {\r\n super(request);\r\n this.switchUserHeader = switchUserHeader;\r\n }\r\n \r\n @Override\r\n public String getParameter(String name) {\r\n switch (name) {\r\n case SPRING_SECURITY_SWITCH_USERNAME_KEY:\r\n return switchUserHeader;\r\n default:\r\n return super.getParameter(name);\r\n }\r\n }\r\n}<\/pre>\nsudo<\/code>\u201d is in place! You can test it e.g. using curl<\/code>:<\/p>\n$ curl localhost:8080\/books\/rest\/book \\\r\n -H \"X-Switch-User-Once: bob\" \\\r\n -b \"JSESSIONID=...\"<\/pre>\n
JSESSIONID<\/code> cookie the system would not let us in. We have to be logged in first and have special privileges to access sudo<\/code> functionality. Switching user is a handy and quite powerful tool. If you want to try it in practice, check out working example on GitHub<\/a>.
\n <\/p>\n