Securing your application landscape with Spring Cloud Security – Part 1

Posted on September 2, 2016 by Riccardo Lippolis

Securing an application is difficult. Securing an entire application landscape is even more difficult! In this modern era of blazing fast microservices we do not want the additional complexity of having to secure it all manually. This is where Spring Cloud Security comes in. By combining proven technologies, it helps us achieve performant, configurable end-to-end security across multiple applications.

So what technologies are being combined? Well, a lot… We will not mention them all here, but the foundation relies on Spring Boot and Spring Security OAuth.

OAuth, or, in our case, OAuth2 is basically an authorization delegation protocol. To quote Wikipedia, OAuth:

[…] specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials.

In our context, the resource owners are the users of our applications, server resources are the data we store about our users (e.g. the list of shop orders), and third-parties are the applications (or services) in our landscape which perform actions on the user data.

A common mistake people make is thinking that OAuth also provides authentication. It doesn’t, but that’s where Spring Security kicks in. For more information about the difference between authentication and authorization in an OAuth context, we refer you to this article.

Basically, the picture below visualizes the type of application landscape we want to achieve with this series of articles.

An overview of the type of application landscape we want to achieve

In the following series of articles, we will build a concrete implementation of the above displayed application landscape from the ground up, with as little code and configuration as possible. We will make some concessions regarding complexity and functionality, mainly to enable us to focus on the basic principles.

The project source code is available on Bitbucket, so feel free to clone the Git repository:

git clone https://bitbucket.org/rlippolis/cloud-security-example.git

1	git clone https://bitbucket.org/rlippolis/cloud-security-example.git

The master branch contains the complete solution. Each article in this series will represent a separate step in the development of the solution. Several Git tags have been created in the repository to be able to follow along with each step.

How to run it

To be able to run the applications, the following software is required:

Gradle (tested with version 2.12)
Java 8 Development Kit

All three applications in the Git repository can be run from the command line, by executing the following command from the root directory of the application to run:

gradle bootRun

1	gradle bootRun

Alternatively, it is possible to run the main method in the relevant Spring Boot Application class (MyAuthServerApplication / MyWebsiteApplication / MyRestApiApplication) from an IDE or command line.

It does not matter in which order the applications are started.

Securing a basic website with a separate Identity Provider

As a starting point, we have created a Spring Boot application, called My Website. The application is bootstrapped using Spring Initializr, with the Web and Thymeleaf dependencies.

The application is pretty straightforward, containing a single Spring MVC Controller, to render a web page which displays the current time (like mentioned before, the functionality of the application is irrelevant, so we keep this simple). For now, the application is not secured in any way.

Tip To see the application in its initial state (not secured), checkout the Git tag insecure-website from the repository. To see the end result of this step (the website is secured using an Identity Provider), checkout the tag secure-website.

To view the current time, run the My Website application (see How to run it), and navigate to: http://localhost:8080/time

Creating the Identity Provider

The first step in securing My Website involves creating My Auth Server. This application will function as an Identity Provider for My Website. To achieve this, we will be using Spring Cloud Security, in combination with Spring Security OAuth2.

In OAuth2, the role of Identity Provider is split in two parts. The first part, the Authorization Server, verifies the identity of a resource owner (the user) and provides some kind of access token to applications wanting to act as the user. The second part, the Resource Server, provides resources (e.g. information about the user), based on the given token.

Important

The OAuth2 specification doesn’t state anything about authentication. It basically defines how to delegate authorizations to access protected resources to third parties. In our context: the Authorization Server tells our application(s) that it may act as some user (resource owner), and thus access their data (resources). So how does the Authorization Server know which user it concerns? That’s where Spring Security enters the picture. Spring Security will handle the authentication part, and Spring Security OAuth2 will do the rest. For more general information about user authentication with OAuth2, see here.

With Spring Security OAuth2 it is possible to create two separate applications, one acting as Authorization Server and one as Resource Server. But it is also possible to combine the two parts into one application, which is what we will be doing.

