AngularJS web apps for Spring-based REST services security: the server side part 1

First of all, I owe an apology to the readers who have been asking a full security example for some time. I could list all the usual excuses or describe what a week of my life looks like… but I’d rather not underestimate their intelligence. You are all probably living a busy and hectic life, so I’d rather plead for your understanding!

I also want to point out that you should not consider this solution a security “silver bullet“. I am satisfyingly applying this solution for a project I’m working on, and I believe it is secure enough for that specific context. However you will probably want to examine the code and adapt it to your needs (is it secure enough for your needs? Do you actually need to handle CORS or CSRF? Do you need OAuth2 for scalability? Etc.). There’s also the matter of the human factor (me!) and the mistakes that come with that! So keep an eye open and feel free to send me your feedback if you spot anything. That’s how we’re all supposed to learn, right?

The full code for this tutorial is available on GitHub here:

• The server application: https://github.com/codesandnotes/secure-rest-spring-tut
• The web client: https://github.com/codesandnotes/secure-rest-angular-tut

In this series of posts I will examine and explain the code found on the repositories here above.

So let’s start with the server-side then!

Setting up the project

I’ve used Spring IO 1.1.2 (current stable version at the time of writing the code) with Spring Boot on top to set up the project. The pom.xml written for that purpose is quite straightforward, except maybe for the exclusion of that spring-boot-starter-tomcat artifact: I decided I’d use Jetty instead 🙂

One important thing should be noted regarding the application.properties file, which is used by Spring Boot for its initial configuration:

logging.level.org.springframework=INFO
logging.level.org.springframework.security=INFO

server.port=8081

I have changed the server port to 8081. This is to avoid later conflict with the other server that I’ll be using to run the web client. Running the server and the client on two different servers with two different ports will allow us to verify our handling of CORS.

Entry point and context configuration

The application’s entry point class, unsurprisingly named Application, is quite uneventful:

@ComponentScan
@Configuration
@EnableAutoConfiguration
public class Application {

  @Bean
  public WebSecurityConfigurerAdapter webSecurityConfigurerAdapter() {
    return new ApplicationSecurity();
  }

  public static void main(String[] args) {
    SpringApplication application = new SpringApplication(Application.class);
    application.run(args);
  }
}

We enable component scanning and auto configuration through annotations, and we define the main method which will be executed when the Spring Boot application is started. Since I have decided that this will also serve as the very root of my configuration structure, I have also annotated the class with the @Configuration annotation so that any @Bean-annotated method declared here will be registered.

And indeed, this is also where I have decided to provide my own version of the WebSecurityConfigurer bean, which we will use to provide our custom security configuration for this application. I do that by implementing an ApplicationSecurity class which extends the WebSecurityConfigurerAdapter class to override Spring Boot’s default security configuration.

To avoid defining all my beans in Application, I have also set up a SecurityConfiguration class which is responsible of defining beans related to… yep, security!

Providing our own WebSecurityConfigurer implementation

Much of what you will see in our ApplicationSecurity class has been discussed already in one of my previous posts.

In essence, we override Spring Security’s configured AuthenticationEntryPoint, AuthenticationFailureHandler, AuthenticationSuccessHandler and LogoutSuccessHandler in order to provide a behavior that is more REST-friendly than what is proposed by Spring Security out-of-the-box: sending back a 401 when user is not authenticated, or removing the redirections after successfully authenticating or after logging out. I invite you to check these classes in the GitHub repository: they are quite self-explanatory.

http.exceptionHandling().authenticationEntryPoint(authenticationEntryPoint);
http.formLogin().successHandler(authenticationSuccessHandler);
http.formLogin().failureHandler(authenticationFailureHandler);
http.logout().logoutUrl("/logout").logoutSuccessHandler(logoutSuccessHandler);

Since we need some basic profiles to test the authentication, we simply override the configure(AuthenticationManagerBuilder) method from WebSecurityConfigurerAdapter in order to set up a couple of in-memory users:

@Override
protected void configure(AuthenticationManagerBuilder builder) throws Exception {
  builder.inMemoryAuthentication().withUser("user").password("user").roles("USER").and().withUser("admin")
    .password("admin").roles("ADMIN");
}

Finally, we define in the configure(HttpSecurity) method override what is protected by authentication and what is not. Following good practices what we really define is what we exempt from authentication:

http.authorizeRequests()
  .antMatchers(HttpMethod.OPTIONS, "/*/**").permitAll()
  .antMatchers("/login", "/rest/open/**").permitAll()
  .antMatchers("/logout", "/rest/**").authenticated();

What the above says is:

