With the release of Java 9, and the introduction of Project Jigsaw (the Java Platform Module System), we no longer have the need for a full-blown JRE to run our Java applications. It is now possible to construct a stripped-down Java Runtime, containing the minimum set of required modules. This allows us to create slim Docker containers without excess baggage.
The source code belonging to this blog post can be found at: https://github.com/rlippolis/java9-runtime-image
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:
|
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.
To be able to run the applications, the following software is required:
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:
|
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.
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
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.
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
... @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) } ... |
myauthserver / verysecretpasswordAn 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:
|
1 2 3 4 5 6 7 8 9 10 |
... @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; } ... |
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.
|
1 2 3 4 5 6 7 8 9 |
... @Override public void configure(HttpSecurity http) throws Exception { http.antMatcher("/user") // (1) .authorizeRequests() .anyRequest() .authenticated(); // (2) } ... |
/user, matching the request mapping in our ResourceController.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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
... @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"); } ... |
/login, and should be publicly available./login.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.
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.
We add a dependency in the My Website project to Spring Cloud Starter OAuth2.
|
1 2 3 4 5 6 |
... dependencies { compile('org.springframework.cloud:spring-cloud-starter-oauth2') ... } ... |
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.
|
1 2 3 4 5 6 7 8 |
... @Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers("/").permitAll() // (1) .anyRequest().authenticated(); // (2) } ... |
/.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.
|
1 2 3 4 5 6 7 8 9 10 11 |
... 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) ... |
| 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!
In the next articles in this series, we will discuss the following topics:
If you have read my previous post about caching, The (non)sense of caching, and have not been discouraged by it, I invite you to build your own cache. In this post we will build a simple cache implementation that refreshes its data automatically, using Java EE features.
Let’s describe the situation. We are building a service that uses an external resource with some reference data. The data is not frequently updated and it’s allright to use data that’s up to 1 hour old. The external resource is very slow, retrieving the data takes about 30 seconds.
Our service needs to respond within 2 seconds. Obviously we can’t call the resource each time we need it. To solve our problem we decide to introduce some caching. We are going to retrieve the entire dataset, keep it in memory and allow retrieval of specific cached values by their corresponding keys.
A very basic implementation of a key-value cache is a (java.util.)Map, so that’s where we’ll start. One step at a time we will extend this implementation untill we have a fully functional cache.
|
1 2 3 |
public class MyFirstCache { private Map cache; } |
We will inject a bean that serves as a facade to our slow external resource. To keep things simple in this example, the bean returns a list of SomeData objects that contain a key and a value.
|
1 2 3 4 5 6 7 8 9 10 11 |
@Inject MySlowResource mySlowResource; private Map<String, String> createFreshCache() { Map<String, String> map = new HashMap<>(); List<SomeData> dataList = mySlowResource.getSomeData(); for (SomeData someData : dataList) { map.put(someData.getKey(), someData.getValue()); } return map; } |
Now we can populate the cache we need to keep the state so that future requests can also make use of it. That’s where we use the Singleton bean. A singleton session bean is instantiated once per application and exists for the lifecycle of the application, see also the JEE tutorial page about Session Beans.
Note that, when we run our application in a clustered environment, each instance of our application will have its own Singleton bean instance.
|
1 2 |
@Singleton public class MyFirstCache { |
Note that, when we run our application in a clustered environment, each instance of our application will have its own Singleton bean instance.
We can use the @PostConstruct annotation to fill the cache with the reference data when the bean is created. If we want the cache to load at application startup instead of on first access, we use the @Startup annotation.
|
1 2 3 4 5 6 7 8 |
@Startup @Singleton public class MyFirstCache { @PostConstruct private void populateCache(){ cache = createFreshCache(); } |
To make the data available, we create a public method getData, that will retrieve the cached value by its key.
|
1 2 3 |
public String getData(String key){ return cache.get(key); } |
As the cached data becomes outdated over time, we want to refresh the het dataset automatically after a specified time period. JEE offers a solution with automatic timers. See also the JEE tutorial page about the Timer Service. We configure the timer to be not persistent.
|
1 2 3 4 5 |
@Schedule(minute = "*/30", hour = "*", persistent = false) @PostConstruct private void populateCache(){ cache = createFreshCache(); } |
Finally, we need to make sure concurrency is handled correctly. In JEE, you can do this either Container-Managed or Bean-Managed. For Singleton Session Beans the default is Container-Managed Concurrrency with a Write Lock on each public method. Whenever the bean is called, all subsequent calls will be held until the lock is released. This is safe, even if you are modifying the data, hence the name Write Lock.
We can improve on this by allowing concurrent read acces on methods that are only reading data, in our case the getData method. To do that we add the @Lock(LockType.READ) annotation. This way, calls to the getData method are only held when a method with a Write Lock is being accessed.
|
1 2 3 4 |
@Lock(LockType.READ) public String getData(String key){ return cache.get(key); } |
(In our simple case we could get away without any locking at all because updating the object reference of our instance variable cache in the populateCache method is an atomic operation, but in practice you don’t want to depend on implementation details of the populateCache method.)
For more information about Container-Managed Concurrency check the JEE tutorial page about Managing Concurrent Access.
Above example code is perfeclty usable, but there are several things to consider:
We have created a simple cache with a minimal amount of code. By making use of built-in Java EE features, a lot of complex tasks are managed by the JEE container, making our job easier.
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 (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.
I am still settling down from an awesome week in Sweden, where I went for the JFokus conference and subsequent speaker conference. Both were of epic proportions, and I would like to share my experience of giving a presentation there that I would not soon forget. Continue reading
Asciidoctor is a great tool for writing technical documentation. The documentation to our Java source is what we write in Javadoc comments. Wouldn’t it be nice if we could use Asciidoctor in our Javadoc comments? Of course! We can achieve this with the Asciidoclet Javadoc doclet. The doclet processes the Javadoc comments as Asciidoctor source and generates HTML in the final Javadoc documentation. We can use all of Asciidoc syntax like tables, lists, include directives, styling and more. We can even use Asciidoctor extensions like asciidoctor-diagram.
Ratpack applications can be written in Java and Groovy. The Java API is already very clean and on top is a Groovy DSL to work with Ratpack. When we use Groovy we can use the DSL, which allows for more clean code. The Ratpack developers have used the @DelegateTo annotation in the source code for the DSL definition. The annotation can be used to indicate which class or interface is used as delegate to execute the closure that is passed to the method. And this helps us a lot in the code editor of IntelliJ IDEA, because IDEA uses this information to give us code completion when we use the Groovy DSL in Ratpack. And that makes using the DSL very easy, because we rely on the IDE to give us the supported properties and methods and we make less mistakes.
There is a catch when we define a constant field in Groovy. Rob Fletcher blogged about this in the post Groovy the public keyword a while ago. When we omit the public keyword for a method then the method is still accessible as public method, because Groovy makes the method public when the class is compiled. When we leave out the public keyword for fields Groovy creates a getter and setter method for the field at compile time and turns it into a property that applies to the Java Bean specification. This is also true if the field is static. So if we define a constant value as static final we must keep in mind that Groovy will generate a getter method so the constant value is a read only property according to Java Bean specification.
For Java or Groovy projects we can use the application plugin in Gradle to run and package our application. The plugin adds for example the startScripts task which creates OS specific scripts to run the project as a JVM application. This task is then used again by the installDist that installs the application, and distZip and distTar tasks that create a distributable archive of the application. The startScripts tasks has the properties unixScript and windowsScript that are the actual OS specific script files to run the application. We can use these properties to change the contents of the files.
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
// 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.