#
Spring Security Overview
This tutorial is a Spring Security architecture overview.
Please take a look at the picture above.
Info
- The classes/instances in blue are specific to Spring Security !
- A Principal is someone who wants to authenticate. We need to have ONLY a name in this type of object.
- More information regarding credentials, authorities (roles), is authenticated or not are stored in Authentication objects (Authentication interface extends Principal interface).
Here are the steps the request pass through:
Step #1: The client send a request to the Servlet Server.
Step #2: Before the request arrive to the servlet container, there are a couple of Filters the request pass
through. These filters must be defined. Not all the filters are related to the security and not all are managed
by Spring Security. Filter #1, Filter #n are filters managed by the Application and not by Spring Security.
At one point we have DelegatingFilterProxy, which is a filter, and it acts as a bridge/link between
the application and spring security filter chain.
Step #3: Each time a request pass through DelegatingFilterProxy, it passes the request to the
FilterChainProxy (a filter).
Step #4: The authentication is the first thing which is done. The Authentication Filter takes care of this.
Step #5: The Authentication Filter use the Authentication Manager for handling the authentication.
Step #6: The Authentication Manager interacts with 1 or more Authentication Providers in order to get the
authentication information. This information is defined in
Authentication interface.
If the information provided is not validated by the Authentication Providers, the authentication fails.
Step #7: The Authentication Providers are using a PasswordEncoder and an UserDetailService.
Step #8: The Authentication information is stored in Security Context Holder. The Authorities information is added.
Step #9: FilterChainProxy (based on Security Filter Chains definition) determines which
Security Filter Chain instance should be invoked for the current request.
Step #10: A specific SecurityFilterChain will be invoked for the current request.
Step #11: The authorization filters take decision based on the Security Context (Authentication information).
Info
The
SecurityContextHolderis where Spring Security stores the details of who is authenticated.SecurityContextis obtained from the SecurityContextHolder and contains the Authentication of the currently authenticated user.Authenticationcan be the input to AuthenticationManager to provide the credentials a user has provided to authenticate or the current user from the SecurityContext.
Security Context Strategy
The SecurityContextHolder in the SecurityContext manager and can set the way the SecurityContext is visible
to the application threads. The Security Context Strategy can be set using SecurityContextHolder.setStrategyName()
method.
Spring Security works with 3 Context Strategies:
MODE_THREADLOCAL: (default strategy) Each thread has its own SecurityContext. Good for traditional Web Applications.
MODE_INHERITABLETHREADLOCAL: When a new thread is created, it inherits the SecurityContext from its parent. This strategy is good for Reactive Applications.
MODE_GLOBAL: All the threads of the application/service use the same SecurityContext instance. In this case, the SecurityContext is not thread safe, and we need to take care of the concurrency.
Step #12: When Spring Security finish its job, the request is passed back to DelegatingFilterProxy.
Step #13: After DelegatingFilterProxy, some other filters might run.
Step #14: If the request is authorized, the request rich the Servlet Container.
The request will be executed and a response will be sent to the client.
UserDetails
UserDetailsService
UserDetailsManager
Enjoy Spring Security framework !