Spring Security解析五：WebSecurityConfigurerAdapter

Posted 2023-05-08

参考技术A

Spring Security解析三：SecurityFilterChain创建过程 章节说到，WebSecurityConfigurerAdapter是构建SecurityFilterChain的关键，在WebSecurityConfigurerAdapter的init方法中会创建一个SecurityBuilder<SecurityFilterChain>类型的实例对象【HttpSecurity】并保存到WebSecurity的securityFilterChainBuilders属性中，后续通过SecurityBuilder来完成SecurityFilterChain的创建。

WebSecurityConfigurerAdapter的源码如下

HttpSecurity的继承关系与WebSecurity几乎一样，只是多实现了一个HttpSecurityBuilder<HttpSecurity>接口，同时声明的泛型不一样。当在WebSecurity中调用HttpSecurity的build()方法构建DefaultSecurityFilterChain时，依然会逐个的执行HttpSecurity的beforeInit()、init()、beforeConfigure()、configure()以及performBuild()方法来完成构建。

总的来说，在 WebSecurityConfigurerAdapter 中创建了HttpSecurity 实例，并将该实例存入WebSecurity的集合中，同时在WebSecurityConfigurerAdapter中为HttpSecurity 配置了一些默认的行为，例如CsrfConfigurer，ExpressionUrlAuthorizationConfigurer、FormLoginConfigurer等。到目前为止，从SpringBoot的启动到Security的Filter的创建和注册过程都已完成，接下来的问题是认证和授权又是在哪里进行的呢？ 关于这方面的问题留在后面的章节中来探讨。

再来整体回顾下初始化的过程

Spring Security 4.2.3 Filters 解析

一、 熟悉一个模块的最快方法

1. 配置logback文件，打印相应的debug信息

2. 根据相应的信息，打断点查看执行结果

 

二、spring 使用 DelegatingFilterProxy 管理 filter chain

 allow the IoC container to manage the lifecycle instead of the servlet container

org.springframework.web.filter.DelegatingFilterProxy 是 Spring 中定义的一个 Filter 实现类，其作用是代理真正的 Filter 实现类，

也就是说在调用 DelegatingFilterProxy 的 doFilter() 方法时实际上调用的是其代理 Filter 的 doFilter() 方法。使用 DelegatingFilterProxy

的好处就是Filter 类可以使用 Spring 的依赖注入机制方便自由的使用 ApplicationContext 中的 bean。

 

需要注意的是被代理的 Filter 的初始化方法 init() 和销毁方法 destroy() 默认是不会被执行的。通过设置 DelegatingFilterProxy 的

targetFilterLifecycle 属性为 true，可以使被代理 Filter 与 DelegatingFilterProxy 具有同样的生命周期。

 

三、 FilterChainProxy

DelegatingFilterProxy 代理的就是一个 FilterChainProxy。一个 FilterChainProxy 中可以包含有多个 FilterChain，但是某个请求

只会对应一个 FilterChain，而一个 FilterChain 中又可以包含有多个 Filter。当我们使用 Spring Security 时，系统会自动为我们

注册一个名为 springSecurityFilterChain,  类型为 FilterChainProxy 的 bean（可查看HttpSecurityBeanDefinitionParser）。

Request Firewalling

An HttpFirewall instance is used to validate incoming requests and create a wrapped request which provides consistent path

values for matching against. See DefaultHttpFirewall, for more information on the type of attacks which the default i

mplementation protects against. A custom implementation can be injected to provide stricter control over the request contents

or if an application needs to support certain types of request which are rejected by default.

Note that this means that you must use the Spring Security filters in combination with a FilterChainProxy if you want this

protection. Don\'t define them explicitly in your web.xml file.

FilterChainProxy will use the firewall instance to obtain both request and response objects which will be fed down the filter chain,

so it is also possible to use this functionality to control the functionality of the response. When the request has passed through the

security filter chain, the reset method will be called. With the default implementation this means that the original values of 

servletPath and pathInfowill be returned thereafter,  instead of the modified ones used for security pattern matching.

 

四、 AuthenticationManager 和 AuthenticationProvider

AuthenticationManager 是一个用来处理认证请求的接口。在其中只定义了一个方法 authenticate()，该方法只接收一个代表认证请求的

