Hands-On Spring Security 5 for Reactive Applications

It's important that you understand how we will be using examples in this book. Since the book tries to give lots of detail on Spring Security 5 and its reactive aspects, we will not have a single use case throughout the book. Instead, we will keep creating small projects to help you understand each of the core concepts covered. Here are some of the important aspects of the code base within this book:

Here are some of the core new application requirements:

With technology in everyone's hands (in some form or another, most people use technology), users are quite well-versed in privacy policies and application security. They are aware of most of the security requirements, and companies take time to educate users about the importance of security and the ways they should look for security flaws in applications. You might already know that if a site runs on HTTP as opposed to HTTPS (SSL) and Chrome tags, these sites quite clearly show the users as Not Secure in the address bar. With more people becoming knowledgeable about technology, these aspects are well-known among the majority of users and security has become one of the most talked about subjects in the IT landscape.

Another important aspect is data privacy. Some users are not concerned about sharing their data but some are quite reticent. Many governments recognize this fear and have started making many rules and regulations in this space. One such data privacy rule is the well-known General Data Protection Regulation (GDPR), which has been enforced since May 25th, 2018.

The European Union (EU) GDPR replaces the Data Protection Directive 95/46/EC and was designed to harmonize data privacy laws across Europe, to protect and empower all EU citizen's data privacy and to reshape the way organizations across the region approach data privacy. For more information, you can check this link: https://gdpr-info.eu/art-99-gdpr/.

Modern browsers have also given us enough tools to look at many aspects of a web application in a more detailed manner with regards to security. In addition, browsers have been enhanced with more and more features (for example, a cookie was once one of the options for storing data, but now we have other options, such as localStorage and indexedDB), making it more vulnerable to security breaches and attacks from an ever-open hacker sitting on the sidelines.

To achieve these various application requirements, organizations go to public cloud providers instead of their own on-premise datacenters. This puts applications in a more vulnerable state and security aspects come to the forefront. The various components that constitute the application need to be highly secured and nonhackable.

The technological landscape is constantly growing, with new technologies popping up and getting adopted by the developer community. Because of this and the various technology improvements it brings in, many organizations have to adopt these technologies to be compete within the market. This again puts huge pressure on security, as these shiny new technologies may not have concentrated enough effort on making security a major requirement.

All in, having rigid security in an application is a no-brainer requirement and organizations, and end users, are well aware of this fact.

 Over the last few years, JavaScript has become one of the most used languages, and you have already heard of the term reactive in the world of JavaScript, both in a backend and a frontend context.

So, What exactly is reactive programming?—It's a programming paradigm that has asynchronous data streams at its core. The data flows through various parts of the program in the form of a message. The message is produced by a Producer and works in a fire-and-forget manner in which the program produces a message and forgets it. The Subscriber who has subscribed (shown interest) to such messages, gets the message, processes it, and passes on the output as a message for other parts of the program to consume.

In the world of databases, NoSQL presented a huge shift from relational databases. Similarly, this programming paradigm is a huge shift from the conventional programming paradigm (imperative programming). The good thing is that without much knowledge, you have already been coding a bit of reactive code in your day-to-day coding life. Wherever you see the word stream, you are indirectly using a piece of reactive code. Such programming has a name of its own and this aspect has become more mainstream in the industry. Many languages understand the advantages this brings and they have started to natively support this paradigm of programming.

In the earlier section of this chapter, we covered how application requirements have drastically changed over the last decade. To cater to this, there is a concept of application development named reactive applications.

It is important to understand the difference between reactive programming and reactive applications. Employing reactive programming doesn't produce reactive applications, but concepts of reactive programming can definitely aid in building reactive applications.

Knowing the Reactive Manifesto will help you understand reactive applications/systems because the manifesto clearly dictates each and every aspect of reactive applications.

Reactive Manifesto

