Spring Security是一个功能强大且高度且可定制的身份验证和访问控制框架，除了标准的身份认证和授权之外，它还支持点击劫持，CSRF，XSS，MITM（中间人）等常见攻击手段的保护，并提供密码编码，LDAP认证，Session管理，Remember Me认证，JWT，OAuth 2.0等功能特性。
由于安全领域本身的复杂性和丰富的安全特性支持，以及Spring Security高度的可定制性，使得它成为一个庞大且复杂的框架。每次升级可能带来的破坏性更新，加上网络上的陈旧教程，更是加重了Spring Security非常难用的印象。很多新手可能跟作者一样，首次引入Spring Security框架之后，突然发现很多页面无法访问，感到无所适从。
为此，本文将基于Spring Boot 3.1.x依赖的Spring Security 6.1.x版本，深入探讨Spring Security的架构和实现原理。本文将着重解释Spring Security的设计思想，而不会过多涉及具体的实现细节。
文章的目标是让读者在阅读完本文之后，能够对整个Spring Security框架有个清晰的理解，并在面对问题时知道如何着手排查。另外，本文重点关注Spring Security的总体架构，以及身份认证(Authentication)和鉴权控制(Authorization)的实现。
❝
【版本兼容性】Spring Security 6引入了很多破坏性的更新，包括废弃代码的删除，方法重命名，全新的配置DSL等，但是架构和基本原理还是保持不变的。本文在讲解过程中会尽量指出当前版本跟老版本的差异，尤其是涉及到兼容性问题的时候。【阅读提示】本文的篇幅较长，并且包含了部分源码分析，时间有限的情况下，可以重点阅读架构图部分。
大家可以尝试思考下，安全相关的校验和处理，应该处于应用的哪个部分呢？答案是，应该放在所有请求的入口，因为它是跟具体的业务逻辑无关的，在Spring MVC世界里就是@Controller之前。
在JakartaEE(JavaEE的新版)规范中，Filter和Servlet都符合这个前置要求。然而，Spring的Web应用基本上只包含一个DispatcherServelt，主要用于请求分发，缺乏安全相关的支持和合适的扩展机制。而Filter运行在Servlet之前，而规范本身就支持配置多个Filter。因此，在请求到达Servlet之前，先通过Filter进行安全验证就是一个非常合理的实现方式。这样可以在请求进入业务逻辑之前，对请求进行拦击，然后进行必要的安全性检查和处理。
这也是Spring Security的实现方式。本质上，Spring Security的实现原理很简单，就是提供了一个用于安全验证的Filter。假如我们自己实现一个简化版的Filter，它的大概逻辑应该是这样的：
public class SimpleSecurityFilter extends HttpFilter { @Override protected void doFilter(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException { UsernamePasswordToken token = extractUsernameAndPasswordFrom(request); // (1) if (notAuthenticated(token)) { // (2) // 用户名密码错误 response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); // HTTP 401. return; } if (notAuthorized(token, request)) { // (3) // 当前登录用户的权限不足 response.setStatus(HttpServletResponse.SC_FORBIDDEN); // HTTP 403 return; } // 通过了身份验证和权限校验，继续执行其它Filter，最终到达Servlet chain.doFilter(request, response); // (4) }}FilterChain
在安全领域，由于攻防手段的多样性和认证鉴权方式的复杂性，将所有功能都放在一个Filter中会导致该Filter迅速演变为一个庞大而复杂的类。
因此，在实际应用场景中，我们常常将这个庞大的Filter拆分成多个小Filter，并将它们链接在一起。每个Filter都只负责特定领域的功能，比如CsrfFilter，AuthenticationFilter，AuthorizationFilter等。
这种概念被称为FilterChain，实际上JarkataEE规范也有相识的概念。通过使用FilterChain，你就可以以插拔的方式添加或移除特定功能的Filter，而无需改动现有的代码。
上一节其实已经说明了Spring Security框架的基本思路，下面我们深入分析其实现原理和架构。
一个应用引入了Spring Security Starter包后，再启动应用，你会发现控制台多了下面这条日志，说明已经开启了Security特性。
2023-07-12T10:05:23.168+08:00 INFO 680540 --- [main] o.s.s.web.DefaultSecurityFilterChain : Will secure any request with [org.springframework.security.web.session.DisableEncodeUrlFilter@46e3559f, org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@3b83459e, org.springframework.security.web.context.SecurityContextHolderFilter@26837057, org.springframework.security.web.header.HeaderWriterFilter@2d74c81b, org.springframework.security.web.csrf.CsrfFilter@3a17b2e3, org.springframework.security.web.authentication.logout.LogoutFilter@5f5827d0, org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter@4ed5a1b0, org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter@3b332962, org.springframework.security.web.authentication.ui.DefaultLogoutPageGeneratingFilter@32118208, org.springframework.security.web.authentication.www.BasicAuthenticationFilter@67b355c8, org.springframework.security.web.savedrequest.RequestCacheAwareFilter@991cbde, org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@dd4aec3, org.springframework.security.web.authentication.AnonymousAuthenticationFilter@414f87a9, org.springframework.security.web.access.ExceptionTranslationFilter@59939293, org.springframework.security.web.access.intercept.AuthorizationFilter@f438904]从这条日志可以观察到，Spring Security通过DefaultSecurityFilterChain类来完成安全相关的功能，而该类本身又由其它Filter组成。默认情况下，Spring Security Starter引入了15个Filter，下面我们简要介绍下其中几个重要的Filter：
这些Filter构成了Spring Security的核心功能，通过它们，我们可以实现身份验证、授权、防护等安全特性。根据应用的需求，我们可以选择启用或禁用特定的Filter，以定制和优化安全策略。
DefaultSecurityFilterChain类实现了SecurityFilterChain接口，我们打开这个接口的源码，会发现它只有两个方法，matches用于匹配特定的Http请求（比如特定规则的URL），getFilters 用于获取可用的所有Security Filter。
public interface SecurityFilterChain { boolean matches(HttpServletRequest request); // 规则匹配 List<Filter> getFilters(); // 该FilterChain下的所有Security Filter}从这段代码可以得出两个结论：
实际上，JakartaEE层面上的Filter实现是DelegatingFilterProxy类，它在Spring Security中起到了一个重要的桥梁作用，连接了Servlet容器和Spring容器。Servlet容器不了解Spring定义的Beans，而Spring Security的大部分组件及其依赖都是注册到Spring容器中的Bean。
DelegatingFilterProxy核心代码的主要工作就是从WebApplicationContext获取指定名称的Filter Bean，然后委托给这个Bean的doFilter方法。以下是简化后的伪代码：
public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws ServletException, IOException { Filter delegateToUse = this.delegate; if (delegateToUse == null) { synchronized (this.delegateMonitor) { delegateToUse = this.delegate; if (delegateToUse == null) { WebApplicationContext wac = findWebApplicationContext(); // 获取Filter Bean并初始化 delegateToUse = initDelegate(wac); } this.delegate = delegateToUse; } } // 委托给的delegate对象完成实际的doFilter invokeDelegate(delegateToUse, request, response, filterChain);}protected Filter initDelegate(WebApplicationContext wac) throws ServletException { // Bean名称配置在SecurityFilterAutoConfiguration.DEFAULT_FILTER_NAME = "springSecurityFilterChain" String targetBeanName = getTargetBeanName(); // 从容器中获取指定名称的Filter类型Bean Filter delegate = wac.getBean(targetBeanName, Filter.class); if (isTargetFilterLifecycle()) { delegate.init(getFilterConfig()); } return delegate;}通过这种方式，DelegatingFilterProxy实现了将Servlet容器中的Filter请求委托给Spring容器中的具体Filter Bean处理，从而实现了Servlet容器和Spring容器之间的无缝连接。
而这个被委托的Filter Bean的类型就是FilterChainProxy，是在WebSecurityConfiguration中配置的：
// name = "springSecurityFilterChain"@Bean(name = AbstractSecurityWebApplicationInitializer.DEFAULT_FILTER_NAME)public Filter springSecurityFilterChain() throws Exception { // 配置SecurityFilterChain boolean hasFilterChain = !this.securityFilterChains.isEmpty(); if (!hasFilterChain) { this.webSecurity.addSecurityFilterChainBuilder(() -> { this.httpSecurity.authorizeHttpRequests((authorize) -> authorize.anyRequest().authenticated()); this.httpSecurity.formLogin(Customizer.withDefaults()); this.httpSecurity.httpBasic(Customizer.withDefaults()); return this.httpSecurity.build(); }); } for (SecurityFilterChain securityFilterChain : this.securityFilterChains) { this.webSecurity.addSecurityFilterChainBuilder(() -> securityFilterChain); } // WebSecurity自定义配置 for (WebSecurityCustomizer customizer : this.webSecurityCustomizers) { customizer.customize(this.webSecurity); } // FilterChainProxy最终是由WebSecurity构建出来的 return this.webSecurity.build();}从上面代码可以发现，FilterChainProxy对象最终是由WebSecurity根据SecurityFilterChain和其它一些配置构建出来的。
FilterChainProxy主要作用就是查找匹配当前Http请求规则的SecurityFilterChain，然后将工作委派给SecurityFilterChain的所有Filter。简化后的伪代码如下所示：
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { // 获取匹配的所有Filter List<Filter> filters = getFilters(request); // 按顺序执行Filter Filter nextFilter = this.filters.get(this.currentPosition - 1); nextFilter.doFilter(request, response, this);}private List<Filter> getFilters(HttpServletRequest request) { for (SecurityFilterChain chain : this.filterChains) { // 返回匹配规则的SecurityFilterChain的Filter列表 if (chain.matches(request)) { return chain.getFilters(); } } return null;}❝
【Tips】FilterChainProxy可以认为是整个Spring Security处理请求的一个起点，如果你遇到Security相关问题，又不清楚是具体哪个Filter导致的，就可以从这里开始Debug。
从上一节的内容，我们可以得出下面这一副架构图（图中蓝色和橘红色的部分代表Security Security）。从图中可以看出，Spring Security框架通过DelegatingFilterProxy建立起了Servlet容器和Spring容器的链接，FilterChainProxy基于匹配规则（比如URL匹配），决定使用哪个SecurityFilterChain。而SecurityFilterChain又由零到多个Filter组成，这些Filter完成实际的功能。
图片
Spring Security是基于Jakarta EE的Filter实现的，而在此基础上，它提供了一套自身的Filter机制，相当于两层的Filter嵌套。为了不混淆这两种Filter，我们把Spring Security框架提供的Filter称为Security Filter。在下文中，我们所提及的配置，扩展和自定义的Filter都指的是Security Filter，如果没有特别说明，都默认指的是Security Filter。
通过一系列Security Filter，Spring Security提供了丰富的开箱即用的安全功能，包括身份认证，鉴权，Csrf等等。每个功能都是通过一个或者多个Security Filter实现的。有些复杂的Filter，例如身份认证和鉴权，拥有自己的特定架构，并且会依赖Filter的顺序和执行过程中的上下文信息，这也是导致Spring Security在使用上相对复杂的原因之一。
Spring Securiy的基本配置都是通过自定义SecurityFilterChain的Bean来实现的。下面是一个示例配置，它提供了自定义的登录页面，并且针对不同的URL配置了不同的角色权限，这些配置方法实际上就是配置不同的Security Filter，更详细的解释会在后面讲解具体特性的时候时展开说明。
@Beanstatic SecurityFilterChain mySecurityFilterChain(HttpSecurity http) throws Exception { // 鉴权相关配置 http.authorizeHttpRequests((requests) -> request.requestMatchers("/admin").hasAuthority("ROLE_ADMIN") // "/admin"要求有“ROLE_ADMIN"角色权限 .requestMatchers("/hello").hasRole("USER") // "/hello"要求有"ROLE_USER"角色权限 .anyRequest().authenticated()); // 其它只需要身份认证通过即可，不需要其它特殊权限 // 登录相关配置 http.formLogin(formLogin -> formLogin .loginPage("/authentication") // 自定义登录页面，不再使用内置的自动生成页面 .permitAll() // 允许自定义页面的匿名访问，不需要认证和鉴权 ); return http.build(); // 返回构建的SecurityFilterChain实例}【版本兼容性】Spring Security 6.0在配置方面引入了许多改变。在之前的老版本中，可以选择废弃的WebSecurityConfigurerAdapter进行配置，但从6.0版本开始，这个废弃类已经被删除了。而目前很多老项目以及网上的教程仍在使用WebSecurityConfigurerAdapter。另外，配置DLS也发生了变化。Spring Security 6.0采用了基于Lambda表达式的DSL配置方式，取代了之前的纯链式调用方式，使得配置更加灵活和直观。一些方法名称也进行了修改，例如antMatchers替换为requestMatchers。
除了Spring Boot的专有配置，Spring Security自身也提供了默认配置，这些默认配置在HttpSecurityConfiguration#httpSecurity方法中，它默认添加了很多Security Filter，核心代码如下：
@Bean(HTTPSECURITY_BEAN_NAME)@Scope("prototype")HttpSecurity httpSecurity() throws Exception { // ... // http .csrf(withDefaults()) .addFilter(webAsyncManagerIntegrationFilter) .exceptionHandling(withDefaults()) .headers(withDefaults()) .sessionManagement(withDefaults()) .securityContext(withDefaults()) .requestCache(withDefaults()) .anonymous(withDefaults()) .servletApi(withDefaults()) .apply(new DefaultLoginPageConfigurer<>()); http.logout(withDefaults()); // ... // return http;}以上解释了Spring Security的实现原理和基本架构，而具体到特定的Security Filter，又有各种的框架，下面将展开说明认证和鉴权两个核心模块。
身份认证有很多种方式，大致可以分为以下4类：
Spring Security支持大部分的认证方式，但不同的认证方式需要配置不同的Bean及其依赖Bean，否则很容易遇到各种异常和空指针。
本文重点讨论标准的账号密码认证方式。
如果你使用的是Spring Boot，那么Spring Boot Starter Security默认就配置了Form表单和Basic认证方式，其配置代码如下所示：
@Configuration(proxyBeanMethods = false)@ConditionalOnWebApplication(type = Type.SERVLET)class SpringBootWebSecurityConfiguration { @Configuration(proxyBeanMethods = false) @ConditionalOnDefaultWebSecurity static class SecurityFilterChainConfiguration { @Bean @Order(SecurityProperties.BASIC_AUTH_ORDER) SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests((requests) -> requests.anyRequest().authenticated()); // 所有URL都需要认证用户 http.formLogin(withDefaults()); // 支持form表单认证，默认配置提供了自动生成的登录和注销页面 http.httpBasic(withDefaults()); // 支持HTTP Basic Authentication return http.build(); } } // ...其它配置...}为了讨论方便，我们用下面的配置覆盖Spring Boot默认的配置，只支持Form表单认证方式，讨论它具体是如何实现的。
@Configuration() public class MySecurityConfig { @Bean SecurityFilterChain mySecurityFilterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests((requests) -> requests.anyRequest().authenticated()); // (1) http.formLogin(withDefaults()); // (2) return http.build(); }}在本节中，我们主要讨论身份认证的实现，因此，接下来将详细探究Form表单认证方式中UsernamePasswordAuthenticationFilter的实现。
对于Filter，我们重点分析它的doFilter方法的源码。实际上，它继承了抽象类AbstractAuthenticationProcessingFilter，而这个抽象类的doFilter是一个模板方法，定义了整个认证流程。其核心流程非常简单，伪代码如下：
private void doFilter(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException { // 首先判断该请求是否是认证请求或者登录请求 if (!requiresAuthentication(request, response)) { // (1) chain.doFilter(request, response); return; } try { Authentication authenticationResult = attemptAuthentication(request, response); // (2) 实际认证逻辑 // 认证成功 successfulAuthentication(request, response, chain, authenticationResult); // (3) } catch (AuthenticationException ex) { // 认证失败 unsuccessfulAuthentication(request, response, ex); // (4) }}在这里，我们涉及到了一个非常重要的数据模型——Authentication，它是一个接口类型，它既是对认证结果的一个抽象表示，同时也是对认证请求的一个抽象，通常也被称为认证Token。它的方法都比较抽象，定义如下：
public interface Authentication extends Principal, Serializable { // 当前认证用户拥有的权限列表 Collection<? extends GrantedAuthority> getAuthorities(); // 用户的一个身份标识，通常就是用户名 Object getPrincipal(); // 可用于证明用户身份的一个凭证，通常就是用户密码 Object getCredentials(); // 当前用户是否认证通过 boolean isAuthenticated(); // 更新用户的认证状态 void setAuthenticated(boolean isAuthenticated) throws IllegalArgumentException; // 获取附加的详情信息，比如原始的Http请求体等。 Object getDetails();}具体的Authentication实现一般都命名为XXXToken，大部分都继承自抽象类AbstractAuthenticationToken，比如表示标准的用户名密码认证结果的UsernamePasswordAuthenticationToken，表示匿名登录用户认证结果的AnonymousAuthenticationToken等等，你也可以完全实现自己的Authentication。
接下来，我们看下UsernamePasswordAuthenticationFilter的认证具体实现方法attempAuthentication，它的源码如下：
public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response) throws AuthenticationException { // 默认只支持POST请求 if (this.postOnly && !request.getMethod().equals("POST")) { throw new AuthenticationServiceException("Authentication method not supported: " + request.getMethod()); } // 从form表单获取用户名和密码 String username = obtainUsername(request); username = (username != null) ? username.trim() : ""; String password = obtainPassword(request); password = (password != null) ? password : ""; // 构建一个用于认证的请求 UsernamePasswordAuthenticationToken authRequest = UsernamePasswordAuthenticationToken.unauthenticated(username, password); // 附加详细信息，比如请求体，有些认证方式需要除了用户名密码外更多的信息 setDetails(request, authRequest); // 委托给AuthenticationManager做具体的认证 return this.getAuthenticationManager().authenticate(authRequest);}这个方法非常简单，它主要进行一些前置校验工作，从请求体中获取用户名和密码，并构建认证请求对象。然后，剩余的认证工作都是委托给AuthenticationManager接口来完成的，该接口的定义如下：
public interface AuthenticationManager { Authentication authenticate(Authentication authentication) throws AuthenticationException;}AuthenticationManager接口只有一个方法，它的入参和出参都是Authentication对象。通常情况下，入参提供了必要的认证信息，例如用户名和密码。而在认证成功后，该方法会返回认证结果，并附加认证状态，用户拥有的权限列表等信息。如果认证失败，它会抛出AuthenticationException异常类的子类，其中包括DisabledException，LockedException和BadCredentialsException等账号相关的异常。
AuthenticationManager接口定义了Spring Security的认证行为。你可以提供自定义的实现，Spring Security也提供了一个通用的实现类ProviderManager。ProviderManager将具体的认证工作委托给一系列的AuthenticationProvider。
每个AuthenticationProvider对应不同的认证方式。比如最常见的用户名密码的认证实现是DaoAuthenticationProvider，而JwtAuthenticationProvider提供了JWT Token的认证。你可以通过添加不同的AuthenticationProvider的方式，在同一个服务内支持多种类型的认证方式，比如需要调用其它API检验密码的情况，就需要自定义AuthenticationProvider。
此外，ProviderManager还可以配置父级AuthenticationManager，当这个ProviderManager的所有AuthenticationProvider都不支持所需的认证方式时，它会继续委托给父级的AuthenticationManager，而该父级通常也是一个ProviderManager类型。
UserDetailsService和PasswordEncoder
DaoAuthenticationProvider是最常用的认证实现之一，它通过UserDetailsService和PasswordEncoder来验证用户名和密码。
UserDetailsService的作用是查找用户信息UserDetails，这些信息包括用户密码，状态，权限列表等。用户信息可以存储在内存，数据库或者其它任何地方。Spring Security默认的配置是内存存储，对应的UserDetailsService实现是InMemoryUserDetailsManager，而数据库存储则对应JdbcUserDetailsManager。
从UserDetailsService获取到用户密码后，需要通过PasswordEncoder来验证密码的正确性。因为密码一般都不应该以明文形式存储，实际存储的是按一定规则编码后的文本，Spring Security支持多种编码方式，例如bcrypt，argon2，scrypt，pbkdf2等。你可以配置PasswordEncoder Bean来选择不同的编码方式。都是请注意，内置的编码方式默认对编码后的文本有一个格式要求，就是必须有类似{bcrypt}的前缀来表示编码方式。
上一节中，我们讲述了用户名密码认证的实现细节，现在，让我们以用户名密码认证方式为例，从整体上来看下身份认证的架构和流程。它的整体架构如下：
这个架构非常灵活，大部分组件都是可配置和可替换的，自底向上，我们分别可以替换以下组件来满足特定需求：
【Tips】从整个Security框架的角度来看，认证模块的核心概念只有两个，分别是认证结果Authentication和Security Context。其它概念都可以认为是认证模块的内部实现细节。
认证模块证明了用户的身份，但显然普通用户不应该可以随意访问管理页面或敏感资源，因此还需要有个模块来确保只有授权的用户才能执行特定的操作，这个模块称之为鉴权或者授权(Authorization)。
当你通过HttpSecurity.authorizeHttpRequests方法来配置请求的访问权限控制时，就会自动添加鉴权的Security Filter：AuthorizationFilter，它是整个SecurityFilterChain的最后一个Filter。
【版本兼容性】在Spring Security 6.0版本中，鉴权模块发生了很大变化。以前的版本中，鉴权模块使用FilterSecurityInterceptor，而6.0版本之后，这个被废弃了，取而代之的是AuthorizationFilter。同时，还有一些相关的依赖组件，如AccessDecisionManager和AccessDecisionVoter也被AuthorizationManger替换了。因此，本节的内容只限于6.0以及之后的版本。
我们先看下鉴权模块的入口，也就是AuthorizationFilter的doFilter方法：
@Overridepublic void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) throws ServletException, IOException { // ...其它非核心逻辑... // try { AuthorizationDecision decision = this.authorizationManager.check(this::getAuthentication, request); // （1） this.eventPublisher.publishAuthorizationEvent(this::getAuthentication, request, decision); if (decision != null && !decision.isGranted()) { // （2） throw new AccessDeniedException("Access Denied"); } chain.doFilter(request, response); } finally { request.removeAttribute(alreadyFilteredAttributeName); }}private Authentication getAuthentication() { Authentication authentication = this.securityContextHolderStrategy.getContext().getAuthentication(); // （3） if (authentication == null) { throw new AuthenticationCredentialsNotFoundException( "An Authentication object was not found in the SecurityContext"); } return authentication;}AuthorizationManager才是真正执行鉴权逻辑的类，最常用的实现类是AuthorityAuthorizationManager，它的实现逻辑很简单，它会调用Authentication的getAuthorities方法，获取当前登录用户的权限列表，然后将这些权限与请求需要的权限进行匹配。
实际上，选择使用哪个AuthorizationManager是开发手动设置的。我们来分析一个常用的权限配置代码片段：
@Beanstatic SecurityFilterChain mySecurityFilterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests((requests) -> // （1） requests .requestMatchers("/admin").hasAuthority("ROLE_ADMIN") // （2） .requestMatchers("/hello").hasRole("USER") // （3） .anyRequest().authenticated()); // （4） // ... 其它配置 ... // return http.build();}在Spring Security中，很多初学者都容易混淆Role和Authority的区别，实际上在技术实现层面上，这两者没有本质区别，底层都仅仅是一个表示权限的字符串标识符。更多的区别在于权限管理的概念上，一般情况下，Authority表示细粒度的操作权限，比如ADD_USER，DELETE_USER等，通常是动词；而Role则会与实际业务角色想对应，比如管理员ADMIN，普通员工STAFF等，通常是名称。此外，一般一个Role会对应多个Authority，同时角色之间可以存在继承关系，比如ADMIN可以继承STAFF的所有权限。
我们来看下hasAuthority的源码，以分析它是如何配置AuthorizeManager的：
public AuthorizationManagerRequestMatcherRegistry hasAuthority(String authority) { return access( // （3） withRoleHierarchy( //（2） AuthorityAuthorizationManager.hasAuthority(authority) // （1） ) );}public static <T> AuthorityAuthorizationManager<T> hasAuthority(String authority) { Assert.notNull(authority, "authority cannot be null"); return new AuthorityAuthorizationManager<>(authority);}public AuthorizationManagerRequestMatcherRegistry access( AuthorizationManager<RequestAuthorizationContext> manager) { Assert.notNull(manager, "manager cannot be null"); return AuthorizeHttpRequestsConfigurer.this.addMapping(this.matchers, manager);}private AuthorityAuthorizationManager<RequestAuthorizationContext> withRoleHierarchy( AuthorityAuthorizationManager<RequestAuthorizationContext> manager) { manager.setRoleHierarchy(AuthorizeHttpRequestsConfigurer.this.roleHierarchy.get()); return manager;}access方法是公开的，你可以自己实现一个AuthorizationManager，然后通过这个方法进行注册。例如，我们可以提供一个拒绝所有请求的实现：
http.authorizeHttpRequests((requests) -> requests.anyRequest().access((authentication, object) -> null));【Tips】通过自定义AuthorizationManager，我们可以完全接管鉴权的逻辑，实现更加灵活和复杂的权限控制。
相比认证模块，鉴权模块不需要太多的灵活性和扩展性需求，因此它的架构相对简单。
同样，我们以一个标准的鉴权流程为例，来看整体的架构和流程图。
本文重点分析了Spring Security的源码和架构，帮助读者理解其实现原理。由于篇幅有限，本文只覆盖了身份认证和鉴权模块的核心逻辑，很多特性没有涉及，包括Session管理，Remember Me服务，异常分支和错误处理等等，不过有了上述的基础知识，读者完全可以自己分析源码并深入理解这些特性。
认证和鉴权失败抛出的异常是如何处理的？
当发生认证或鉴权失败时，Spring Security有专门的Security Filter ExceptionTranslationFilter来捕获并处理这些异常。如果是认证异常错误AuthenticationException及其子类，会触发AuthenticationEntryPoint#commence方法，而如果是鉴权错误AccessDeniedException及其子类，则会触发AccessDeniedHandler#handle方法。
一个请求被Security拒绝了，应该如何Debug排查？
如果遇到身份认证错误，建议直接Debug相关Filter的doFilter方法，比如Form表单登录的Filter就是UsernamePasswordAuthenticationFilter；而如果是鉴权错误，可以从AuthorizationFilter开始Debug。
但需要注意的是，出于安全考虑，Security相关的错误通常不会提供明确的错误信息，甚至不会显示错误信息，而是直接跳转到登录页面，比如CsrfFilter可能会导致这种情况。在这种情况下，可以从第一个Filter开始Debug，启动日志搜索Will secure any request with，就可以找到所有Security Filter列表。或者直接从入口FilterChainProxy#doFilter开始Debug。
SecurityFilterChain的配置方法底层是如何实现的？
SecurityFilterChain是通过HttpSecurity提供的一套DSL进行配置的。诸如formLogin，csrf，authorizeHttpRequests等方法的逻辑都类似，参数都是一个lambda表达式，用于做各种自定义配置。而每个方法都会对应一个特定的配置类，比如FormLoginConfigurer，CsrfConfigurer等，在执行HttpSecurity#build方法的时候，会调用这些配置类的configure方法，该方法的作用就是根据用户的自定义配置，创建一个或者多个Security Filter，并将其注册到SecurityFilterChain。
此外，开发者还可以通过HttpSecurity.addFilter方法直接添加自定义的Security Filter。而对于复杂且有许多配置选项的Filter，也可以自定义SecurityConfigurerAdapter类，并通过HttpSecurity#apply方法来配置和注册Filter。
Spring Security Starter有哪些默认配置？
Spring Security Starter默认配置在spring-boot-autoconfigure-x.x.x包下的文件META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports中可以找到。而具体的核心配置类有HttpSecurityConfiguration和SpringBootWebSecurityConfiguration。
Spring Security版本跟本文的不一样，遇到问题如何排查？
每次Spring Security升级，尤其是大版本升级，都可能引入破坏性或者不兼容的更新。不过，基于Filter和SecuiryFilterChain的框架和架构通常是不会改变的。但是，通常会废弃掉老的配置方法，引入新的配置，某些特定模块的实现也有可能完全替换，比如6.0的鉴权模块AuthorizationFilter就完全替换了老的鉴权模块。
你可以先从Security Filter列表开始排查，也可以通过入口FilterChainProxy#doFilter来Debug。
Spring Security整体太复杂了，能不能不使用它，而完全自己实现？
Security是个一个非常复杂的领域，很多开发者对其了解不深。使用Spring Security不仅提供了大部分的安全特性，还包含了很多安全领域的最佳实践。自己从头实现安全功能成本很高，并可能缺乏一些重要的安全特性。不过Spring Security的复杂设计以及频繁的破坏性更新，的确给开发带来了很大的学习成本和维护成本。
Spring Security的架构非常灵活，因此作者的建议是，不需要完全照搬整体框架，对于不同的应用类型和场景，可以选择性地引入部分功能。比如Admin应用可以提供自定义的AuthenticationProvider，而API服务完全可以自定义Securiy Filter，只要维护好Security Context的Authentication，就可以很好的集成到Spring Security框架里，同时开发的学习和维护成本也能降到最低。
本文链接：http://www.28at.com/showinfo-26-100473-0.htmlSpring Security 6.0：深度剖析其核心实现与工作原理
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
