spring security（一）：默认的配置都干了什么

梦里梦外; 2022-12-27 08:19 171阅读 0赞

先啰嗦一些理论。客户端请求发送到 web 服务之前，以及 web 服务的响应返回到客户端之前，需要经过一系列的过滤器（这些过滤器组成了一个过滤器链）。过滤器有两个作用：（1）阻止请求发送到后面的过滤器或者 web 服务；（2）修改请求或者响应的内容再送到后面去。

![image-20201208173523348][]

图中的 Servlet 就是程序员开发的 web 应用。如果这块不太清楚，建议刷一下《Hand First Servlet & Jsp》。

# 1、过滤器和负责安全校验的过滤器。 #

[关于过滤器的创建、配置、使用可以看下这里。][Link 1]  
根据 filter 功能的不一样，比如：魔改请求与响应、校验用户信息、或者校验别的XXX，所以 FilterChain 中的 filters 又可以做一些划分。

![image-20201208174521463][]

负责校验用户身份信息的 filters 都放在了 SecurityFilterChain 中。这里先不要管 DelegatingFilterProxy 是什么东西，具体做了哪些事情，只需要知道 校验用户身份的 filters 都在它里面就可以了。

当在 Spring Boot 应用中加入 Security 依赖后，这个依赖会自动地给项目添加一些 filters，做一些配置，并且启动安全保护。这些 filters 也都属于 SecurityFilterChain 的范畴。

dependencies { 
        testImplementation 'org.springframework.boot:spring-boot-starter-test'
        testImplementation 'org.springframework.security:spring-security-test'
    }

# 2、认证是到底是干了什么事情？ #

web 应用为了防止别有用心的用户假冒真用户去访问服务，所以对访问用户进行身份认证（验一验用户名、密码）。security 自动开启安全保护默认所有的 api 在访问时先验证访问者的身份。上面提到 security 会自动添加一些 filters ，这些 filters 就是执行具体的认证流程。

那 security filter 到底是怎么认证的呢？

先看下 spring security 的认证模型是怎么设计的，如下图所示。`SecurityContextHolder` 相当于一个“仓库” 或者 “平台”，已经通过认证的用户信息都存放在这里。`SecurityContext` 像一个“竹筐”，里面放着真正的已被认证的用户信息：`Authentication`。信息由三部分构成：`Principal` 里面存放一部分（可以对外展示的）信息，比如：用户名、年龄等，`Credentials` 里面存放一部分（安全敏感的）信息，比如：密码。`Authorities` 里面存放用户的权限，一般都是角色信息：如：`ADMIN`。

![image-20201208181207984][]

Security filter 具体干的事情就是：校验完用户名、密码以后，将用户信息构建成一个 `Authorication`，并存放到 `SecurityContext` 中，最后将 `SecurityContext` “塞到” `SecurityContextHolder` 里面。

无论是基于内存的用户认证、基于 JDBC 的用户认证、还是 UserDetailsService 的方式，它们只是校验用户名、密码这个环节上有所区别（这块内容后面再写博客介绍），校验完了都得构建 Authorization 并塞到 SecurityContextHolder 里面。

**官方文档有这么句话和一小段代码：**

![image-20201208191308770][]

所以还有除了上述三种认证方式以外，还可以手动“塞”里面去。（这个也后面再写）

# 3、默认的安全配置都做了什么事情？ #

这里介绍下当添加了 Spring Security 依赖都`自动地`干了什么事情。（下面的代码都是 `org.springframework.security` 包里面的）

// 
    public abstract class WebSecurityConfigurerAdapter implements WebSecurityConfigurer<WebSecurity> { 
        
        protected void configure(HttpSecurity http) throws Exception { 
        this.logger.debug("Using default configure(HttpSecurity). "
                          + "If subclassed this will potentially override subclass configure(HttpSecurity).");
        http.authorizeRequests((requests) -> requests.anyRequest().authenticated());
        http.formLogin();
        http.httpBasic();
    	}
    }

这个方法里规定；所有的 api 在被方式时都要认证问者的身份，认证的方式有两种：`formLogin` 或 `httpBasic`。

所以随便写一个 api，没加 security 依赖前可以直接访问，加了依赖再访问，立马 return 401。要访问也可以，输入用户名和密码，否则免谈。

那用户名、密码是什么？