A manifesto is apublicdeclarationofintentions,opinions,objectives,ormotives,asoneissuedbyagovernment,sovereign,ororganization (http://www.dictionary.com/browse/manifesto).

The Reactive Manifesto clearly articulates the views of the issuer, following which an application can be developed to be reactive.

According to the Reactive Manifesto (https://www.reactivemanifesto.org/), a reactive system should be responsive, resilient, elastic, and message-driven.

Let's get into each of these terms in a bit more detail. Most of the text in this section is from the online Reactive Manifesto and then slightly modified to convey the concepts in more easily digestible terms for the readers.

Responsive

In case of problems, responsive systems can quickly detect them and effectively deal with them. These systems also give consistent response times and also establish upper bounds, guaranteeing a minimum Quality of Service (QoS). Because of such characteristics, these systems build end user confidence, simplify error handling, and encourage more interaction from end users.

 

Resilient

In the case of failure, resilient systems stay responsive and interactable. Resilience in an application can be achieved by:

• Replication: Running the same component in more than one place, so that if one fails, another could handle it and the application can function in a normal fashion.
• Containment/isolation: Issues of a particular component are contained and isolated within that component and don't interfere with other components or other similar components spun up as part of replication.
• Delegation: In the case of an issue in a component, without much deliberation, the control is transferred to another similar component that is running in a completely different context.

Elastic

Elastic systems can easily autoscale (increase or decrease resources) as the input rate increases or decreases. Such systems don't have any contention points and can replicate components at will, distributing the increase in load. The way these systems are designed makes sure that when scaling is required, it can be done in a very cost-effective manner by adding on more commodity hardware and software platforms as opposed to expensive hardware and licensed software platforms.

Message-driven

In reactive applications, one of the main aspects is the usage of asynchronous messages to pass data from one component to another. This brings loose coupling between components and aids in achieving location transparency (as long as the component is reachable/discoverable, it can reside in a single node or a cluster of nodes anywhere). Create a message, publish, and forget. Registered subscribers receive the message, process it, and broadcast the message for the other subscribes to do their jobs. This is one of the core aspects of reactive programming and it is one of the fundamental aspects needed for a reactive system. This fire-and-forget concept brings in a non-blocking way of communication, resulting in highly scalable applications.

The following diagram (Figure 1) clearly shows the Reactive Manifesto in a pictorial fashion. It also clearly shows the relationship between the main concepts on the Reactive Manifesto:

Figure 1: Reactive Manifesto

Since reactive applications are responsive, resilient, elastic, and message-driven, these applications are inherently highly flexible, highly scalable, loosely coupled, and fault-tolerant.

Mateusz Gajewski, in one of his presentations shared on www.slideshare.net, sums up the Reactive Manifesto in a very nice way:

Figure 2: Reactive Manifesto as conceived by Mateusz Gajewski

 

Spring Framework is the de facto standard for building Java applications. Over the last decade, it has matured with every major release. Spring Framework 5 became generally available as 5.0.0. in September 2017; this is an important release (major) for the framework since its previous version, which was released in 2013.

One of the major additions to Spring 5 is the introduction of a functional web framework, Spring WebFlux, built on the core reactive foundation. Reactive programming is slowly creeping into the framework and many core modules within the framework are inherently supporting reactive programming in a big way. Since the framework has started supporting reactive programming natively, core aspects of this programming are fully implemented and followed by many of the modules. Also, many reactive concepts have become common language within the framework.

It's important to note that Spring's reactive concepts have been taken as is from Java 8's Reactor Core library, which implements the reactive programming paradigm. Reactor Core is built on top of Reactive Streams Specification, which is the industry standard for building reactive applications in the Java world.

Another important feature is the inclusion of new way by which such applications can be tested. We have a dedicated chapter for Spring WebFlux in (Chapter 5, Integrating with Spring WebFlux) where these aspects will be covered in more detail.

Being a major release, it has loads of stuff either added or enhanced. But we are not going to list all of its features. The full list can be found at this link: https://github.com/spring-projects/spring-framework/wiki/What%27s-New-in-Spring-Framework-5.x.

It's hard to wrap your head around reactive concepts when you're coming from a traditional programming model. Some of the subsequent sections are aimed at introducing you to reactive concepts and how they evolved into their present state.

Reactive Streams and Reactive Streams Specifications

The official document for Reactive Streams (http://www.reactive-streams.org/) says that—Reactive Streams is an initiative to provide a standard for asynchronous stream processing with non-blocking back pressure. This encompasses efforts aimed at runtime environments (JVM and JavaScript) as well as network protocols.

It started as an initiative between a group of companies in 2013. In April 2015, 1.0 of the specification was released and there were a number of implementations (such as Akka Streams and Vert.x) available at the same time. The specification was initiated with a target to get it included in the official Java standard library and in 2017, with the release of JDK9, it made it's way into it officially. As with any specification, the ultimate aim is to have a number of implementations conforming to the specification, and over time, the specification evolves. The specification consists of some core interfaces, some rules around these, and a Technology Compatibility Kit (TCK).

TCK is a suite of tests that will be executed to check the correctness/compliance of a Java Specification Request (JSR) implementation. In Java Community Process (JCP), TCK is one of the three required components for ratifying a JSR. The other two are JSR specification and JSR reference implementation. The TCK for the Java platform is called Java Compatibility Kit (JCK).

Being a specification, it enables any implementation respecting the specification to cooperate and interoperate with each other. For example, an implementation written in Akka can talk to the Vert.x implementation over the Reactive Streams protocol without any trouble. Adoption is growing and, as we speak, more implementations that conform to the specifications written in different languages are being released:

Figure 3: Reactive Streams Specification/API

The preceding figure clearly shows the Reactive Streams Specification. Some of the important specification rules are as follows:

• The calls from Publisher to Subscriber and Subscriber to Publisher shouldn't be concurrent in nature.
• The Subscriber can perform its job synchronously or asynchronously but always has to be non-blocking in nature.
• From Publisher to Subscriber there should be an upper bound defined. After that defined bound, buffer overflows occur and could result in errors.
• Apart from NullPointerException (NPE), no other exception can be raised. In the case of NPE, Publisher calls the onError method and Subscriber cancels the Subscription.

In the preceding definition of Reactive Streams, there are some very important terms, namely non-blocking and backpressure, which we'll explore a bit more to understand the core concepts of Reactive Streams.

Non-blocking

Non-blocking means threads never block. If the thread needs to block, the code is written in such a way that the thread gets notified at the right time and the process continues. Reactive programming lets you implement a non-blocking, declarative, and event-driven architecture.

One of the approaches to writing non-blocking applications is by using messages as the means of sending data. A thread sends the request and soon after that, the thread is being used for something else. When the response is ready, it is delivered back using another thread and the requesting party is notified so that further processing can continue:

Figure 4: Non-blocking

 

The non-blocking concept is already implemented by well-known frameworks, such as Node.js and Akka. The approach that Node.js uses is a single thread that sends data in a multiplexing aspect.

In telecommunications and computer networks, multiplexing (sometimes contracted to muxing) is a method by which multiple analog or digital signals are combined into one signal over a shared medium. The aim is to share an expensive resource. For more information about multiplexing, you can visit the following link: http://www.icym.edu.my/v13/about-us/our-news/general/722-multiplexing.html.

Backpressure

In an ideal scenario, every message produced by the Producer is passed to the Subscriber as and when the message is produced without any delay. There is a chance that the Subscriber is unable to handle the messages at the same rate as they are produced and this can cramp its resources.

Backpressure is a method by which the Subscriber can tell the Producer to send messages at a slower rate to give the Subscriber time to handle these messages properly without putting too much pressure on its resources.

Since this is the first chapter, we are just introducing you to these important reactive concepts. Code examples will be covered in subsequent chapters.

Now that we have a brief idea of Reactive Streams and Reactive Streams Specification, we will go into next important reactive concept in Java, namely Reactive Extensions.

public interface Publisher<T> {
  public void subscribe(Subscriber<? super T> s);
}

public interface Subscriber<T> {
  public void onSubscribe(Subscription s);
  public void onNext(T t);
  public void onError(Throwable t);
  public void onComplete();
}

public interface Subscription {
  public void request(long n);
  public void cancel();
}

public interface Processor<T, R> extends Subscriber<T>, Publisher<R> {
}

Spring Framework adopted reactive in 2013 (the same time reactive was born and became more mainstream) with the release of Version 1.0 of Reactor. This was the time when Spring Framework Version 4.0 was released and Spring got itself engaged with Pivotal. In 2016, Spring's 4.3 Version was released with Reactor's Version 3.0. Around this period, the work on Spring's Version 5.0 (major version) was actively under construction.

With new-generation application requirements, many conventional coding practices were challenged. One of the main aspects was to get rid of blocking IO and to find an alternative to conventional imperative programming.

Web applications backed by a Servlet container are inherently blocking, and Spring 5 did a great deal in web application development by introducing a fresh web application framework based on reactive programming: Spring WebFlux.

Spring also has embraced Rx and has used it in many ways within Spring 5. With Spring 5, reactive features are baked into it in many aspects, helping developers to embrace reactive programming easily in a slow-paced manner.

Pivotal is heavily invested in Reactor but has exposed APIs, allowing developers to choose the library of their choice between Reactor and RxJava.

The following diagram depicts Spring 5's reactive programming support:

Figure 5: Spring Framework + Reactor + Rx

Reactor is Pivotal's (SpringSource) answer to implementing Reactive Streams Specification. As mentioned earlier, Spring is heavily invested in Reactor and this section aims to delve a bit deeper into Reactor.

Reactor is a fourth-generation reactive library for building non-blocking applications on the JVM based on the Reactive Streams Specification.

An overview of the history of Project Reactor can be pictorially represented in the following figure:

Figure 6: Project Reactor history

The figure above shows the major releases of Project Reactor. The project kick started in the year 2013 (1.x version) and the major release of 3.x was released in the year 2016. As of writing this book, the core module of the framework is at version 3.1.8.RELEASE.

Now that we have a brief understanding of Spring Framework and its connection with reactive programming, lets dive a bit deep into Project Reactor.

Modules in Reactor

With the latest release of Reactor 3.0 the project has been structured with modularity in mind. Reactor 3.0 consists of four major components namely Core, IO, Addons, and Reactive Streams Commons.

• Reactor Core (https://github.com/reactor/reactor-core): The main library within Reactor. It provides foundational, non-blocking JVM-compliant Reactive Streams Specification implementations. It also contains code for Reactor types, such as Flux and Mono. 
• Reactor IO (https://github.com/reactor/reactor-ipc): It contains backpressure-ready components that can be used to encode, decode, send (unicast, multicast, or request/response), and then serve connections. It also contains support for Kafka (https://kafka.apache.org/), Netty (http://netty.io/), and Aeron (https://github.com/real-logic/aeron).
• Addons (https://github.com/reactor/reactor-addons): As the name suggests, these are add-ons that consist of three components:
  • reactor-adapter: Contains a bridge to RxJava 1 or 2 types, such as Observable, Completable, Single, Maybe, and Mono/Flux back and forth.
  • reactor-logback: Supports logback over asynchronous reactor-core processors.
  • reactor-extra: Contains more operations for Flux, which include mathematical operations such as sum and average.
• Reactive Streams Commons (https://github.com/reactor/reactive-streams-commons): A collaboration experiment project between Spring's Reactor and RxJava. It also contains Reactor-Streams-compliant operators that both projects implement. Issues fixed on one project are also fixed on the other.

Reactive types in Reactor Core

Reactor provided two reactive types, Flux and Mono, that implement Rx extensively. They can be represented as a timeline in which elements are sequenced according to how they arrived. It is important that you get the hang of these two types. Let's do that in the following subsections.

The Flux reative type

A Reactive Streams publisher with Rx operators that emits 0 to N elements, and then completes (successfully or with an error). For more information, you can check the following link: https://projectreactor.io

Flux<T> is a Publisher<T> with basic flow operations and supports 0..n elements.

The definition of Flux is as follows:

public abstract class Flux<T>
 extends Object
 implements Publisher<T>

 

The following figure, as depicted in the Flux documentation, explains the working of Flux in more detail:

Figure 7: Working of Flux

Flux support is in Spring 5 and a variety of other important modules, including Spring Security. Operators acting on Flux would create new publishers.

Please refer to the Reactor Flux documentation for more information: https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Flux.html.

Now, let's have a look at some code examples where usage of Flux is shown:

• Creating empty Flux:

Flux<String> emptyFlux = Flux.empty();

• Creating Flux with items in it:

Flux<String> itemFlux = Flux.just("Spring”, "Security”, "Reactive”);

• Creating Flux from an existing list:

List<String> existingList = Arrays.asList("Spring”, "Security”, "Reactive”);
Flux<String> listFlux = Flux.fromIterable(existingList);

• Creating Flux that emits every x milliseconds in an infinite manner:

Flux<Long> timer = Flux.interval(Duration.ofMillis(x));

• Creating Flux that emits an exception:

Flux.error(new CreatedException());

The Mono reactive type

 

A Reactive Streams Publisher with basic Rx operators that completes successfully by emitting an element, or with an error.

– Mono JavaDoc

Mono<T> is a Publisher<T> that supports 0..1 elements.

The definition of Mono is as follows:

public abstract class Mono<T>
    extends Object
    implements Publisher<T>

As detailed in the documentation, the following figure shows the workings of Mono:

Figure 08: Working of Mono

 

Mono<Void> should be used for a Publisher that completes with no value. The documentation explains each method and how it works using a marble diagram, which is self-explanatory. Again, this type is also supported by Spring 5 and Spring Security.

JavaDoc for Mono contains more information: https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Mono.html.

Let's have a look at some examples:

• Creating empty Mono:

Mono<String> emptyMono = Mono.empty();

• Creating Mono with a value in it:

Mono<String> itemMono = Mono.just("Spring Security Reactive”);

• Creating Mono that emits an exception:

Mono.error(new CreatedException());

Data stream types

Broadly, data streams can be categorized into two types:

• Cold data streams: There are a number of names by which this is known, such as Cold Source, Cold Observable, and Cold Publisher. These emit data only when one subscribes to it and because of this, all messages produced from start are delivered to the subscriber. If a new Subscriber connects to it, the messages are replayed in ascending order and this is same for any new Subscriber. The Subscriber also has a provision to dictate the rate at which the Publisher should emit messages. These data streams are good candidates for applying reactive backpressure (request(n)), for example, a database cursor or file stream (reading a file).
• Hot data streams: Again, this has a number of different names, such as Hot Source, Hot Observable, and Hot Publisher. These emit data irrespective of any subscribers connected. When a new Subscriber connects, it just emits the messages from that point in time and cannot replay messages from the start. These cannot pause message emissions, so an alternate mechanism is required to control flow, such as a buffer. Examples of this stream include mouse events and stock prices.

 

It's important to note that operators on a stream can change their property, going from cold to hot and vice versa. Also, there are times when a merge between hot and cold can happen and their properties change.

Reactor and RxJava

One of the main aspects between the two is RxJava 2.x which is Java 6+ compatible, but Reactor is Java 8+ compatible. If you are going with Spring 5, I urge you to use a Reactor. If you are comfortable with RxJava 2.x, there is no need to migrate to Reactor. Reactor is an implementation of the Reactive Streams Specification, so you can remain agnostic of what the underlying implementation is.

Application security is composed of various processes put in place to find, fix, and prevent security vulnerabilities in an application.

We are living in the world of Development + Operations (DevOps) where we bring engineering and operational staff together. DevOps advocates automation and monitoring at all levels. With security becoming a very important consideration, a new term, DevSecOps, is becoming prominent—this is where we bring in security as a first-class citizen.

For an application, security comes under the nonfunctional requirements. Due to its importance in an application, most organizations have dedicated teams that test applications for potential security flaws. It's a very important aspect to be considered, as in this modern world, a security breach can seriously ruin an organization's brand.

Security is a very broad term and encompasses many aspects. In this book, we will look at some of the fundamental security concerns using the Spring Framework module—Spring Security. After covering some of the core security concerns, we will also look at some of the low-level security problems and how Spring Security can help deal with them.

Since we will be focusing on Spring, we will be delving deep into security concerns with respect to a Java web application development.

Spring Security 5 is the new version of the framework and will be the main focus of this book. Spring Security enables you to take care of authentication and authorization of your application in all aspects. It also has top-level projects to deal specifically with a number of authentication mechanisms, such as LDAP, OAuth, and SAML. Spring Security also gives you enough mechanisms to deal with common security attacks, such as Session Fixation, Clickjacking, and Cross-Site Request Forgery. Moreover, it has very good integration with a number of Spring Framework projects, such as Spring MVC, Spring WebFlux, Spring Data, Spring Integration, and Spring Boot.

Spring Security provides a number of security features for your application. The two main features for which Spring Security is well-known are it's support for a variety of authentication and authorization methodologies. In this section, we will delve deeply into these core features in more detail.

Spring Security 5 provides a number of new features along with support for Spring 5. Some of the important new features introduced as part of this release are:

In this section, we will look at how Spring Security works. We will first explain the core concepts and then look at various classes the request goes through to perform security.

Servlet Filter

It's quite important to understand Servlet Filter so you can understand Spring Security internals. The following figure clearly explains a Servlet Filter in action. It comes before the request reaches the actual resource and also before the response if sent back to the consumer. It's a pluggable component that can be introduced at any time with configuration in the web configuration file (web.xml).

Figure 9: Working of Servlet Filter

Security Interceptor (DelegatingFilterProxy)

When any request reaches an application that is secured using Spring Security, there is a gate the request goes through. This interceptor does all the magic and if things don't look good, it errors out and goes back to the caller, as shown in the following figure:

Figure 10: Working of Security Interceptor

The Security Interceptor makes sure that, according to various security configurations set up for your application, it delegates the work to appropriate parties and makes sure that everyone is happy before actually reaching the resource requested by the caller. To do the actual job, the Security Interceptor employs a number of managers, each entrusted to do a single job. The following figure lists some of the important managers the Security Interceptor works with to perform the function:

Figure 11: Security Interceptor and associated managers

In Spring Security, the Security Interceptor is accomplished by DelegatingFilterProxy. For any request that reaches the web application, this proxy makes sure to delegate the request to Spring Security, and when things go well, it makes sure that the request is taken to the right resource within the web application.

DelegatingFilterProxy is a Servlet Filter that has to be configured in your web.xml file, which then delegates to a Spring-managed bean (@Bean) that implements a ServletFilter interface.

The following code snippet shows how to configure DelegatingProxyFilter in web.xml:

<?xml version="1.0" encoding="UTF-8"?>
 <web-app>
    <filter>
        <filter-name>springSecurityFilterChain</filter-name>
        <filter-class>
            org.springframework.web.filter.DelegatingFilterProxy
        </filter-class>
    </filter>

    <filter-mapping>
        <filter-name>springSecurityFilterChain</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
 </web-app>

In the preceding code, all the requests to the web application (/* mapping) would go through the DelegatingProxyFilter filter. It's important to note that the name of this filter should be springSecurityFilterChain as Spring Security looks for this default filter name to configure itself. The proxy filter just passes/delegates the control to a bean named springSecuirtyFilterChain. If you are using the default Spring Security setup, the request would then be received by FilterChainProxy. FilterChainProxy is responsible for passing the request through the various Servlet Filters configured as part of Spring Security. The springSecuirtyFilterChain bean need not be explicitly declared, instead, it is taken care of by the framework which is transparent to the developer.

Now that we've looked at all the core concepts of Spring Security, let's come back to the working of Spring Security as pictorially represented in the following diagram. It contains two important security aspects –Authentication and Authorization:

Figure 12: Working of Spring Security

The request from the caller reaches DelegatingFilterProxy, which delegates to FilterChainProxy (Spring Bean), which in turn passes the request through a number of filters, and after successful execution, grants access to the secured resource the caller has asked for.

 

For the complete list of Servlet Filters and their functions, I urge you to go through the Spring Security reference: https://docs.spring.io/spring-security/site/docs/current/reference/html/security-filter-chain.html.

With all these details, the following figure sums up how Spring Security takes care of Authentication and Authorization for your web application:

Figure 13: Authentication and Authorization in Spring Security using a database

When a caller sends a request to a web application protected by Spring Security, it first goes through the Security Interceptor managers, such as Authentication Manager (responsible for authentication) and Access Decision Manager (responsible for authorization), and after executing these successfully, gives the caller access to the secured resource.

For reactive applications, these concepts are all valid. There are equivalent reactive classes and the way we code is the only thing that changes. These are easy to understand and implement.

 

In Chapter 2, Deep Diving into Spring Security, we will cover Authentication, and in Chapter 3, Authentication Using SAML, LDAP, and OAuth/OIDC, we will cover Authorization in detail and delve a bit more deeply into its internals.

In Spring Framework, Spring Security is a top-level project. Within the Spring Security project (https://github.com/spring-projects/spring-security), there are a number of sub-modules:

These are the top-level projects within Spring Framework that are strongly linked to Spring Security:

Security Assertion Markup Language (SAML) is an XML-based framework for ensuring that transmitted communications are secure. SAML defines mechanisms to exchange authentication, authorization, and non-repudiation information, allowing single sign-on capabilities for Web services.

The Lightweight Directory Access Protocol (LDAP) is a directory service protocol that runs on a layer above the TCP/IP stack. Its based on a client-server model and provides a mechanism used to connect to, search, and modify Internet directories.

Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret key cryptography. A free implementation of this protocol is available from MIT and it is also available in many commercial products.

In this chapter, we introduced you to new application requirements and then moved to some of the core reactive concepts. We looked at the Reactive Manifesto and reactive programming. We then moved our attention to Spring 5 and Spring Security 5, and touched on some of the new features in it, especially regarding reactive programming. We then looked briefly at Spring's reactive programming efforts by introducing you to Project Reactor. After that, we explored Spring Security in a bit more detail to refresh your thoughts on this subject. Finally, we closed this chapter by giving you an idea of how examples would be structured in this book and what coding practices we will be using.

You should now have a good grasp on reactive programming, and on Spring Security and how it works. You should also have a clear understanding of how to go through the rest of the chapters, especially the example code.