Spring Security的认证和授权（1）

1、Spring Security 简介

Java企业级开发生态丰富，无论你想做哪方面的功能，都有众多的框架和工具可供选择, 以至于SUN公司在早些年不得不制定了很多规范，这些规范在今天依然影响着我们的开发，安全领域也是如此，然而，不同于其他领域，在Java企业级开发中，安全管理方面的框架非常少，一般来说，主要有三种方案：

Shiro
Spring Security
Sa-Token
开发者自己实现

Shiro本身是一个老牌的安全管理框架，有着众多的优点，例如轻量、简单、易于集成、可以在JavaSE环境中使用等。不过，在微服务时代，Shiro就显得力不从心了，在微服务面前, 它无法充分展示自己的优势。

Spring Security作为Spring家族的一员，在和Spring家族的其他成员如Spring Boot、Spring Cloud等进行整合时，具有其他框架无可比拟的优势，同时对OAuth2有着良好的支持，再加上 Spring Cloud 对 Spring Security 的不断加持（如推出 Spring Cloud Security）,让 Spring Security 不知不觉中成为微服务项目的首选安全管理方案。

Sa-Token 是一个轻量级 Java 权限认证框架，主要解决：登录认证、权限认证、Session会话、单点登录、OAuth2.0、微服务网关鉴权等一系列权限相关问题。

也有开发者选择自己实现安全管理，这一部分人不在少数，但是一个系统的安全，不仅仅是登录和权限控制这么简单，我们还要考虑各种各样可能存在的网络攻击以及防御策略，从这个角度来说，开发者自己实现安全管理也并非是一件容易的事情，只有大公司才有足够的人力物力去支持这件事情。

2、Spring Security 核心功能

对于一个安全管理框架而言，无论是Shiro还是Spring Security,最核心的功能，无非就是如下两方面：

认证
授权

通俗点说，认证就是身份验证（你是谁？），授权就是访问控制（你可以做什么？）

2.1、认证

Spring Security支持多种不同的认证方式，这些认证方式有的是Spring Security自己提供的认证功能，有的是第三方标准组织制订的。Spring Security集成的主流认证机制主要有如下几种：

表单认证
OAuth2.0 认证
SAML2.0 认证
CAS 认证
RememberMe 自动认证
JAAS 认证
OpenlD 去中心化认证
Pre-Authentication Scenarios 认证口
X509认证
HTTP Basic 认证
HTTP Digest 认证

作为一个开放的平台，Spring Security提供的认证机制不仅仅包括上面这些，我们还可以通过引入第三方依赖来支持更多的认证方式，同时，如果这些认证方式无法满足我们的需求, 我们也可以自定义认证逻辑，特别是当我们和一些“老破旧“的系统进行集成时，自定义认证逻辑就显得非常重要了。

2.2、授权

无论釆用了上面哪种认证方式，都不影响在Spring Security中使用授权功能。Spring Security支持基于URL的请求授权、支持方法访问授权、支持SpEL访问控制、支持域对象安全(ACL)，同时也支持动态权限配置、支持RBAC权限模型等，总之，我们常见的权限管理需求，Spring Security基本上都是支持的。

2.3、其它

在认证和授权这两个核心功能之外,Spring Security还提供了很多安全管理的“周边功能”, 这也是一个非常重要的特色。

大部分Java工程师都不是专业的Web安全工程师，自己开发的安全管理框架可能会存在大大小小的安全漏洞，而Spring Security的强大之处在于，即使你不了解很多网络攻击，只要使用了 Spring Security,它会帮助我们自动防御很多网络攻击，例如CSRF攻击、会话固定攻击等，同时Spring Security还提供了 HTTP防火墙来拦截大量的非法请求。由此可见，研究Spring Securityr也是研究常见的网络攻击以及防御策略。

对于大部分的Java项目而言，无论是从经济性还是安全性来考虑，使用Spring Security 无疑是最佳方案。

3、Spring Security 整体架构

3.1、认证和授权

3.1.1、认证

在 Spring Security 的架构设计中，认证(Authentication)和授权(Authorization)是分开的，无论使用什么样的认证方式，都不会影响授权，这是两个独立的存在，这种独立带来的好处之一，就是Spring Security可以非常方便地整合一些外部的认证方案。

在Spring Security中，用户的认证信息主要由Authentication的实现类来保存， Authentication 接口定义如下：

public interface Authentication extends Principal, Serializable {
	Collection<? extends GrantedAuthority> getAuthorities();
	Object getCredentials();
	Object getDetails();
	Object getPrincipal();
	boolean isAuthenticated();
	void setAuthenticated(boolean isAuthenticated) throws IllegalArgumentException;
}

这里接口中定义的方法如下：

getAuthorities方法：用来获取用户的权限。
getCredentials方法：用来获取用户凭证，一般来说就是密码。
getDetails方法：用来获取用户携带的详细信息，可能是当前请求之类等。
getPrincipal方法：用来获取当前用户，例如是一个用户名或者一个用户对象。
isAuthenticated：当前用户是否认证成功。

用户使用用户名/密码登录或使用Remember-me登录时，都会对应一个不同的 Authentication 实例。Spring Security中的认证工作主要由AuthenticationManager接口来负责，下面来看一下该接口的定义：

public interface AuthenticationManager {
	Authentication authenticate(Authentication authentication) throws AuthenticationException;
}

AuthenticationManager只有一个authenticate方法可以用来做认证，该方法有三个不同的返回值：

返回Authentication, 表示认证成功。
抛出AuthenticationException异常，表示用户输入了无效的凭证。
返回null,表示不能断定。