Authentication对象作为参数，如果认证成功，则会返回一个封装了当前用户权限等信息的 Authentication 对象进行返回。

    public Authentication authenticate(Authentication authentication) throws AuthenticationException {

        Class<? extends Authentication> toTest = authentication.getClass();
        AuthenticationException lastException = null;
        Authentication result = null;
        boolean debug = logger.isDebugEnabled();

　　　　　//使用authenticationProvider列表处理认证请求
        for (AuthenticationProvider provider : getProviders()) {
            if (!provider.supports(toTest)) {
                continue;
            }

            if (debug) {
                logger.debug("Authentication attempt using " + provider.getClass().getName());
            }

            try {
                result = provider.authenticate(authentication);
　　　　　　　　　　//认证成功，跳出循环
                if (result != null) {
                    copyDetails(authentication, result);
                    break;
                }
            }
            catch (AccountStatusException e) {
                prepareException(e, authentication);
                // SEC-546: Avoid polling additional providers if auth failure is due to
                // invalid account status
                throw e;
            }
            catch (InternalAuthenticationServiceException e) {
                prepareException(e, authentication);
                throw e;
            }
            catch (AuthenticationException e) {
                lastException = e;
            }
        }
　　　　　//没有结果，重试认证
        if (result == null && parent != null) {
            // Allow the parent to try.
            try {
                result = parent.authenticate(authentication);
            }
            catch (ProviderNotFoundException e) {
                // ignore as we will throw below if no other exception occurred prior to
                // calling parent and the parent
                // may throw ProviderNotFound even though a provider in the child already
                // handled the request
            }
            catch (AuthenticationException e) {
                lastException = e;
            }
        }
        //认证成功，发布认证结果
        if (result != null) {
            if (eraseCredentialsAfterAuthentication
                    && (result instanceof CredentialsContainer)) {
                // Authentication is complete. Remove credentials and other secret data
                // from authentication
                ((CredentialsContainer) result).eraseCredentials();
            }

            eventPublisher.publishAuthenticationSuccess(result);
            return result;
        }

        // Parent was null, or didn\'t authenticate (or throw an exception).

        if (lastException == null) {
            lastException = new ProviderNotFoundException(messages.getMessage(
                    "ProviderManager.providerNotFound",
                    new Object[] { toTest.getName() },
                    "No AuthenticationProvider found for {0}"));
        }

        prepareException(lastException, authentication);

        throw lastException;
    }

 1.认证过程

在 Spring Security 中，AuthenticationManager 的默认实现是 ProviderManager，而且它不直接自己处理认证请求，而是委托给其所配

置的 AuthenticationProvider 列表，然后会依次使用每一个 AuthenticationProvider 进行认证，如果有一个 AuthenticationProvider 认

证后的结果不为 null，则表示该 AuthenticationProvider 已经认证成功，之后的 AuthenticationProvider 将不再继续认证。然后直接以该

AuthenticationProvider 的认证结果作为 ProviderManager 的认证结果。如果所有的 AuthenticationProvider 的认证结果都为 null，则表

示认证失败，将抛出一个 ProviderNotFoundException。

 

2. 校验认证

校验认证请求最常用的方法是根据请求的用户名加载对应的 UserDetails，然后比对 UserDetails 的密码与认证请求的密码是否一致。

如DaoAuthenticationProvider其内部使用 UserDetailsService 来负责加载 UserDetails。在认证成功以后会使用加载的

UserDetails 来封装要返回的 Authentication 对象，加载的 UserDetails 对象是包含用户权限等信息的。认证成功返回的 Authentication

对象将会保存在当前的 SecurityContext 中。

 

 

4. 在 request 之间共享 SecurityContext

既然 SecurityContext 是存放在 ThreadLocal 中的，而且在每次权限鉴定的时候都是从 ThreadLocal 中获取 SecurityContext 中对应的

Authentication 所拥有的权限，但不同的 request 是不同的线程，为什么每次都可以从 ThreadLocal 中获取到当前用户对应的 SecurityContext 呢？

每次请求开始的时候从 session 中获取 SecurityContext，然后把它设置给 SecurityContextHolder

 

参考：

极客学院：初识Spring Security

 Spring Security 4.2.3 API