Having secured the frontend and also embedded a session ID in every gateway call to the backend, we can shift our focus to securing those backend services.

Let's start with the images service. First of all, we need to configure session management by creating SessionConfig as follows:

    @EnableMongoWebSession 
    public class SessionConfig { 
 
    } 

This preceding code can be described as follows:

• @EnableMongoWebSession activates the Reactor-based Spring Session MongoDB

Next, we can lock things down by creating a SecurityConfiguration class like this:

    @EnableWebFluxSecurity 
    @EnableReactiveMethodSecurity 
    public class SecurityConfiguration { 
 
      @Bean 
      SecurityWebFilterChain springWebFilterChain() { 
        return HttpSecurity.http() 
            .securityContextRepository( 
                new WebSessionSecurityContextRepository()) 
            .authorizeExchange() 
                .anyExchange().authenticated() 
                .and() 
            .build(); 
      } 
    } 

The preceding class definition can be described as follows:

• @EnableWebFluxSecurity activates a collection of filters and components needed to secure Spring WebFlux endpoints.
• @EnableReactiveMethodSecurity adds additional support for putting annotations on methods and classes where we can plug in sophisticated security expressions (as we'll soon see).
• Next, we create a SecurityWebFilterChain. This is, actually, a collection of filters defined in a very specific order using Spring Security's fluent API. This API nicely lets us define what we need while leaving Spring Security to put it together in the right order.
• In this case, we want HTTP support, but with a WebSession-based SecurityContextRepository. This activates a filter that will load the exchange with a Principal object from our session store.
• As a minimum for authorization, all exchanges must be authenticated.

Some of this is the same as earlier, and some of it is different.

What's different? The images service has method security, meaning, it can annotate individual methods with additional authorization rules, which we'll see shortly. We are no longer confined to securing things based on URLs and HTTP verbs. There are also no account definitions. That's because the images service is not creating new sessions, but riding on the one created in the gateway by the chat microservice instead; (do we really want to create a separate User domain object in every microservice?).

Both services respond to Authorization headers as well as SESSION headers, which means that once logged in, the two can easily share information. Both, essentially, route all URLs into the same authorization rule, .anyExchange().authenticated(). (That's the same net effect as that of .pathMatchers("/**").authenticated()).