Again, we will use Spring Initializr to bootstrap the application, with the Web and Thymeleaf dependencies, but this time we also add the Cloud OAuth2 dependency. We configure the application to run at http://localhost:9090/auth (see the properties in my-auth-server/src/main/resources/application.yml).

My Auth Server application is configured as both an Authorization Server and Resource Server, and is secured with Spring Security, with the help of a few Spring configurer adapters. These are explained below.

Authorization Server configuration

The AuthorizationServerConfigurer allows you to modify the default configuration (enabled by the annotation @EnableAuthorizationServer) to be able to act as an OAuth2 Authorization Server. Furthermore, we configure the client details service. This service specifies details about the way ‘clients’ (== other applications) interact with the Authorization Server.

...
@Override
public void configure(ClientDetailsServiceConfigurer clients) throws Exception {
    clients.inMemory()                                  // (1)
            .withClient("myauthserver")
            .secret("verysecretpassword")               // (2)
            .redirectUris("http://localhost:8080/")     // (3)
            .authorizedGrantTypes("authorization_code") // (4)
            .scopes("myscope")                          // (5)
            .autoApprove(true);                         // (6)
}
...

...

@Override

public void configure(ClientDetailsServiceConfigurer clients) throws Exception {

clients.inMemory() // (1)

.withClient("myauthserver")

.secret("verysecretpassword") // (2)

.redirectUris("http://localhost:8080/") // (3)

.authorizedGrantTypes("authorization_code") // (4)

.scopes("myscope") // (5)

.autoApprove(true); // (6)

}

...

We configure everything in-memory for simplicity, but it is also possible to get the details from e.g. a database
The client authenticates with the credentials myauthserver / verysecretpassword
Specify the allowed redirect URI patterns, this prevents random parties from gaining an access token (e.g. XSRF attacks)
OAuth2 supports different grant types, of which the Authorization Code type is the most known. For more information about grant types, see here
When a client (application) authorizes with the Authorization Server, the server can assign one or more scopes to the client. In simple terms, a client scope can be seen as a specific permission for this client. With client scopes, it is possible to allow some applications to have more access rights to user resources than other applications. This is out of scope (pun intended) for this article.
It is possible to make the Authorization Server ask the user permission for the client to obtain rights to access their resources. In our case we automatically approve the request.

Resource Server configuration

An application acting as an OAuth2 client to My Auth Server may need to be able to fetch information about a user, given a valid OAuth2 access token. To serve this information, we add a REST Controller, and secure this resource by configuring the My Auth Server as an OAuth2 Resource Server.

The REST Controller is a standard Spring @RestController, with one request mapping:

...
@RequestMapping(value = { "/user" }, produces = "application/json")
public Map<String, Object> user(OAuth2Authentication user) {              // (1)
    Map<String, Object> userDetails = new HashMap<>();
    userDetails.put("user", user.getUserAuthentication().getPrincipal()); // (2)
    userDetails.put("authorities", AuthorityUtils.authorityListToSet(
            user.getUserAuthentication().getAuthorities()));              // (3)
    return userDetails;
}
...

...

@RequestMapping(value = { "/user" }, produces = "application/json")

public Map<String, Object> user(OAuth2Authentication user) { // (1)

Map<String, Object> userDetails = new HashMap<>();

userDetails.put("user", user.getUserAuthentication().getPrincipal()); // (2)

userDetails.put("authorities", AuthorityUtils.authorityListToSet(

user.getUserAuthentication().getAuthorities())); // (3)

return userDetails;

}

...

The currently logged in user is injected by Spring as an OAuth2Authentication object. This is basically a standard Java Principal, with some added OAuth2-specific details.
We return a map containing the current username,
and a set of user roles.

This is the minimal set of details required for a Spring-enabled OAuth2 client to reconstruct its own OAuth2 Principal object. It is possible to add more details here, if needed. Instead of a Map, some examples on the internet just return the Principal object directly. Although this saves you the overhead of creating a map, we feel it exposes too much unnecessary information. With our approach, we are in control of what information is shared about the user.

