【个人版】SpringBoot下Spring-Security核心概念解读【二】
Spring-Security + HttpSecurity
Spring-Security全局导读：
1、Security核心类设计
2、HttpSecurity结构和执行流程解读
3、Spring-Security个人落地篇
背景： Spring-Security框架的核心架构上一篇已经概述，展示其执行流程及逻辑，但是和我们实际使用有点差距，相信大家在使用此框架时，肯定被以下代码迷惑过：
@Configuration
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.csrf().disable()
.formLogin().disable()
.authorizeRequests().antMatchers(HttpMethod.OPTIONS).permitAll()
.anyRequest().authenticated()
.and().logout().logoutSuccessHandler(authResult).permitAll()
.and().exceptionHandling().authenticationEntryPoint(authResult);
}
}
上述代码直接看就是一串httpSecurity对象的链式配置，但很多问题没有还需明确：
1、HttpSecurity可以设置哪些配置点? 重点配置有哪些？
2、链条中为什么需要add方法？是否必须？
3、每个配置点底层以何种形式存在？执行时机或顺序如何定义？
4、HttpSecurity除了链式配置外，还需要哪些配置？
5、在适配模式下使用，重写的configure方法何时执行？
6、HttpSecurity在何处以何种方式被使用的？
下面将在以上问题的基础上，对HttpSecurity做自我理解后的解读：
基础条件：
1、SpringBoot的Web项目【版本2.7.14】
2、集成相关spring-security的starter依赖
解答一、HttpSecurity的由来
上下文自动配置类：
org.springframework.boot.autoconfigure.security.servlet.SecurityAutoConfiguration
org.springframework.boot.autoconfigure.security.servlet.UserDetailsServiceAutoConfiguration
org.springframework.boot.autoconfigure.security.servlet.SecurityFilterAutoConfiguration
引入Security注解开关：
org.springframework.security.config.annotation.web.configuration.EnableWebSecurity
传递关系(依次由上到下):
- SecurityAutoConfiguration
- SpringBootWebSecurityConfiguration
- WebSecurityEnablerConfiguration
- EnableWebSecurity
进而引入Security框架核心类的配置类：
AuthenticationConfiguration => AuthenticationManager管理类
WebSecurityConfiguration => WebSecurity配置类
HttpSecurityConfiguration => HttpSecurity配置类
HttpSecurity创建代码简化版：
@Configuration(
proxyBeanMethods = false
)
class HttpSecurityConfiguration {
private ObjectPostProcessor<Object> objectPostProcessor; // 框架类初始化增强类，后续单独讲
private AuthenticationManager authenticationManager; // 授权管理器，核心依赖类，可自定义，可系统自动配置，后续单独讲
private AuthenticationConfiguration authenticationConfiguration; // 授权管理器配置类，作为父授权管理器托底
private ApplicationContext context;
@Scope("prototype")
@Bean({"org.springframework.security.config.annotation.web.configuration.HttpSecurityConfiguration.httpSecurity"})
HttpSecurity httpSecurity() throws Exception {
WebSecurityConfigurerAdapter.LazyPasswordEncoder passwordEncoder = new WebSecurityConfigurerAdapter.LazyPasswordEncoder(this.context);
// 创建授权管理器构建类，parent设置时可以全局搜索我们自定义的AuthenticationProvider类，就不用通过构建器手工设置
AuthenticationManagerBuilder authenticationBuilder = new WebSecurityConfigurerAdapter.DefaultPasswordEncoderAuthenticationManagerBuilder(this.objectPostProcessor, passwordEncoder);
authenticationBuilder.parentAuthenticationManager(this.authenticationManager());
// 实例化HttpSecurity
HttpSecurity http = new HttpSecurity(this.objectPostProcessor, authenticationBuilder, this.createSharedObjects());
// 初始化HttpSecurity安全管理逻辑，如logout、登录页、异常等场景设置，都是默认配置，做到开箱即用
http.csrf(Customizer.withDefaults()).addFilter(new WebAsyncManagerIntegrationFilter()).exceptionHandling(Customizer.withDefaults()).headers(Customizer.withDefaults()).sessionManagement(Customizer.withDefaults()).securityContext(Customizer.withDefaults()).requestCache(Customizer.withDefaults()).anonymous(Customizer.withDefaults()).servletApi(Customizer.withDefaults()).apply(new DefaultLoginPageConfigurer());
http.logout(Customizer.withDefaults());
this.applyDefaultConfigurers(http); // SpringFactoriesLoader.loadFactories(AbstractHttpConfigurer.class, classLoader) -- 默认factories加载实现类，忽略
return http;
}
private AuthenticationManager authenticationManager() throws Exception {
return this.authenticationManager != null ? this.authenticationManager : this.authenticationConfiguration.getAuthenticationManager();
}
// HttpSecurity内部全局共享实例集合，核心类都会在此保存并重复使用
private Map<Class<?>, Object> createSharedObjects() {
Map<Class<?>, Object> sharedObjects = new HashMap();
sharedObjects.put(ApplicationContext.class, this.context);
return sharedObjects;
}
}
除代码中标注的注释外，还需要注意：
1、注意HttpSecurity上@Bean发布范围是多例，因为可以Proxy下可以配置多个过滤器链（注：如果在不同类或同一个类的不同地方多次引用，相关配置会错乱，除非自己另行全局封装）
2、AuthenticationManager是部分Filter的核心依赖，尤其涉及我们自定义鉴权部分的代码，其主旨为拦截后对接口具体的参数处理与返回，也就是我们的鉴权逻辑。
解答二：HttpSecurity结构之配置与构建过程
作为一个框架的核心类，HttpSecurity的设计完成应用了多个巧妙的设计模式，使代码可读性、复用性更高。
核心设计模式一：构建器模式
构建器模式是最常见的创建型模式，在类相关实例变量相当多的场景下非常实用，避免长列表或多重载构造函数。在Security框架中，安全策略多样，每个安全策略需要管理的参数量不固定且灵活性较高（隐含意思是：HttpSecurity配置安全策略及安全策略配置具体参数都适用此场景，实际security框架就是这么设计和干的），如果采用常见if…else…语法，配置及使用过程将毫无人性，构建器模式让HttpSecurity的链式配置更加易读和使用。
Spring6中将配置器的创建改成lambda形式，进一步缩短HttpSecurity的配置层次，将配置器的创建与HttpSecurity的配置解耦，这就是框架的魅力。
构建器模式代码结构很简单，难点在于安全知识点的理解与调控，开发过程中注意参数变化导致的配置器的失效问题，下面将简单列举来进一步说明：
1、图中1处的logout无参方法返回配置器Configurer的实例对象，我们通过配置内部构建方法进一步配置其他参数值，结束配置可用HttpSecurity另起一行配置新的配置器，或者使用logout配置器的and方法继续链式配置其他配置器
2、图中2处的logout有参方法提供了一个自定义构造器参数，可以对系统默认的Configurer实例做进一步配置，可对象可由lambda表达式代替，Spring6已经全面像此场景靠拢（部分人对过长的HttpSecurity链无感）
配置器操作中其实隐含一个非常重要的操作，可以看到图中的getOrApply方法。该方法一方面将Configurer实例添加到HttpSecurity的全局缓存中，并将HttpSecurity的实例对象的引用传递进原Configurer内部，做到相交相融，还有将Configurer从普通new出的实例进一步提级，完成类似spring容器里的实例对象的生命周期的管理。根据反馈效果，后续可追加解读。
核心设计模式二：模板模式
模板模式常用在继承结构，HttpSecurity继承了AbstractConfiguredSecurityBuilder -> AbstractSecurityBuilder抽象类，该抽象类将构建方法完全委托给实现类完成，已知实现类有：HttpSecurity、WebSecurity、AuthenticationManagerBuilder，可以看到这三个类正是Security框架的核心。模板模式特点之xxx -> doXxx，构建过程如下：
protected final O doBuild() throws Exception {
synchronized(this.configurers) {
this.buildState = AbstractConfiguredSecurityBuilder.BuildState.INITIALIZING;
this.beforeInit();
this.init();
this.buildState = AbstractConfiguredSecurityBuilder.BuildState.CONFIGURING;
this.beforeConfigure();
this.configure();
this.buildState = AbstractConfiguredSecurityBuilder.BuildState.BUILDING;
O result = this.performBuild();
this.buildState = AbstractConfiguredSecurityBuilder.BuildState.BUILT;
return result;
}
}
构建流程说明：
1、beforeInit()
- 尴尬，三个实现类都忽略了
2、init()
- 执行所有安全配置器的初始化代码，即configurer.init(HttpSecurity)
3、beforeConfigure()
- 授权管理器实例化并添加到sharedObjects集合，AuthenticationManagerBuilder在此构建后状态标记已变更，不可重新变更，只能获取并使用。构建后的实例，可以注入到HttpSecurity中可以创建Filter的配置器中，自定义安全Filter需要人工或特殊配置来设置。（这块有一定的操作空间）
4、configure()
- 这个方法和init方法相辅相成，前面已经完成各配置器的初始化，现完成调用各配置器Configurer的configure方法，逐一完成对HttpSecurity的配置。(此块即完成security框架内部Filter的添加，例：LogoutFilter)
5、performBuild()
- HttpSecurity构建的结果就是SecurityFilterChain对象，此对象的功能就是用来管理security内部Filter集合，创建逻辑也很简单：new DefaultSecurityFilterChain(this.requestMatcher, sortedFilters)。关于SecurityFilterChain的介绍，请点击并移步至此篇。
概要说明：
1、构建流程的入口是我们HttpSecurity.build方法，该方法可由我们主动触发，在WebSecurityConfigurerAdapter适配器模式下，由框架触发
2、授权管理器用来鉴权逻辑，所以一般配置器生产的Filter实例可不用配置，必要的Filter也会做检查。授权管理器对应的构建器在代码里有一定的操作空间，其构建状态影响较大。
3、添加到HttpSecurity的内部安全Filter有很多，这些Filter不影响我们正常使用的ApplicationFilterChain的执行流程，各Filter在集合中的顺序有默认顺序（详见FilterOrderRegistration，包含所有内部过滤器清单及Order），自定义Filter可通过HttpSecurity.addFilterBefore/After等方法指定。
总结：
通过上述两大设计模式对Security框架的解读，文章开篇的几个问题基本都涵盖了，自己可以对照着解读，根据问题和自己的理解去源码中进一步验证，再来一遍debug，基本就可以结束了。下面文章将根据这两篇前缀，直接出一个完整的个人版落地篇，也就是我们实际使用这个框架的内容了。
PS：还有一个重要流程其实没有阐述，就是上一篇的FilterChainProxy与本篇的HttpSecurity构建的SecurityFilterChain对象是如何绑定的，其答案为：WebSecurity通过控制HttpSecurity的配置与构建过程生成SecurityFilterChain，在对应构建方法中使用FilterChainProxy包装，进而发布到外部ApplicationFilterChain过滤器链中。如果感兴趣，以后有机会再开篇详解。