public class UserDetailsServiceAutoConfiguration { 
        public InMemoryUserDetailsManager inMemoryUserDetailsManager(SecurityProperties properties,
    			ObjectProvider<PasswordEncoder> passwordEncoder) { 
    		SecurityProperties.User user = properties.getUser();
    		List<String> roles = user.getRoles();
    		return new InMemoryUserDetailsManager(
    				User.withUsername(user.getName()).password(getOrDeducePassword(user, passwordEncoder.getIfAvailable()))
    						.roles(StringUtils.toStringArray(roles)).build());
    	}
    
    	private String getOrDeducePassword(SecurityProperties.User user, PasswordEncoder encoder) { 
    		String password = user.getPassword();
    		if (user.isPasswordGenerated()) { 
    			logger.info(String.format("%n%nUsing generated security password: %s%n", user.getPassword()));
    		}
    		if (encoder != null || PASSWORD_ALGORITHM_PATTERN.matcher(password).matches()) { 
    			return password;
    		}
    		return NOOP_PASSWORD_PREFIX + password;
    	}
    }

`UserDetailsServiceAutoConfiguration` 这个类只有上面两个方法（这个类好多人见了上百遍但都没留意过），目的也很简单。在 web 应用启动时，生成一个用户，并保存在内存中（其实是保存在 `InMemoryUserDetailsManager` 的对象中）。，用户名：`user` ，密码：`一个很长的字符串，并在终端日志中打印出来`。

看看终端日志喽：  
![在这里插入图片描述][a83fee5cd9dcfd20c4a431ebfb9b8f99.png_pic_center]

蓝色箭头就是上面提到的那个类。红色箭头是产生的密码。黑色箭头是 spring security 默认的负责认证访问者身份的过滤器链，后面的英语意思是："\[" 这里面的 filters"\]" 将保护所有请求。可以看看这些 filters 的名字，有些 filters 将执行具体的认证过程。

所以，默认的安全配置做了这么几件事情：

1.  规定所有的 api 在被访问前必须认证访问者的身份。
2.  自动生成一个用户存在内存里，开发者以此用户身份访问 api。
3.  自动给 web 应用添加了一系列 filters 并存放在 `DefaultSecurityFiltersChain` 中，用于执行认证的具体细节。

# 4、默认的认证流程是怎么执行的？ #

认证有两种方式：

*  基于 form 的，这种会有个专门的前端页面，填写用户名、密码。整个流程大概是，浏览器先请求 api ，security filters 发现 request 中没有用户名和密码，过滤器（过滤器链中的某个）重定向 url（这个 url 就是填用户名、密码的界面） 并返回 response。在页面上填写 用户名、密码后再向 api 发请求，这次就可以执行认证的整个过程了。
 *  基于 httpBasic 的，这种方式将用户名和密码直接放在了请求里面，所以不会有 form 方式的重定向过程，可以直接开始认证。

这里解释 httpBasic 放是的请求执行过程。

请求命令：`curl http://localhost:8080/user -u user:f27f769d-a5ff-4e69-a728-0cf23bdd2d10`

客户端的发送的请求在到达 servlet 之前会先穿过一系列 filters，肯定是其中的某个 filter 执行的认证并将通过认证的用户信息写到了 `SecurityContextHolder` 中。

那这个过滤器是谁呢？

在默认设置中，`DefaultSecurityFilterchain` 中的 `BasicAuthenticationFilter` 执行了具体的认证过程。

至于为什么是在 `doFilterInternal()` 方法中执行的认证，[可以看下这里][Link 2]。

@Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
        throws IOException, ServletException { 
        try { 
            UsernamePasswordAuthenticationToken authRequest = this.authenticationConverter.convert(request);
            if (authRequest == null) { 
                this.logger.trace("Did not process authentication request since failed to find "
                                  + "username and password in Basic Authorization header");
                chain.doFilter(request, response);
                return;
            }
            String username = authRequest.getName();
            this.logger.trace(LogMessage.format("Found username '%s' in Basic Authorization header", username));
            if (authenticationIsRequired(username)) { 
                Authentication authResult = this.authenticationManager.authenticate(authRequest);
                SecurityContextHolder.getContext().setAuthentication(authResult);
                if (this.logger.isDebugEnabled()) { 
                    this.logger.debug(LogMessage.format("Set SecurityContextHolder to %s", authResult));
                }
                this.rememberMeServices.loginSuccess(request, response, authResult);
                onSuccessfulAuthentication(request, response, authResult);
            }
        }
        catch (AuthenticationException ex) { 
            SecurityContextHolder.clearContext();
            this.logger.debug("Failed to process authentication request", ex);
            this.rememberMeServices.loginFail(request, response);
            onUnsuccessfulAuthentication(request, response, ex);
            if (this.ignoreFailure) { 
                chain.doFilter(request, response);
            }
            else { 
                this.authenticationEntryPoint.commence(request, response, ex);
            }
            return;
        }
    
        chain.doFilter(request, response);
    }
    
    private boolean authenticationIsRequired(String username) { 
        Authentication existingAuth = SecurityContextHolder.getContext().getAuthentication();
        if (existingAuth == null || !existingAuth.isAuthenticated()) { 
            return true;
        }
        if (existingAuth instanceof UsernamePasswordAuthenticationToken && !existingAuth.getName().equals(username)) { 
            return true;
        }
        return (existingAuth instanceof AnonymousAuthenticationToken);
    }

解释下上面的代码。

