As you know, microservices are the components that we deploy in on-premises or cloud infrastructure. Microservices may offer APIs or web applications. Our sample application, OTRS, offers APIs. This chapter will focus on how to secure these APIs using Spring Security and Spring OAuth2. We'll also focus on OAuth 2.0 fundamentals. We'll use OAuth 2.0 to secure the OTRS APIs. For more understanding on securing REST APIs, you can refer to RESTful Java Web Services Security, Packt Publishing book. You can also refer to Spring Security [Video], Packt Publishing video, for more information on Spring Security. We'll also learn about Cross Origin Request Site filters, and cross-site scripting blockers.
In this chapter, we will cover the following topics:
- Enabling Secure Socket Layer (SSL)
- Authentication and authorization
- OAuth 2.0
So far, we are using the Hyper Text Transfer Protocol (HTTP). HTTP transfers data in plain text, but data transfer over the Internet in plain text is not a good idea at all. It makes hackers' jobs easy and allows them to get your private information, such as your user ID, passwords, and credit card details easily using a packet sniffer.
We definitely don't want to compromise user data, so we will provide the most secure way to access our web application. Therefore, we need to encrypt the information that is exchanged between the end user and our application. We'll use Secure Socket Layer (SSL) or Transport Security Layer (TSL) to encrypt the data.
SSL is a protocol designed to provide security (encryption) for network communications. HTTP associates with SSL to provide the secure implementation of HTTP, known as Hyper Text Transfer Protocol Secure, or Hyper Text Transfer Protocol over SSL (HTTPS). HTTPS makes sure that the privacy and integrity of the exchanged data is protected. It also ensures the authenticity of websites visited. This security centers around the distribution of signed digital certificates between the server hosting the application, the end user's machine, and a third-party trust store server. Let's see how this process takes place:
- The end user sends the request to the web application, for example http://twitter.com, using a web browser.
- On receiving the request, the server redirects the browser to https://twitter.com using the HTTP code 302.
- The end user's browser connects to https://twitter.com and, in response, the server provides the certificate containing the digital signature to the end user's browser.
- The end user's browser receives this certificate and sends it to a trusted Certificate Authority (CA) for verification.
- Once the certificate gets verified all the way to the root CA, an encrypted communication is established between the end user's browser and the application hosting server.
Secure HTTP communication
Now, after going over the basics of SSL, let's implement it for our sample OTRS project. We don't need to implement SSL for all microservices. All microservices will be accessed using our proxy or edge server; Zuul-server by the external environment, except our new microservice, security-service, which we will introduce in this chapter for authentication and authorization.
First, we'll set up SSL in edge server. We need to have the keystore that is required for enabling SSL in embedded Tomcat. We'll use the self-signed certificate for demonstration. We'll use Java keytool to generate the keystore using the following command. You can use any other tool also:
keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -ext san=dns:localhost -storepass password -validity 365 -keysize 2048
It asks for information such as name, address details, organization, and so on (see the following screenshot):
The keytool generates keys
Be aware of the following points to ensure the proper functioning of self-signed certificates:
- Use
–extto define Subject Alternative Names (SAN). You can also use IP (for example,san=ip:190.19.0.11). Earlier, use of the hostname of the machine, where application deployment takes place was being used as most common name (CN). It prevents thejava.security.cert.CertificateExceptionforNo name matching localhost found. - You can use a browser or OpenSSL to download the certificate. Add the newly generated certificate to the cacerts keystore located at
jre/lib/security/cacertsinside activeJDK/JREhome directory by using thekeytool –importcertcommand. Note thatchangeitis the default password for the cacerts keystore. Run the following command:keytool -importcert -file path/to/.crt -alias <cert alias> -keystore <JRE/JAVA_HOME>/jre/lib/security/cacerts -storepass changeitTip
Self-signed certificates can be used only for development and testing purposes. The use of these certificates in a production environment does not provide the required security. Always use the certificates provided and signed by trusted signing authorities in production environments. Store your private keys safely.
Now, after putting the generated keystore.jks in the src/main/resources directory of the OTRS project, along with application.yml, we can update this information in EdgeServer application.yml as follows:
server:
ssl:
key-store: classpath:keystore.jks
key-store-password: password
key-password: password
port: 8765Rebuild the Zuul-server JAR to use the HTTPS.
Similarly, you can configure SSL for other microservices.