1.Spring Security 简介

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

Shiro
Spring Security
开发者自己实现

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

也有开发者选择自己实现安全管理，这一部分人不在少数，但是一个系统的安全，不仅仅是登录和权限控制这么简单，我们还要考虑各种各样可能存在的网络攻击以及防御策略，从这个角度来说，开发者自己实现安全管理也并非是一件容易的事情，只有大公司才有足够的人力物力去支持这件事情。Spring Security作为Spring家族的一员，在和Spring家族的其他成员如Spring Boot、Spring Cloud等进行整合时，具有其他框架无可比拟的优势，同时对OAuth2有着良好的支持，再加上 Spring Cloud 对 Spring Security 的不断加持（如推出 Spring Cloud Security）,让 Spring Security 不知不觉中成为微服务项目的首选安全管理方案。

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认证
https Basic 认证
https 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还提供了 https防火墙来拦截大量的非法请求。由此可见，研究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，PioviderManager 管理了众多的 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

AccessDecisionVoter是一个投票器，投票器会检查用户是否具备应有的角色，进而投出赞成、反对或者弃权票；AccessDecisionManager则是一个决策器，来决定此次访问是否被允许。 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));
    }
}