The next step is to secure this resource. Of course, we can only provide valid user information, if we have a logged in user. Therefore, we configure My Auth Server as an OAuth2 Resource Server, which basically is a server hosting protected resources, capable of serving these resources when presented with a valid access token. In this case, the protected resource is information about the logged in user. The Resource Server security configuration is defined in ResourceServerConfigurer, using the @EnableResourceServer annotation.

...
@Override
public void configure(HttpSecurity http) throws Exception {
    http.antMatcher("/user")     // (1)
            .authorizeRequests()
            .anyRequest()
            .authenticated();    // (2)
}
...

...

@Override

public void configure(HttpSecurity http) throws Exception {

http.antMatcher("/user") // (1)

.authorizeRequests()

.anyRequest()

.authenticated(); // (2)

}

...

We match our security configuration on the URL /user, matching the request mapping in our ResourceController.
Only authenticated access is allowed.

Spring Security configuration

The last step for My Auth Server is to configure the application security, to define how we want our users to authenticate themselves. We use a pretty standard Spring Security setup, but for the sake of completeness, we describe the configuration below.

The WebSecurityConfigurer modifies the default Spring Security configuration (enabled by the annotation @EnableWebSecurity annotation). We configure the URLs to secure, enable Cross-Site Request Forgery protection, setup a login form, and add some user credentials.

...
@Override
protected void configure(HttpSecurity http) throws Exception {
    http
            .authorizeRequests()
                .antMatchers("/login**").permitAll() // (1)
                .anyRequest().authenticated()        // (2)
            .and().csrf()                            // (3)
            .and().formLogin().loginPage("/login");  // (4)
}

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

...

@Override

protected void configure(HttpSecurity http) throws Exception {

http

.authorizeRequests()

.antMatchers("/login**").permitAll() // (1)

.anyRequest().authenticated() // (2)

.and().csrf() // (3)

.and().formLogin().loginPage("/login"); // (4)

}

@Override

protected void configure(AuthenticationManagerBuilder auth) throws Exception {

auth

.inMemoryAuthentication() // (5)

.withUser("user").password("password").roles("USER")

.and()

.withUser("admin").password("admin").roles("USER", "ADMIN");

}

...

The login page is located at /login, and should be publicly available.
All other requests should be authenticated.
Enable Cross-Site Request Forgery (CSRF) protection.
Configure the form login page at /login.
For simplicity, we use an in-memory user database with two users: a normal user and an administrator.

The login form is a simple html form, generated using a Thymeleaf template. The template is located at my-auth-server/src/main/resources/templates/login.html, and made available using a Spring MVC View Controller, defined in my-auth-server/src/main/java/com/jdriven/example/cloudsecurity/config/WebMvcConfigurer.java.

Using the Identity Provider to secure My Website

Now that we have set up our Identity Provider (My Auth Server), we need to configure My Website to use it. This is a very easy task, consisting of three parts.

Spring Cloud Starter OAuth2

We add a dependency in the My Website project to Spring Cloud Starter OAuth2.

...
dependencies {
	compile('org.springframework.cloud:spring-cloud-starter-oauth2')
	...
}
...

...

dependencies {

compile('org.springframework.cloud:spring-cloud-starter-oauth2')

...

}

...

Spring Security Configuration

We configure the security in WebSecurityConfigurer (which is a Spring Web Security Configurer Adapter), using the @EnableOAuth2Sso annotation to enable OAuth2. The security configuration itself is pretty straightforward.

...
@Override
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            .antMatchers("/").permitAll()   // (1)
            .anyRequest().authenticated();  // (2)
}
...

...

@Override

protected void configure(HttpSecurity http) throws Exception {

http.authorizeRequests()

.antMatchers("/").permitAll() // (1)

.anyRequest().authenticated(); // (2)

}

...

Allow navigating to the index page at /.
Secure all the other URLs.

Application configuration

The last step is to add some properties to our application configuration in application.yml. These properties configure My Website to use the URLs provided by My Auth Server.