AuthenticationManager 最主要的实现类是 ProviderManager，ProviderManager 管理了众多的 AuthenticationProvider 实例，AuthenticationProvider 有点类似于 AuthenticationManager, 但是它多了一个supports方法用来判断是否支持给定的Authentication类型。

public interface AuthenticationProvider {
	Authentication authenticate(Authentication authentication) throws AuthenticationException;
	boolean supports(Class<?> authentication);
}

由于Authentication拥有众多不同的实现类，这些不同的实现类又由不同的 AuthenticationProvider 来处理，所以 AuthenticationProvider 会有一个 supports 方法，用来判断当前的 AuthenticationProvider 是否支持对应的 Authentication。

关键点：
在一次完整的认证流程中，可能会同时存在多个AuthenticationProvider (例如，项目同时支持form表单登录和短信验证码登录)，多个AuthenticationProvider统一由ProviderManager 来管理。同时，ProviderManager具有一个可选的parent, 如果所有的AuthenticationProvider 都认证失败，那么就会调用parent进行认证。parent相当于一个备用认证方式，即各个 AuthenticationProvider都无法处理认证问题的时候，就由parent出场收拾残局。

3.1.2、授权

当完成认证后，接下来就是授权了。在Spring Security的授权体系中，有两个关键接口：

AccessDecisionManager
AccessDecisionVoter

AccessDecisionManager则是一个决策器，来决定此次访问是否被允许。
AccessDecisionVoter是一个投票器，投票器会检查用户是否具备应有的角色，进而投出赞成、反对或者弃权票。

AccessDecisionVoter 和 AccessDecisionManager 都有众多的实现类，在 AccessDecisionManager 中会挨个遍历AccessDecisionVoter，进而决定是否允许用户访问，因而AccessDecisionVoter 和 AccessDecisionManager 两者的关系类似于 AuthenticationProvider 和 ProviderManager 的关系。

注意：
在Spring Security中，用户请求一个资源（通常是一个网络接口或者一个Java方法）所需要的角色会被封装成一个ConfigAttribute对象，在ConfigAttribute中只有一个getAttribute 方法，该方法返回一个String字符串，就是角色的名称。一般来说，角色名称都带有一个ROLE_ 前缀，投票器AccessDecisionVoter所做的事情，其实就是比较用户所具备的角色和请求某个资源所需的ConfigAttribute之间的关系。

3.2、Web安全

在Spring Security中，认证、授权等功能都是基于过滤器来完成的。下表列出了 Spring Security中常见的过滤器，注意这里说的是否默认加载是指引入Spring Security依赖之后，开发者不做任何配置时，会自动加载的过滤器。
在这里插入图片描述

开发者所见到的Spring Security提供的功能，都是通过这些过滤器来实现的，这些过滤器按照既定的优先级排列，最终形成一个过滤器链，开发者也可以自定义过滤器，并通过@Order 注解去调整自定义过滤器在过滤器链中的位置。

需要注意的是，默认过滤器并不是直接放在Web项目的原生过滤器链中，而是通过一个FilterChainProxy 来统一管理。Spring Security 中的过滤器链通过 FilterChainProxy 嵌入到 Web 项目的原生过滤器链中，如下图所示。

在这里插入图片描述
在Spring Security中，这样的过滤器链不仅仅只有一个，可能会有多个，如下图所示。当存在多个过滤器链时，多个过滤器链之间要指定优先级，当请求到达后，会从 FilterChainProxy进行分发，先和哪个过滤器链匹配上，就用哪个过滤器链进行处理。当系统中存在多个不同的认证体系时，那么使用多个过滤器链就非常有效。

在这里插入图片描述
FilterChainProxy 作为一个顶层管理者，将统一管理 Security Fliter。 FilterChainProxy 本身将通过Spring框架提供的DelegatingFilterProxy整合到原生过滤器链中，所以还可以做进一步的优化，如下图所示。

3.3、登录数据保存

如果不使用Spring Security这一类的安全管理框架，大部分的开发者可能会将登录用户数据保存在Session中，事实上,Spring Security也是这么做的。但是，为了使用方便,Spring Security 在此基础上还做了一些改进，其中最主要的一个变化就是线程绑定。

当用户登录成功后，Spring Security会将登录成功的用户信息保存到SecurityContextHolder 中。SecurityContextHolder 中的数据保存默认是通过ThreadLocal来实现的，使用ThreadLocal 创建的变量只能被当前线程访问，不能被其他线程访问和修改，也就是用户数据和请求线程绑定在一起。当登录请求处理完毕后，Spring Security会将SecurityContextHolder中的数据拿出来保存到Session中，同时将SecurityContextHolder中的数据清空。以后每当有请求到来时， Spring Security就会先从Session中取出用户登录数据，保存到SecurityContextHolder 中，方便在该请求的后续处理过程中使用，同时在请求结束时将SecurityContextHolder中的数据拿岀来保存到Session中，然后将SecurityContextHolder 中的数据清空。

这一策略非常方便用户在Controller或者Service层获取当前登录用户数据，但是带来的另外一个问题就是，在子线程中想要获取用户登录数据就比较麻烦。Spring Security对此也提供了相应的解决方案，如果开发者使用@Async注解来开启异步任务的话，那么只需要添加如下配置，使用Spring Security提供的异步任务代理，就可以在异步任务中从SecurityContextHolder里边获取当前登录用户的信息：

@Configuration
public class ApplicationConfiguration extends AsyncConfigurerSupport {
    @Override
    public Executor getAsyncExecutor() {
        return new DelegatingSecurityContextExecutorService(Executors.newFixedThreadPool(5));
    }
}