1. Introduction
In this quick tutorial, we’re going to focus on the Servlet 3 support for async requests, and how Spring MVC and Spring Security handle these.
The most basic motivation for asynchronicity in web applications is to handle long running requests. In most use cases, we’ll need to make sure the Spring Security principal is propagated to these threads.
And, of course, Spring Security integrates with @Async outside the scope of MVC and processing HTTP requests as well.
2. Maven Dependencies
In order to use the async integration in Spring MVC, we need to include the following dependencies into our pom.xml:
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-web</artifactId>
<version>6.1.5</version>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-config</artifactId>
<version>6.1.5</version>
</dependency>
The latest version of Spring Security dependencies can be found here.
3. Spring MVC and @Async
According to the official docs, Spring Security integrates with WebAsyncManager.
The first step is to ensure our springSecurityFilterChain is set up for processing asynchronous requests. We can do it either in Java config, by adding following line to our Servlet config class:
dispatcher.setAsyncSupported(true);
or in XML config:
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
<async-supported>true</async-supported>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>ASYNC</dispatcher>
</filter-mapping>
We also need to enable the async-supported parameter in our servlet configuration:
<servlet>
...
<async-supported>true</async-supported>
...
</servlet>
Now we are ready to send asynchronous requests with SecurityContext propagated with them.
Internal mechanisms within Spring Security will ensure that our SecurityContext is no longer cleared out when a response is committed in another Thread resulting in a user logout.
4. Use Cases
Let’s see this in action with a simple example:
@Override
public Callable<Boolean> checkIfPrincipalPropagated() {
Object before
= SecurityContextHolder.getContext().getAuthentication().getPrincipal();
log.info("Before new thread: " + before);
return new Callable<Boolean>() {
public Boolean call() throws Exception {
Object after
= SecurityContextHolder.getContext().getAuthentication().getPrincipal();
log.info("New thread: " + after);
return before == after;
}
};
}
We want to check if the Spring SecurityContext is propagated to the new thread.
The method presented above will automatically have its Callable executed with the SecurityContext included, as seen in logs:
web - 2017-01-02 10:42:19,011 [http-nio-8081-exec-3] INFO
o.baeldung.web.service.AsyncService - Before new thread:
org.springframework.security.core.userdetails.User@76507e51:
Username: temporary; Password: [PROTECTED]; Enabled: true;
AccountNonExpired: true; credentialsNonExpired: true;
AccountNonLocked: true; Granted Authorities: ROLE_ADMIN
web - 2017-01-02 10:42:19,020 [MvcAsync1] INFO
o.baeldung.web.service.AsyncService - New thread:
org.springframework.security.core.userdetails.User@76507e51:
Username: temporary; Password: [PROTECTED]; Enabled: true;
AccountNonExpired: true; credentialsNonExpired: true;
AccountNonLocked: true; Granted Authorities: ROLE_ADMIN
Without setting up the SecurityContext to be propagated, the second request will end up with null value.
There are also other important use cases to use asynchronous requests with propagated SecurityContext:
- we want to make multiple external requests which can run in parallel and which may take significant time to execute
- we have some significant processing to do locally and our external request can execute in parallel to that
- other represent fire-and-forget scenarios, like for example sending an email
Do note that, if our multiple method calls were previously chained together in a synchronous fashion, converting these to an asynchronous approach may require synchronizing results.
5. Conclusion
In this short tutorial, we illustrated the Spring support for processing asynchronous requests in an authenticated context.
From a programming model perspective, the new capabilities appear deceptively simple. But there are certainly some aspects that do require a more in-depth understanding.
This example is also available as a Maven project over on Github.