...
security:
  oauth2:
    client:
      accessTokenUri: http://localhost:9090/auth/oauth/token           // (1)
      userAuthorizationUri: http://localhost:9090/auth/oauth/authorize // (2)
      clientId: myauthserver                                           // (3)
      clientSecret: verysecretpassword                                 // (4)
    resource:
      userInfoUri: http://localhost:9090/auth/user                     // (5)
...

...

security:

oauth2:

client:

accessTokenUri: http://localhost:9090/auth/oauth/token // (1)

userAuthorizationUri: http://localhost:9090/auth/oauth/authorize // (2)

clientId: myauthserver // (3)

clientSecret: verysecretpassword // (4)

resource:

userInfoUri: http://localhost:9090/auth/user // (5)

...

The URL used by an OAuth2 client to acquire an OAuth2 access token.
The URL to which the user will be redirected to authorize access to a resource.
The client ID specified earlier in the Authorization Server configuration.
The client password specified earlier in the Authorization Server configuration.
The user info resource URL, specified earlier in the Resource Server configuration.

Tip To see the resulting source code at this point, checkout the Git tag secure-website.

That’s it! If we run both the My Auth Server application and the My Website application (see How to run it), and navigate to http://localhost:8080/time, we will see that the URL is now secured, and we need to login first. Congratulations, your website is now secure!

Up next

In the next articles in this series, we will discuss the following topics:

After having secured a single application, we will add a new application, a REST service, which we will also secure through My Auth Server in a Single Sign On (SSO) configuration.
We will call the REST service from the browser using client side Javascript, proxying the service calls through My Website using Netflix Zuul.
Then, we will make the REST service stateless (no sessions), remaining secure by using JSON Web Tokens (JWT).
Finally, we will add the ability to login using a Google account.

Spicy Spring: Create New Projects From a URL

Posted on March 17, 2016 by mrhaki

To quickly start with a Spring project we can use the website start.spring.io. Via a user interface we can set project properties and at the end we have a project archive (Zip or gzipped Tar file) or build file (pom.xml or build.gradle). We can also directory access an URL to create the output files and we set the properties via request parameters. This way you can share a link with someone and if they click on it they will download the generated project archive or build files.

Continue reading →

Spicy Spring: Java System Properties As Configuration Properties With Spring Boot

Posted on September 30, 2015 by mrhaki

In a previous post we learned that configuration property values can be passed via environment variables. With Spring Boot we can also pass the values using Java system properties. So if we have a property sample.message then we can use -Dsample.message=value to pass a value when we run the application. If we use the Spring Boot Gradle plugin we must reconfigure the bootRun task to pass Java system properties from the command-line.

Continue reading →

Spicy Spring: Setting Configuration Properties Via Environment Variables

Posted on September 25, 2015 by mrhaki

Spring Boot has many options for externalising the configuration of our application. One of the options it to use OS environment variables. We need to follow certain rules to name the environment variable and then Spring Boot will use the value of variable to set a configuration property. The property name must be in uppercase and any dots need to be replaced with underscores. For example the configuration property sample.message is set with the environment variable SAMPLE_MESSAGE. This feature can be useful in a continuous integration environment where we can set environment variables or just when developing locally. The nice thing is that this also works when we use the Spring Boot Gradle plugin. The environment variables are passed on to the Java process that the bootRun task starts.

Continue reading →

Spicy Spring: Report Applied Auto-configuration Spring Boot

Posted on September 24, 2015 by mrhaki

The auto-configuration feature in Spring Boot adds beans to our application context based on conditions. For example based on the availability of a class on the class path or a environment property beans are enabled or disabled. We must apply the @EnableAutoConfiguration or @SpringBootApplicaiton in our Spring Boot application to make this work. To get an overview of all the configurations that had positive and negative conditional matches in our application we can use the --debug command-line option. This will print out a report to System.out with a complete overview. We can check why a configuration is applied or not.

Continue reading →

Spicy Spring: Reload Classes Spring Boot With Spring Loaded And Gradle Continuous Build

Posted on September 23, 2015 by mrhaki

