Securing applications using Spring Security 6 — Part 1

Photo by rc.xyz NFT gallery on Unsplash

Being a seasoned #JavaDeveloper, it’s highly unlikely that you have not heard about the concept of securing your application using Spring Security.

This is a series where I will begin with shedding the light on the basics of spring security architecture and then moving towards building a sample application to consolidate the understanding of learned concepts.

The core architecture of spring security is vast, covering everything here will be hard, hence I will be touching the topics that are building blocks to create a definitive understanding.

Authentication

The authentication is considered as a process involving user or system to confirm their identity by providing information such as credentials or certificates.

For example, when a user provides the username and password for a account to a system, system verifies that information against the records to make sure the user has the knowledge and have access to the right credentials before allowing the user to perform operation on a restricted resource.

Authorization

Authorization is considered as a process of granting permission to access to already authenticated entity. It can be achieved using Role Based Access or attribute based access.

A basic example would be to consider a use case where a user can have different roles associated to the profile USER and ADMIN. Admin role will authorize the user to have full access to the system whereas a user role will allow the user to perform restricted operations.

As we have concluded a basic difference between authentication and authorization, let’s move ahead with the core agenda of this article.

Pre-Requisites

There are few requisites which I would expect that you should know to understand the concepts in this article.

• Basic Java concepts — we will be using Java 17 in this article.
• Spring Boot Basics, Spring Data JPA etc.

What is Spring Security ?

According to Spring Framework Documentation,

Spring Security is a powerful and highly customizable authentication and access-control framework. It is the de-facto standard for securing Spring-based applications.

The component illustration below, provides the basic understanding of the components that are available in spring security by default.

Spring Security Architecture

Spring Security Components

Security Filter Chain

Security Filter chain is considered to be one of the most important component of Spring security. To understand it better, it is imperative to look into the concepts of Filters and Filter Chain.

A Filter is a component in an application that intercepts the incoming request and outgoing responses allowing the application to perform pre-processing and post processing on the data before it reaches the actual servlet for processing.

An application have multiple filters that could be applied to the incoming request and outgoing response. In Spring MVC, servlet is an instance of Dispatcher Servlet that can handle a single HttpServletRequest and Response.

Filter Chain is the object that is provided by the Servlet Container to the developer to chain the filters and invoke as needed. Filters uses the Filter Chain object to invoke the next filter.

protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        filterChain.doFilter(request, response);
}

Delegating Filter Proxy

• The servlet and spring application context both has their own life cyle. To bridge this gap, Spring provides an implementation of Filter called as DelegatingFilterProxy.
• The DelegatingFilterProxy can be registered using standard Servlet container mechanism but delegates all the work to a Spring Bean that implements Filter.

Filter Chain Proxy

This is a special Filter provided by Spring Security. It is a bean(an object that is instantiated, assembled and managed by Spring IOC) that is wrapped into the Delegating Filter Proxy. Filter Chain Proxy basically delegates to Security Filter Chain to execute different Security Filters that are applied by Spring Security.

It also performs tasks that are not optional such as clearing out Security Context as well as apply default mechanism to protect applications against certain type of attacks.

Security Filter Chain is the interface that is used by Filter Chain Proxy to determine which filter instances should be invoked for the current request.

One common misconception that there could be only one Security Chain, As per the Spring Documentation, Security Filter Chain can be unique and configured in isolation.

Security Filter Chain Concepts

//Sample security filter chain implementation
public SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http, JwtAuthenticationFilter jwtAuthenticationFilter) throws Exception {
        http.csrf(AbstractHttpConfigurer::disable)
                .authorizeHttpRequests(requests ->
                            .anyRequest().authenticated()
                )
                .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
        return http.build();
    }

Here is a list of some security filters that are supported as a part of Security Filter Chain:

Authentication Filters

1. UsernamePasswordAuthenticationFilter — Username password based logins
2. BasicAuthenticationFilter — HTTP Basic Authentication Headers
3. RememberMeAuthenticationFilter — Remember me functionality for automatic authentication
4. AnonymousAuthenticationFilter — Anonymous authentication if no authentication mechanism is available
5. OAuth2LoginAuthenticationFilter — Authentication via OAuth2.0 providers such as Google, Facebook
6. Saml2WebSsoAuthenticationFilter — SAML 2.0 Single Sign On

Authorization Filters

1. FilterSecurityInterceptor — Access control rules based on user roles and permission
2. AuthorizationFilter — customizable filter for authorization logic.

Other Filters

