Chapter 12. Securing an API

Security is one of the most commonly discussed problems related to microservices-based architecture. There is always one main problem for all security concerns—a network. With microservices, where typically there is much more communication over the network than there is for monolithic applications, the approach to authentication and authorization should be reconsidered. Traditional systems are usually secured at the border and then allow the frontend service full access to the backend components. The migration to microservices forces us to change this approach to delegated-access management.

How does Spring Framework address the security concerns of microservices-based architecture? It provides several projects that implement different patterns regarding authentication and authorization. The first of these is Spring Security, which is a de facto standard for secure Spring-based Java applications. It consists of a few submodules that help you get started with SAML...

Enabling HTTPS for Spring Boot

If you want to use SSL and serve your RESTful APIs over HTTPS, you will need to generate a certificate. The fastest way to achieve this is through a self-signed certificate, which is enough for development mode. JRE provides a simple tool for certificate management—keytool. It is available under your JRE_HOME\bin directory. The command in the following code generates a self-signed certificate and puts it into the PKCS12 KeyStore. Besides KeyStore's type, you will also have to set its validity, alias, and the name of the file. Before starting the generation process, keytool will ask you for your password and some additional information, as follows:

keytool -genkeypair -alias account-key -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore account-key.p12 -validity 3650

Enter keystore password:
Re-enter new password:
What is your first and last name?
 [Unknown]: localhost
What is the name of your organizational unit?
 [Unknown]: =
What is the name of your organization...

Secure discovery

As you can see, the configuration of SSL for a microservice application is not a very hard task. However, it is time to increase the difficulty level. We have already launched a single microservice that serves a RESTful API over HTTPS. Now we want that microservice to integrate with the discovery server. There are two problems that arise from this. The first of these is the need to publish information about the secure microservice's instance in Eureka. The second of these concerns exposing Eureka over HTTPS and forcing the discovery client to authenticate against a discovery server using a private key. Let's discuss these issues in detail.

Registering a secure application

If your application is exposed over a secure SSL port, you should change two flags from the EurekaInstanceConfig—nonSecurePortEnabled to false and securePortEnabled to true. This forces Eureka to publish instance information that shows an explicit preference for secure communication. The Spring Cloud DiscoveryClient...

Secure configuration server

There is one other key element in our architecture that should be considered during our discussion about security—the Spring Cloud Config Server. I would say that it is even more important to protect the config server than the discovery service. Why? Because we usually store their authentication credentials to the external systems, along with other data that should be hidden from unauthorized access and usage. There are several ways to properly secure your config server. You may configure an HTTP basic authentication, a secure SSL connection, encrypt/decrypt sensitive data, or use third-party tools such as those already described in Chapter 5, Distributed Configuration with Spring Cloud Config. Let's take a closer look at some of them.

Encryption and decryption

Before we begin, we have to download and install the Java Cryptography Extension (JCE) provided by Oracle. It consists of two JAR files (local_policy.jar and US_export_policy.jar), which need to override...

Authorization with OAuth2

We have already discussed some concepts and solutions related to authentication in a microservices environment. I have shown you the examples of basic and SSL authentication between microservices and a service discovery, and also between microservices and a config server. In inter-service communication, authorization seems to be more important then authentication, which is instead implemented on the edge of the system. It's worth understanding the difference between authentication and authorization. Simply put, authentication verifies who you are, while authorization verifies what you are authorized to do.

Currently the most popular authorization methods for RESTful HTTP APIs are OAuth2 and Java Web Tokens (JWT). They may be mixed together as they are rather more complementary than other solutions. Spring provides support for OAuth providers and consumers. With Spring Boot and Spring Security OAuth2, we may quickly implement common security patterns, such as single...

Summary

There wouldn't have been anything wrong if I had included a security section in every single chapter from part two of this book. But I have decided to create a dedicated chapter on this subject in order to show you a step-by-step process of how to secure the key elements of a microservices-based architecture. The topics related to security are usually more advanced than other topics, so I took a bit more time to explain some of the basic concepts around the field. I have shown you samples illustrating a two-way SSL authentication, encryption/decryption of sensitive data, Spring Security authentication, and OAuth2 authorization with JWT tokens. I will leave it to you to decide which of them should be used in your system architecture to provide your desired level of security. 

After reading this chapter, you should be able to set up both the basic and the more advanced security configurations for your application. You should also be able to secure every component of your system's architecture...