The introductory article on Spring Security provided a comprehensive overview of the benefits of utilizing the framework. It concluded by highlighting the spring-boot-starter-security as the gateway to Spring Security.
By using this starter, you can quickly get up and running with Spring Security without the need for extensive manual configuration. It saves you time by providing sensible default settings while still allowing for customization as per your specific requirements.
Spring Security is typically added to a Spring Boot application to provide security features. If you don't have a Spring Boot project, you can create one using spring initializer.
Step 1: Add the dependency to your project’s pom.xml file and rebuild the maven.
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-test</artifactId>
<scope>test</scope>
</dependency>
Spring Security automatically generates a random password during startup which is displayed in the console logs.
You will find that subsequent visit to any of the route defined in your controller requires authentication i.e. you must sign in with a username that defaults to ‘user’ and a password which is the generated password you have in your console.
For flexibility, the username and password can be customized in your application.properties
The main goal of the default security configuration is to provide a quick setup of security features for testing and experimenting within a development environment.
A Preview of the bigger picture.
Every application is intended to be accessed by “Users” who have to be first registered so that their details are stored in a database linked to that application. These users will be assigned different roles or access levels that will determine what part of the application they can access and what kind of action they can perform while logged into this application.
The key concepts drawn out of the paragraph above include securing the APIs, authentication, which is identifying a user making a request at the API, and authorization, which is defining what a user can do.
The default implementation allows us to use a single user profile at a time. However, applications are mostly built to be used by many users. Usually, these users running into millions (a good thing for any business) are stored in the application database.
Spring security provides a ‘middleman’ called in-memory authentication. This form of authentication allows you to configure and authenticate users directly in memory, without the need for an external user database.
It is primarily used for testing, development, or small-scale applications where the number of users is limited and maintaining a separate database for user credentials is not necessary or practical.
Time to meet the guys. The best way to understand Spring Security is to recognize the moving pieces (key players) and how they interconnect.
Step 2: Create a SecurityConfiguration class. This will warehouse our security configuration a.k.a customization.
We will be creating beans of certain key players: SecurityFilter Chain, Authentication Manager, Password Encoder, and UserDetailsService.
The Client makes a request to our controller. The request details (aka request header) contain information about the person making this request. This is called the credentials.
The SecurityFilterChain as the name suggests is a chain of filters that filters through incoming requests to enforce security measures.
To do the work of authenticating, the security filter chain requires an Authentication Manager. The Authentication Manager has a built-in method called authenticate.
The authentication manager internally uses another player, UserDetails Service.
UserDetails Service provides a method that uses the username to fetch the corresponding user from the storage (an external database or the in-memory database in our case).
So the actual authentication is simply a comparison of the user details in the request header and the user details fetched from the database.
This quite simplified architecture will give us a broad overview of the interaction happening between the beans of the key players highlighted above.
Of course, It only gets interesting from here. To be continued.