*  第 5 行：客户端的 request 中有用户名和密码。`authenticationConverter.convert(request)` 把用户上传 的 username 和 password 拿出来，构建了一个 `UsernamePasswordAuthenticationToken` ，它可是 `Authentication` 的子类。说白了这里就是给 request 里面的用户构造一个 authentication，后面的逻辑大概就能想到了，web 程序启动时可是自动生成了一个 username 和 password，这也能构造出一个 authentication。里外两个 authentication 进行对比，相同则认证通过，否则认证失败。
 *  第 12 行：从外面的 authentication 中拿出 username，其实就是用户上传的 username。
 *  第 14 行：判断这个 username 需不需要执行认证。那判断的依据是什么呢？前面提到的，但凡已经通过认证的用户信息会以 Authorization 对象的形式存储在 SecurityContextHolder 的 SecurityContext中。如果SecurityContext 里面是空的，那当前的 username 肯定是还没有被认证的。如果不是空的，那就再对比，`authorization.getName().equals(username)` 是否成立，如果不成立，那当前 username 也是还没被认证的。第 41 行的方法的逻辑就很清楚了，结果当然是需要认证，因为当前的 SecurityContext 里面是空的。
 *  第 15 行：这行代码执行了真正的认证，即从内存中拿出 authorization，与外部的进行对比。那到底是怎么拿的？谁拿的？具体的代码在哪里？这块的函数调用比较复杂，这里写一个顺序，有兴趣的可以追着看下。
    
        // --> 从 -->
        // BasicAuthenticationFilter.java 的 115 行 
        Authentication authResult = this.authenticationManager.authenticate(authRequest); 
        // --> 进入 -->
        // PrividerManager.java 的 165 行 的方法里面
        public Authentication authenticate(Authentication authentication) throws AuthenticationException { 
            // 在 182 行 有个方法，在这里跳了。
            result = provider.authenticate(authentication);
        }
        // --> 进入 -->
        // DaoAuthenticationProvider.java
        // 这里得解释下，的确是进到这个类里了。但 DaoAuthenticationProvider 继承了抽象类AbstractUserDetailsAuthenticationProvider， 
        // 所以 AbstractUserDetailsAuthenticationProvider 里面的 authenticate(Authentication authentication) 方法，肯定也在 DaoAuthenticationProvider 中。
        // 所以 这里得先到 AbstractUserDetailsAuthenticationProvider 中 看下 authenticate(Authentication authentication) 方法。
        
        // --> 进入 -->
        // AbstractUserDetailsAuthenticationProvider.java 但要记住，实际上是在 DaoAuthenticationProvider 中看 authenticate(Authentication authentication) 方法。
        public Authentication authenticate(Authentication authentication) throws AuthenticationException { 
            // 在 133 行，这里又跳了。retrieveUser() 是抽象方法，DaoAuthenticationProvider 重写了这个方法。
            user = retrieveUser(username, (UsernamePasswordAuthenticationToken) authentication);
        } 
        
        // --> 这次真的进入 -->
        // DaoAuthenticationProvider.java
        protected final UserDetails retrieveUser(String username, UsernamePasswordAuthenticationToken authentication)
        			throws AuthenticationException { 
            // 在 93 行，真正的认证在这里，根据用户上传的 username，去查“通过认证”的用户里有没有这个人。
            // 不过又跳了.......
            UserDetails loadedUser = this.getUserDetailsService().loadUserByUsername(username);
        }
        
        protected UserDetailsService getUserDetailsService() { 
            return this.userDetailsService;
        }
        
        // --> 进入 -->
        // InMemoryUserDetailsManager.java, 它是 UserDetailsService 的一个子类。
        // 还记得上面么，web 应用自动创建的 user 就在它里面存着呢？ 
        // 如果不记得了，翻上去看下 UserDetailsServiceAutoConfiguration 里面干了啥，就两个方法。
        
        public class InMemoryUserDetailsManager implements UserDetailsManager, UserDetailsPasswordService { 
            // web 启动时创建的“已经通过认证”的 user 就在 users 中存放着，key 是 username。 
            // MutableUserDetails 是 UserDetails 的子类。
            private final Map<String, MutableUserDetails> users = new HashMap<>();
            
            @Override
        	public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException { 
                // 根据 request 中携带的 username 去查 username 相同的 User。
                // 再重复一遍，web 中保存的 User 都是已经通过认证的。别糊涂了。
        		UserDetails user = this.users.get(username.toLowerCase());
                // 匹配不到，报异常。
        		if (user == null) { 
        			throw new UsernameNotFoundException(username);
        		}
                // 匹配成功，构造成 UserDetails 返回。User 是 UserDetails 的子类。
        		return new User(user.getUsername(), user.getPassword(), user.isEnabled(), user.isAccountNonExpired(),
        				user.isCredentialsNonExpired(), user.isAccountNonLocked(), user.getAuthorities());
        	}
        }
        
        // 到这里，相同 username 的 User 已经找到了。接下来还得对比下密码是不是一样。
        // 只有 用户名相同，密码相同，才能通过认证。
        // 又得跳啊，不过这次是往回跳。
        // 来，继续啊！！！
        
        // --> 进入 --> 
        // AbstractUserDetailsAuthenticationProvider.java 的 authenticate(Authentication authentication) 别昏头啊，实际上是在 DaoAuthenticationProvider.java 里面。
        
        public Authentication authenticate(Authentication authentication) throws AuthenticationException { 
            // 在 158 行，这里校验了密码。如果密码不匹配会报异常。
            // additionalAuthenticationChecks() 也是个抽象方法，DaoAuthenticationProvider 重写了。
            // 自己 跳过去看吧，这里不再写了。
            additionalAuthenticationChecks(user, (UsernamePasswordAuthenticationToken) authentication);
            
            // 在 168 行，创建了一个 UsernamePasswordAuthenticationToken 对象就返回了。
            // UsernamePasswordAuthenticationToken 是 Authorization 的子类。
            return createSuccessAuthentication(principalToReturn, authentication, user)
        }
        
        // 继续往回跳
        // --> 进入 --> 
        // ProviderManager.java 
        public Authentication authenticate(Authentication authentication) throws AuthenticationException { 
            // 182 行的 result 中存放的就是返回的 UsernamePasswordAuthenticationToken。
            Authentication result = provider.authenticate(authentication)
            // 在 215 行 做一些判断后就将 result 给返回了。
        }
        
        // 继续往回跳
        // --> 进入 --> 
        // BasicAuthenticationFilter.java
        protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
        			throws IOException, ServletException { 
            // 在 155 行，认证过程到此就执行完了。
            Authentication authResult = this.authenticationManager.authenticate(authRequest);
        }
 *  第 16 行： 将认证后的 Authorization 放到 SecurityContextHolder 的 Context 里面。

到这里，认证流程就算是走完了。

[image-20201208173523348]: https://raw.githubusercontent.com/diego1109/pictures/main/20201208173523.png
[Link 1]: https://blog.csdn.net/yy_diego/article/details/110447507
[image-20201208174521463]: https://raw.githubusercontent.com/diego1109/pictures/main/20201208174521.png
[image-20201208181207984]: https://raw.githubusercontent.com/diego1109/pictures/main/20201208181208.png
[image-20201208191308770]: https://raw.githubusercontent.com/diego1109/pictures/main/20201208191308.png
[a83fee5cd9dcfd20c4a431ebfb9b8f99.png_pic_center]: /images/20221120/97f050a0ec624edfb6dcbca572f8d105.png
[Link 2]: https://blog.csdn.net/yy_diego/article/details/110482447