• Requests of the OPTIONS type are always permitted (otherwise preflights cannot be done… more about that further below).
• Requests whose URL is “/login” or beginning with “/rest/open/” are always permitted. This covers the URLs which we want to make accessible to all (the “open” ones) as well as the login POST request (otherwise, it’s kind of a catch-22 situation: needing to be logged in order to… login!).
• All other requests under “/rest/“, as well as the “/logout” URL, are only accessible to authenticated users. This excludes however those URLs starting with “/rest/open/“, because they have been previously been specified as not needing authentication.

There are two more security aspects defined in ApplicationSecurity: CORS and CSRF.

CORS

CORS (cross-origin resource sharing) is the mechanism that secures the sharing of resources with domains that are not the domain of origin of those resources. This helps preventing malevolent persons, under certain circumstances, from adding scripts that are NOT from your site to your web page. The users, feeling safe while using your web application, could otherwise be lured into running some malicious code.

AJAX requests, with their ability to perform POSTs, PUTs or DELETEs, are logically forbidden by default in order to avoid those situations. However that’s kind of a bummer for us, since we actually want our web client on a domain perform AJAX requests on our server, which is on a different domain! So how can we do that in a safe way?

In a nutshell: the browser, who makes a resource request using AJAX, makes a deal with the server. The browser first asks permission to the server for accessing the resource (the preflight), and once the permission is obtained the browser can then perform the actual request to obtain that resource. It might go a little like this:

• (browser) Err… hi there! I’m http://mywebclient.com. Nice meeting you!
  So… I’d like to perform a POST request with this and that header…
• (server) Yeah yeah, hi. Let me check if I can accept that… Hmm… Yep, sounds legit! Ok then, bring it on.
• (browser) Alright mate! Here’s my actual request! …
• (server) Yep, that matches what you said you would request. So here goes the response. Have a nice day!

That’s basically it. If you want the details of what actually happens during that process, check this excellent post on how CORS work. You will have all the dirt, client and server-side.

Do note however that this preflight request is performed automatically by the browser before the actual request. This is not something that has to be programmed in the client.

Setting up CORS

So how do we actually implement that on the server side with Spring Security?

Well, we know we need to define the “rules” by which a resource sharing will be accepted or not. These rules are specified in the header of the response to be sent back to the browser when it preflights.

In practice we set up a filter that does that. In the tutorial code, this is the CORSFilter class. What headers should we specify in there? The available options for the response headers are described quite nicely in this MDN page. For this tutorial I have set up the following ones:

// Access-Control-Allow-Origin
String origin = request.getHeader("Origin");
response.setHeader("Access-Control-Allow-Origin", allowedOrigins.contains(origin) ? origin : "");
response.setHeader("Vary", "Origin");

// Access-Control-Max-Age
response.setHeader("Access-Control-Max-Age", "3600");

// Access-Control-Allow-Credentials
response.setHeader("Access-Control-Allow-Credentials", "true");

// Access-Control-Allow-Methods
response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");

// Access-Control-Allow-Headers
response.setHeader("Access-Control-Allow-Headers",
  "Origin, X-Requested-With, Content-Type, Accept, " + CSRF.REQUEST_HEADER_NAME);

• Access-Control-Allow-Origin specifies the origin URL from which requests will be accepted. A request received from a different origin will be rejected. In this code I compare the origin I get against a list of accepted origins that I have defined. If it is in the list, I specify that origin as being accepted.
• Access-Control-Max-Age defines how long the preflight will be cached, that is, how much time the browser has between what he announced it would request and the actual request.
• Access-Control-Allow-Credentials indicates whether the actual request can contain credentials or not.
• Access-Control-Allow-Methods indicates which methods are allowed to access the resource.
• Access-Control-Allow-Headers lists the headers that can be used by the browser when making the actual request. Notice how in my code I allow a custom header to send CSRF tokens? If that CSRF header is not specified, the tokens will never be accepted by the browser. For requests needing to return CSRF tokens this would obviously be problematic… But I get ahead of myself. More on that later!

There’s one more possible header which we do not use in our tutorial: Access-Control-Expose-Headers. This tells the browser what headers he can access.

We then register that CORS filter in ApplicationSecurity:

http.addFilterBefore(corsFilter, ChannelProcessingFilter.class);

And that’s it!

Let’s go over that sequence again. When the client wants to access a resource:

1. The browser preflights a CORS-triggering request. In practice, it sends an OPTIONS request for that purpose. (always authorize OPTIONS requests in your configuration!).
2. The server replies with the set of conditions by which the actual request is accepted.
3. The browser sends the actual request.
4. The server provides the requested resource.

As we said before, the browser takes care of the preflight. So all the client needs to do, from a code point of view, is send the actual request.

In a forthcoming post I will discuss how CSRF is configured. Later on we’ll also examine how the AngularJS client performs these requests securely. Until then , feel free to play around with the code. This is a Spring Boot application, so running the server is just a matter of running the Application class’ main method.

Cheers!