Spring Security with Spring-Boot-based Microservices

Spring Security is an authentication and authorization framework for Java-EE-based applications. It provides a comprehensive set of features that handle your security requirements and also offers extension points in order to apply application-specific customizations easily. We will use Spring Boot to create Spring-based applications, and we will use the starter kit for Spring Security that Spring Boot provides.

At the time of writing, the current version of Spring Boot is 2.0.0.RELEASE.

Spring Boot simplifies the process of applying security measures to the application by simply adding its dependency to the Maven POM file:

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
<version>2.0.0.RELEASE</version>
</dependency>
Version 2.0.0.RELEASE of spring-boot-starter-security defines Spring security version 5.0.3.RELEASE as a transitive dependency under the hood.

When the spring-boot-starter-security artifact is added to the classpath, the entire application is protected with HTTP Basic Authentication.

HTTP Basic Authentication is one of the most widely used authentication mechanisms; it secures web resources by requesting the username and password sent by a client. It uses standard fields in the HTTP header and doesn't require any cookies or session identifiers. With HTTP Basic Authentication, the username and password are passed as Base64-encoded, and due to Base64 being a reversible encoding mechanism, it's important to mention that the HTTP Basic Authentication scheme is not secure and HTTPS/TLS should be used in conjunction with it to secure the transport layer.

To secure a Spring-Boot-based REST service implementation, we are going to use the same implementation that we had in Chapter 2, Creating Your First Microservice and we will just add the spring-boot-starter-security dependency. The WeatherServiceApplication class contains the following executable main() method. The example contains the temperature Microservice implemented in Chapter 2, Creating Your First Microservice.

@SpringBootApplication
public class WeatherServiceApplication {
public static void main(String[] args) {
SpringApplication.run(WeatherServiceApplication.class);
}
}

After executing the method on WeatherServiceApplication and requesting the http://localhost:8080/temperature REST endpoint, we'll come across the following login page:

By accessing a secured endpoint, we will be prompted with a login page that asks us to input our credentials. The default User Name for this login will be user.  The Password will be printed on the console while executing the main() method as:

Using default security password: 7b559a60-1673-4308-8dd4-c441732b0c70

It's a password that was generated randomly while the application was starting so it should change at each execution of the method. It's also possible to request the endpoint with curl by providing the credentials, as follows:

curl -u user:7b559a60-1673-4308-8dd4-c441732b0c70 http://localhost:8080/temperature

Having dynamically generated a password for your application will not necessarily get it into a production-ready state, so you set the password could by providing the username and password through a configuration file. Spring Boot has a key-value file template, application.properties, to externalize the configuration and it should reside under the root folder of the classpath by default. In our example, its content will define the default username and its corresponding password as follows:

spring.security.user.name=user
spring.security.user.password=secret

After creating this properties file under the src/main/resources folder of our application, we can try to request the endpoint with Postman (https://www.getpostman.com) this time. To provide the credentials, we need to set the authentication type as Basic Auth and provide the Username and Password defined in the properties file. The final task should be to update the request before clicking the Update Request button:

As you can see on the Headers tab in the following image, the Authorization header is set to Basic type along with a Base64-encoded value:

If we decode that encoded value, we will see that the Username and Password are concatenated with :, as follows:

user:secret

In a real-world scenario, you will probably want to match your user's credentials across to a database or an LDAP realm, instead of a configuration file. To tighten your security measures, we will look at an example for an In-memory user realm, and then enhance it with a database-based realm.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.22.61.218