1. CsrfFilter — Cross Site Request Forgery Attacks protection
2. LogoutFilter — User logout functionality
3. ExceptionTranslationFilter — Translates exceptions into HttpResponses or redirects
4. SessionManagementFilter — Manages user session and prevent concurrent behavior

Security Context Holder

Spring Security Context Holder is a store where Spring Security stores the details of who is authenticated.

Security Context Holder

By default, The context uses the ThreadLocal to store these details. It means even if the context is not passed around between different methods as an argument, the methods will still be able access the same context for the particular thread.

//Accessing the security context to retrieve relevant information for current request.
SecurityContext securityContext = SecurityContextHolder.getContext();
Authentication authentication = securityContext.getAuthentication();
Object principal = authentication.getPrincipal();
String username = authentication.getName();
Collection<? extends GrantedAuthority> authorities = authentication.getAuthorities();

Its not always that the application needs the strategy where the authentication is restricted to ThreadLocal. Spring security provides different strategy modes that allows the application to adapt to different authentication strategies. The strategy needs to be defined if needed at the startup.

• Thread Local — Default
• Global — Not recommended due to security vulnerabilities and thread-safety concerns.
• Inheritable Thread Local — Can be used if the application is using asynchronous operations and want child threads to inherit the security context. Consider using dedicated thread pools for tasks that require a specific security context.

// Setting spring security context holder strategy
 @PostConstruct
    public void setSecurityContextHolderStrategy() {
        SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL);
    }

Security Context

Security Context is obtained by the Security Context Holder which contains the Authentication Instance. Security context consists of the following

• principal — User Identity
• credentials — Primarily password or related information which is then cleared once authenticated.
• authorities — High Level permission provided to the principal for accessing the system resources.

Authentication Interface

The authentication interface serves an input to the Authentication Manager to provide the credentials that the user has provided for authentication as well post authentication has been completed it contains the information associated to the authenticated entity.

Authentication Manager

Authentication Manager is an interface that defines how the Spring Security Filters perform a set of authentication. Most common implementation of Authentication Manager is the ProviderManager.

Authentication Manager

Provider Manager generally consists of one or more Authentication Provider. It looks for a successful authentication using the configured providers.

Provider manager also allows configuring an optional parent Authentication Manager kind of a default which is consulted in case there no authentication provider that can perform the authentication on provided credentials.

If there is no authentication provider configured then authentication fails with no provider exception which indicates the manager is not configured to handle the type of authentication that is presented.

An Authentication Manager can be shared among different Provider Manager consisting of different authentication providers.

Authentication Provider

Authentication Provider is an interface implemented by the class that acts as the entity to host the implementation of the authenticate method. The authenticate method is responsible verify the entity and return an Authentication instance containing the respective information.

There are some default implementation to use in Spring security

DaoAuthenticationProvider

This is a default implementation of a Authentication Provider which uses the password encoder and user details service to authenticate username and password provided by the entity.

//Sample Bean for Authentication Provider
// Registering User Detail Service and Password Encoder.
  @Bean
    public AuthenticationProvider authenticationProvider() {
        DaoAuthenticationProvider authProvider = new DaoAuthenticationProvider();
        authProvider.setUserDetailsService(userDetailsService());
        authProvider.setPasswordEncoder(passwordEncoder());
        //Deprecated
//      authProvider.setPasswordEncoder(NoOpPasswordEncoder.getInstance());
        return authProvider;
    }

Password Encoder

This is bean that is registered with the container to encode the password that is presented by the entity. It is a standard practice not to store the passwords in plain text and hence Password Encoder come to rescue.

As a developer, you can choose to encode the password or use no encoding which is then configured for the authentication provider.

@Bean
    public PasswordEncoder passwordEncoder(){
        return new BCryptPasswordEncoder();
    }

User Detail Service

User detail service is an interface implemented to retrieve username, password and other information that aids in authenticating the user.

There are few default implementations that are provided by the Spring Security

1. InMemoryUserDetailsManager — provides support for username and password stored in the memory
2. JDBCUserDetailsManager — provides support for username and password stored in the database and retrieved via JDBC. There is a default schema that is applied when this implementation is used and hence if using this implementation, then default schema must be followed to use it to full potential.
3. CachingUserDetailsService — provides support for caching the user information using username and password. For this implementation, make sure to disable the credentials erasure for the Spring Security for credential container.

We can also register a custom user details service which is the path that we will follow when we implement the sample application.

I hope you enjoyed the article, the intent of the article was to set in the stage for you to understand the core concepts really well. We will continue our journey to implement a sample application in next part of the this article. Stay tuned for the next part.

Please comment or provide feedback if you really liked this article.

Thanks & Cheers, Happy Learning!!