Understanding Spring Security Architecture: Authentication, Authorization, and Filter Chains

Authentication and Access Control

Application security can be divided into two independent concerns: authentication (who you are) and authorization (what you can do). Spring Security separates these concerns with a dedicated architecture and extensible strategies.

Authentication

The core interface is AuthenticationManager with a single method Authentication authenticate(Authentication authentication). An implementation may return a fully‑authenticated Authentication object, throw an AuthenticationException, or return null when it cannot decide.

The most common implementation is ProviderManager, which delegates to a chain of AuthenticationProvider instances. Each provider can support specific authentication types via its supports(Class<? extends Authentication>) method.

Spring Boot registers a default global AuthenticationManager bean; custom managers can be built with AuthenticationManagerBuilder (e.g., in‑memory, JDBC, LDAP).

Authorization or Access Control

After successful authentication, Spring Security uses an AccessDecisionManager (default AffirmativeBased) together with a list of AccessDecisionVoter objects to evaluate ConfigAttribute metadata such as role names or SpEL expressions.

Typical configuration uses .hasRole("ADMIN") or SpEL like isFullyAuthenticated() && hasRole('FOO'). Custom voters or expression handlers can be added for advanced rules.

Web Security

Spring Security’s web layer is built on a servlet Filter chain. The FilterChainProxy delegates to internal security filters, each with a specific order. The chain is selected by a request matcher; the first matching chain handles the request.

In Spring Boot the security filter chain is a bean registered with SecurityProperties.DEFAULT_FILTER_ORDER. Additional chains can be added by defining a @Configuration class extending WebSecurityConfigurerAdapter and annotating it with @Order.

Static resources (e.g., /css/**, /images/**) are ignored by default, while the final chain (pattern /**) contains authentication, authorization, exception handling, session management, etc.

Actuator endpoints have their own filter chain with a higher order; custom security rules can be applied before or after the actuator chain by adjusting the order.

Note All Spring Security filters are unknown to the servlet container, which is why custom filters must be registered as @Bean or wrapped in a FilterRegistrationBean with registration disabled.

Method Security

Method‑level protection is enabled with @EnableGlobalMethodSecurity. Annotations such as @Secured("ROLE_USER"), @PreAuthorize, and @PostAuthorize apply the same ConfigAttribute concepts to individual service methods.

When a secured bean is invoked, Spring creates a proxy that checks the current Authentication from the SecurityContextHolder and throws an AccessDeniedException if the check fails.

Working with Threads

Security information is stored in a thread‑local SecurityContext. Code can obtain the current authentication via:

SecurityContext context = SecurityContextHolder.getContext();
Authentication authentication = context.getAuthentication();
assert authentication.isAuthenticated();

Custom asynchronous code must propagate the security context, e.g., by using DelegatingSecurityContextExecutorService in an AsyncConfigurer.

Asynchronous Security Configuration

Because SecurityContext is thread‑bound, background tasks executed with @Async need the context wrapped. Spring Security provides helpers such as DelegatingSecurityContextExecutorService to achieve this.