When we develop a Spring Boot application we can hot reload newly compiled classes using Gradle. The bootRun task of the Spring Boot Gradle plugin has support for Spring Loaded. We must add a dependency to Spring Loaded as a dependency for the classpath configuration in the buildscript block. If we now use the bootRun task everything is ready to reload changed classes. Now we can use the continuous build feature of Gradle to listen for changes in our source files to recompile them. The recompiled classes are then reloaded in the running Spring Boot application started with bootRun. We start a second Gradle instance with the -t option for the classes task. This way when we change a source file it gets recompiled automatically and reloaded.

Continue reading →

Spicy Spring: Create your own ResourceLoader

Posted on September 4, 2015 by Willem Cheizoo

As a Spring developer we know how to load a resource in a Service. The prefixes of classpath: and file: are commonly used. But what if we want to load resources from a different location like a database table RESOURCE, with our own prefix db:?

The Spring Framework provides some default built-in resource implementations, which can be found in the chapter Resources in the Spring Framework Reference Guide. The URL is prefixed and handled by the corresponding ResourceLoader (JavaDoc).

If we want to load a resource from a database table RESOURCE we have to create our own ResourceLoader which triggers on the prefix db:.
Continue reading →

Spicy Spring: Using @Value for Constructor Arguments

Posted on April 19, 2015 by mrhaki

In Spring we can use the @Value annotation to set property or arguments values based on a SpEL expression. If we want to use the @Value annotation for a constructor argument we must not forget to add the @Autowired annotation on the constructor as well.

// File: sample/Message.groovy
package sample

import org.springframework.beans.factory.annotation.*
import org.springframework.stereotype.*

@Component
class Message {

    final String text

    // Use @Autowired to get @Value to work.
    @Autowired
    Message(
        // Refer to configuration property
        // app.message.text to set value for 
        // constructor argument text.
        @Value('${app.message.text}') final String text) {
        this.text = text
    }

}

// File: sample/Message.groovy

package sample

import org.springframework.beans.factory.annotation.*

import org.springframework.stereotype.*

@Component

class Message {

final String text

// Use @Autowired to get @Value to work.

@Autowired

Message(

// Refer to configuration property

// app.message.text to set value for

// constructor argument text.

@Value('${app.message.text}') final String text) {

this.text = text

}

Written with Spring 4.1.6.

Original article

Spicy Spring : Dynamically create your own BeanDefinition

Posted on April 16, 2015 by Willem Cheizoo

When we a have Spring managed application, we want to let Spring manage all of our beans. Beside the regular way of creating beans with known solutions like Annotated beans, Java Configuration and XML Configuration, there is also a way in which we can create our own BeanDefinition.

With a BeanDefinitionRegistryPostProcessor it is possible to create a specific post processor which can add BeanDefinitions to the BeanDefinitionRegistry.
It differs from the BeanPostProcessor, which only has hooks for Bean Initialization (construction of your POJO), where the BeanDefinitionRegistryPostProcessor has a hook on the BeanDefinitionRegistry. This gives us the ability to define our own BeanDefinition.

First we create a BeanDefinitionRegistryPostProcessor implementation as listed in the example. We implement the required method, and will be able to add our own bean definition to the registry. The defined BeanDefinition will be picked up by the ApplicationContext and the POJO will be constructed. Our result is A Spring managed bean

package com.jdriven;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.support.BeanDefinitionRegistry;
import org.springframework.beans.factory.support.BeanDefinitionRegistryPostProcessor;
import org.springframework.beans.factory.support.RootBeanDefinition;
import org.springframework.stereotype.Component;

@Component
public class LogicServiceRegistryPostProcessor 
        implements BeanDefinitionRegistryPostProcessor {

    @Override
    public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry)
            throws BeansException {

        RootBeanDefinition beanDefinition = 
                new RootBeanDefinition(MyServiceImpl.class); //The service implementation
        serviceDefinition.setTargetType(MyService.class); //The service interface
        serviceDefinition.setRole(BeanDefinition.ROLE_APPLICATION);
        registry.registerBeanDefinition("myBeanName", beanDefinition );
    }
}

