Before we can dig into those nice security policies and authorization rules we just talked about, we need a solution to secure multiple microservices.

What is the exact problem? When we log in to the first piece of our social media platform, we want that status to be carried through to the other components with ease.

The solution is Spring Session (http://projects.spring.io/spring-session/), which supports multiple third-party data stores to offload session state including Redis, MongoDB, GemFire, Hazelcast, and others. Instead of the session data being stored in memory, it is externalized to a separate data store.

This provides multiple benefits such as the following:

• Provides scalability when running multiple instances of various services
• Avoids the need for session affinity (sticky sessions) by not requiring load balancers to route clients to the same instance
• Leverages a data store's built-in expiration options (if desired)
• Multi-user profiles

There is one other, hidden benefit that we will take immediate advantage of in this chapter--sharing session state between different microservices. Log in to the user-facing microservice, create a session with that security state, and share the session with all microservices. Bam! Automatic access.

Since we are already using MongoDB, let's use that to also store our session.

The first thing we need to do in getting Spring Session off the ground is to update each microservice with the following dependencies:

    compile('org.springframework.boot:spring-boot-starter-security-
     reactive') 
    compile('org.springframework.session:spring-session-data-mongodb') 

These preceding dependencies can be described as follows:

• spring-boot-starter-security-reactive brings in all the configuration support we need to define a security policy, including some critical annotations, as well as Spring WebFlux-based security components to implement our policy, including various filters
• spring-session-data-mongodb will bring in Spring Session MongoDB and Spring Data MongoDB, making it possible to write session data to our MongoDB service reactively

To configure Spring Session to use MongoDB, we need the following added to each microservice:

    @EnableMongoWebSession 
    public class SessionConfig { 
 
    } 

This new SessionConfig class does the following:

• @EnableMongoWebSession activates Spring Session MongoDB, signaling to use MongoDB as the place to read and write any session data

This is all it takes to enable using MongoDB for session data. However, there are some lingering issues we have to sort out due to the structure of our microservice-based application that bars us from moving forward.

We used this code in the previous chapter:

    Map<String, CorsConfiguration> corsConfigurationMap = 
      new HashMap<>(); 
    CorsConfiguration corsConfiguration = new CorsConfiguration(); 
    corsConfiguration.addAllowedOrigin("http://localhost:8080"); 
    corsConfigurationMap.put( 
      "/topic/comments.new", corsConfiguration); 
    corsConfigurationMap.put( 
      "/app/chatMessage.new", corsConfiguration); 
    corsConfigurationMap.put( 
      "/topic/chatMessage.new", corsConfiguration); 

To make our WebSocket chat microservice integrate with the images-based web page, we needed addAllowedOrigin("http://localhost:8080"). That way, a web request from a service on port 8080 was permitted to cross over to a service on port 8200.

When it comes to security and sessions, stitching together two different services on two different ports in the browser isn't the best way to approach things. Not only is it technically daunting, it is really a code smell--a hint that our application is leaking too much of its structure to the outside world.

The solution is to create a Gateway API.