15. Servlet API integration
Prev | Part IV. Web Application Security | Next

## 15. Servlet API integration

This section describes how Spring Security is integrated with the Servlet API. The servletapi-xml sample application demonstrates the usage of each of these methods.

## 15.1 Servlet 2.5+ Integration

### 15.1.1 HttpServletRequest.getRemoteUser()

The HttpServletRequest.getRemoteUser() will return the result of `SecurityContextHolder.getContext().getAuthentication().getName()` which is typically the current username. This can be useful if you want to display the current username in your application. Additionally, checking if this is null can be used to indicate if a user has authenticated or is anonymous. Knowing if the user is authenticated or not can be useful for determining if certain UI elements should be shown or not (i.e. a log out link should only be displayed if the user is authenticated).

### 15.1.2 HttpServletRequest.getUserPrincipal()

The HttpServletRequest.getUserPrincipal() will return the result of `SecurityContextHolder.getContext().getAuthentication()`. This means it is an `Authentication` which is typically an instance of `UsernamePasswordAuthenticationToken` when using username and password based authentication. This can be useful if you need additional information about your user. For example, you might have created a custom `UserDetailsService` that returns a custom `UserDetails` containing a first and last name for your user. You could obtain this information with the following:

    Authentication auth = httpServletRequest.getUserPrincipal();
    // assume integrated custom UserDetails called MyCustomUserDetails
    // by default, typically instance of UserDetails
    MyCustomUserDetails userDetails = (MyCustomUserDetails) auth.getPrincipal();
    String firstName = userDetails.getFirstName();
    String lastName = userDetails.getLastName();

| Note
It should be noted that it is typically bad practice to perform so much logic throughout your application. Instead, one should centralize it to reduce any coupling of Spring Security and the Servlet API’s.

### 15.1.3 HttpServletRequest.isUserInRole(String)

The HttpServletRequest.isUserInRole(String) will determine if `SecurityContextHolder.getContext().getAuthentication().getAuthorities()` contains a `GrantedAuthority` with the role passed into `isUserInRole(String)`. Typically users should not pass in the "ROLE_" prefix into this method since it is added automatically. For example, if you want to determine if the current user has the authority "ROLE_ADMIN", you could use the following:

    boolean isAdmin = httpServletRequest.isUserInRole("ADMIN");

This might be useful to determine if certain UI components should be displayed. For example, you might display admin links only if the current user is an admin.

## 15.2 Servlet 3+ Integration

The following section describes the Servlet 3 methods that Spring Security integrates with.

### 15.2.1 HttpServletRequest.authenticate(HttpServletRequest,HttpServletResponse)

The HttpServletRequest.authenticate(HttpServletRequest,HttpServletResponse) method can be used to ensure that a user is authenticated. If they are not authenticated, the configured AuthenticationEntryPoint will be used to request the user to authenticate (i.e. redirect to the login page).

### 15.2.2 HttpServletRequest.login(String,String)

The HttpServletRequest.login(String,String) method can be used to authenticate the user with the current `AuthenticationManager`. For example, the following would attempt to authenticate with the username "user" and password "password":

    try {
    httpServletRequest.login("user","password");
    } catch(ServletException e) {
    // fail to authenticate
    }

| Note
It is not necessary to catch the ServletException if you want Spring Security to process the failed authentication attempt.

### 15.2.3 HttpServletRequest.logout()

The HttpServletRequest.logout() method can be used to log the current user out.

Typically this means that the SecurityContextHolder will be cleared out, the HttpSession will be invalidated, any "Remember Me" authentication will be cleaned up, etc. However, the configured LogoutHandler implementations will vary depending on your Spring Security configuration. It is important to note that after HttpServletRequest.logout() has been invoked, you are still in charge of writing a response out. Typically this would involve a redirect to the welcome page.

### 15.2.4 AsyncContext.start(Runnable)

The AsynchContext.start(Runnable) method that ensures your credentials will be propagated to the new Thread. Using Spring Security’s concurrency support, Spring Security overrides the AsyncContext.start(Runnable) to ensure that the current SecurityContext is used when processing the Runnable. For example, the following would output the current user’s Authentication:

    final AsyncContext async = httpServletRequest.startAsync();
    async.start(new Runnable() {
    	public void run() {
    		Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
    		try {
    			final HttpServletResponse asyncResponse = (HttpServletResponse) async.getResponse();
    			asyncResponse.setStatus(HttpServletResponse.SC_OK);
    			asyncResponse.getWriter().write(String.valueOf(authentication));
    			async.complete();
    		} catch(Exception e) {
    			throw new RuntimeException(e);
    		}
    	}
    });

### 15.2.5 Async Servlet Support

If you are using Java Based configuration, you are ready to go. If you are using XML configuration, there are a few updates that are necessary. The first step is to ensure you have updated your web.xml to use at least the 3.0 schema as shown below:

    <web-app xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    version="3.0">

    </web-app>

Next you need to ensure that your springSecurityFilterChain is setup for processing asynchronous requests.

    <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>

That’s it! Now Spring Security will ensure that your SecurityContext is propagated on asynchronous requests too.

So how does it work? If you are not really interested, feel free to skip the remainder of this section, otherwise read on. Most of this is built into the Servlet specification, but there is a little bit of tweaking that Spring Security does to ensure things work with asynchronous requests properly. Prior to Spring Security 3.2, the SecurityContext from the SecurityContextHolder was automatically saved as soon as the HttpServletResponse was committed. This can cause issues in an Async environment. For example, consider the following:

    httpServletRequest.startAsync();
    new Thread("AsyncThread") {
    	@Override
    	public void run() {
    		try {
    			// Do work
    			TimeUnit.SECONDS.sleep(1);

    			// Write to and commit the httpServletResponse
    			httpServletResponse.getOutputStream().flush();
    		} catch (Exception e) {
    			e.printStackTrace();
    		}
    	}
    }.start();

The issue is that this Thread is not known to Spring Security, so the SecurityContext is not propagated to it. This means when we commit the HttpServletResponse there is no SecuriytContext. When Spring Security automatically saved the SecurityContext on committing the HttpServletResponse it would lose our logged in user.

Since version 3.2, Spring Security is smart enough to no longer automatically save the SecurityContext on commiting the HttpServletResponse as soon as HttpServletRequest.startAsync() is invoked.

## 15.3 Servlet 3.1+ Integration

The following section describes the Servlet 3.1 methods that Spring Security integrates with.

### 15.3.1 HttpServletRequest#changeSessionId()

The HttpServletRequest.changeSessionId() is the default method for protecting against Session Fixation attacks in Servlet 3.1 and higher.

Prev | Up | Next
14. Core Security Filters | Home | 16. Basic and Digest Authentication