package com.jdriven;

import org.springframework.beans.BeansException;

import org.springframework.beans.factory.support.BeanDefinitionRegistry;

import org.springframework.beans.factory.support.BeanDefinitionRegistryPostProcessor;

import org.springframework.beans.factory.support.RootBeanDefinition;

import org.springframework.stereotype.Component;

@Component

public class LogicServiceRegistryPostProcessor

implements BeanDefinitionRegistryPostProcessor {

@Override

public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry)

throws BeansException {

RootBeanDefinition beanDefinition =

new RootBeanDefinition(MyServiceImpl.class); //The service implementation

serviceDefinition.setTargetType(MyService.class); //The service interface

serviceDefinition.setRole(BeanDefinition.ROLE_APPLICATION);

registry.registerBeanDefinition("myBeanName", beanDefinition );

}

Spicy Spring : Different ways of Autowiring

Posted on March 23, 2015 by Willem Cheizoo

I would like to show different ways of using Spring’s @Autowired annotation: Constructor, Method and Field autowiring.
The examples I show are all a form of byType autowiring mode (constructor autowiring mode is Analogous to byType). Take a look at the Spring Reference guide for more information on the Autowiring modes.

Constructor Autowiring

Create a constructor with a dependent bean as constructor parameter and add the @Autowired annotation to the constructor. A big advantage of autowiring by constructor is that the field can be made final, and therefore may not be changed after construction.

package com.jdriven;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Component
public class AutowiredCapabilityBean
{
    //The InjectableBean can be made final
    private final InjectableBean injectableBean; 
    
    //The InjectableBean is autowired byType and is required.
    //An error is thrown when no bean or multiple beans of InjectableBean exist
    @Autowired
    public AutowiredCapabilityBean(InjectableBean injectableBean) {
        this.injectableBean = injectableBean;
    }
}

package com.jdriven;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.stereotype.Component;

@Component

public class AutowiredCapabilityBean

{

//The InjectableBean can be made final

private final InjectableBean injectableBean;

//The InjectableBean is autowired byType and is required.

//An error is thrown when no bean or multiple beans of InjectableBean exist

@Autowired

public AutowiredCapabilityBean(InjectableBean injectableBean) {

this.injectableBean = injectableBean;

}

Method Autowiring

Create a setter method for the dependent bean and add the @Autowired annotation to the setter method. A disadvantage of using Method autowiring is that the setter can be called in production code, overriding the bean accidentally.

package com.jdriven;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Component
public class AutowiredCapabilityBean
{
    private InjectableBean injectableBean; 

    //No explicit constructor is needed. The default constructor is used.
    
    //The InjectableBean is autowired byType, but is not required.
    @Autowired
    public void setInjectableBean(InjectableBean injectableBean) {
        this.injectableBean = injectableBean;
    }
}

package com.jdriven;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.stereotype.Component;

@Component

public class AutowiredCapabilityBean

{

private InjectableBean injectableBean;

//No explicit constructor is needed. The default constructor is used.

//The InjectableBean is autowired byType, but is not required.

@Autowired

public void setInjectableBean(InjectableBean injectableBean) {

this.injectableBean = injectableBean;

}

Field Autowiring

Create a field (member variable) for the dependent bean and add the @Autowired annotation to the field. This way of Autowiring has less code, but takes more effort to test the AutowiredCapabilityBean with an implementation of the InjectableBean, since there is no constructor and no setter for it.

package com.jdriven;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Component
public class AutowiredCapabilityBean
{
    //The InjectableBean is autowired byType and is required.
    @Autowired
    private InjectableBean injectableBean; 
    
    //No explicit constructor is needed. The default constructor is used.
}

package com.jdriven;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.stereotype.Component;

@Component

public class AutowiredCapabilityBean

{

//The InjectableBean is autowired byType and is required.

@Autowired

private InjectableBean injectableBean;

//No explicit constructor is needed. The default constructor is used.

}