【Spring Boot】Spring 的安全框架：Spring Security

1.Spring Security 初识

Spring Security 提供了声明式的安全访问控制解决方案（仅支持基于 Spring 的应用程序），对访问权限进行认证和授权，它基于 Spring AOP 和 Servlet 过滤器，提供了安全性方面的全面解决方案。

除常规的认证和授权外，它还提供了 ACLs、LDAP、JAAS、CAS 等高级特性以满足复杂环境下的安全需求。

1.1 核心概念

Spring Security 的 3 个核心概念。

• Principle：代表用户的对象 Principle（User），不仅指人类，还包括一切可以用于验证的设备。
• Authority：代表用户的角色 Authority（Role），每个用户都应该有一种角色，如管理员或是会员。
• Permission：代表授权，复杂的应用环境需要对角色的权限进行表述。

在 Spring Security 中，Authority 和 Permission 是两个完全独立的概念，两者并没有必然的联系。它们之间需要通过配置进行关联，可以是自己定义的各种关系。

1.2 认证和授权

安全主要分为 验证（authentication）和 授权（authorization）两个部分。

1.2.1 验证（authentication）

验证 指的是，建立系统使用者信息（Principal）的过程。使用者可以是一个用户、设备，和可以在应用程序中执行某种操作的其他系统。

用户认证一般要求用户提供用户名和密码，系统通过校验用户名和密码的正确性来完成认证的通过或拒绝过程。

Spring Security 支持主流的认证方式，包括 HTTP 基本认证、 HTTP 表单验证、HTTP 摘要认证、Open ID 和 LDAP 等。

Spring Security 进行验证的步骤如下。

• 1️⃣ 用户使用用户名和密码登录。
• 2️⃣ 过滤器（UsemamePasswordAuthenticationFilter）获取到用户名、密码，然后封装成 Authentication。
• 3️⃣ AuthenticationManager 认证 token (Authentication 的实现类传递）。
• 4️⃣ AuthenticationManager 认证成功，返回一个封装了用户权限信息的 Authentication 对象， 用户的上下文信息（角色列表等）。
• 5️⃣ Authentication 对象赋值给当前的 SecurityContext，建立这个用户的安全上下文（通过调用 SecurityContextHolder.getContext().setAuthentication()）。
• 6️⃣ 用户进行一些受到访问控制机制保护的操作，访问控制机制会依据当前安全上下文信息检查这个操作所需的权限。

除利用提供的认证外，还可以编写自己的 Filter（过滤器），提供与那些不是基于 Spring Security 的验证系统的操作。

1.2.2 授权（authorization）

在一个系统中，不同用户具有的权限是不同的。一般来说，系统会为不同的用户分配不同的角色，而每个角色则对应一系列的权限。

它判断某个 Principal 在应用程序中是否允许执行某个操作。在进行授权判断之前，要求其所要使用到的规则必须在验证过程中已经建立好了。

对 Web 资源的保护，最好的办法是使用过滤器。对方法调用的保护，最好的办法是使用 AOP。

Spring Security 在进行用户认证及授予权限时，也是通过各种拦截器和 AOP 来控制权限访问的，从而实现安全。

1.3 模块

名称	模块	解释
核心模块	spring-security-core.jar	包含核心验证和访问控制类和接口，以及支持远程配置的基本 API。
远程调用	spring-security-remoting.jar	提供与 Spring Remoting 集成。
网页	spring-security-web.jar	包括网站安全的模块，提供网站认证服务和基于 URL 访问控制。
配置	spring-security-config.jar	包含安全命令空间解析代码。
LDAP	spring-security-ldap.jar	LDAP 验证和配置。
ACL	spring-security-acl.jar	对 ACL 访问控制表的实现。
CAS	spring-security-cas.jar	对 CAS 客户端的安全实现。
OpenlD	spring-security-openid.jar	对 OpenID 网页验证的支持。
Test	spring-security-test.jar	对 Spring Security 的测试的支持。

2.核心类

2.1 Securitycontext

SecurityContext 中包含 当前正在访问系统的用户的详细信息，它只有以下两种方法。

• getAuthentication()：获取当前经过身份验证的主体或身份验证的请求令牌。
• setAuthentication()：更改或删除当前已验证的主体身份验证信息。

SecurityContext 的信息是由 SecurityContextHolder 来处理的。

2.2 SecurityContextHolder

SecurityContextHolder 用来保存 SecurityContext。最常用的是 getContext() 方法，用来获得当前 SecurityContext。

SecurityContextHolder 中定义了一系列的静态方法，而这些静态方法的内部逻辑是通过 SecurityContextHolder 持有的 SecurityContextHolderStrategy 实现的，如 clearContext()、getContext()、setContext()、createEmptyContext()。

SecurityContextHolderStrategy 的关键代码如下：

public interface SecurityContextHolderStrategy {
　　void clearContext();
　　Securitycontext getContext();
　　void setContext(SecurityContext context);
　　Securitycontext createEmptyContext();
}

2.2.1 strategy 实现

默认使用的 strategy 就是基于ThreadLocal 的 ThreadLocalSecurityContextHolderStrategy 来实现的。

除了上述提到的，Spring Security 还提供了 3 种类型的 strategy 来实现。

• GlobalSecurityContextHolderStrategy：表示全局使用同一个 SecurityContext，如 C/S 结构的客户端。
• InheritableThreadLocalSecurityContextHolderStrategy：使用 InheritableThreadLocal 来存放 Securitycontext，即子线程可以使用父线程中存放的变量。
• ThreadLocalSecurityContextHolderStrategy: 使用 ThreadLocal 来存放 SecurityContext。

—般情况下，使用默认的 strategy 即可。但是，如果要改变默认的 strategy，Spring Security 提供了两种方法来改变 strategyName。

SecurityContextHolder 类中有 3 种不同类型的 strategy, 分别为 MODE_THREADLOCAL、MODE_INHERITABLETHREADLOCAL 和 MODE_GLOBAL，关键代码如下：

public static final String MODE_THREADLOCAL = "MODE_THREADLOCAL"； 
public static final String MODEJNHERITABLETHREADLOCAL = "MODE_INHERITABLETHREADLOCAL";
public static final String MODE_GLOBAL = "MODE_GLOBAL";
public static final String SYSTEM_PROPERTY = "spring.security.strategy";
private static String strategyName = System.getProperty(SYSTEM_PROPERTY);
private static SecurityContextHolderStrategy strategy;

MODE_THREADLOCAL 是默认的方法。

如果要改变 strategy，则有下面两种方法：

• 通过 SecurityContextHolder 的静态方法 setStrategyName(java.lang.String strategyName) 来改变需要使用的 strategy。
• 通过系统属性（SYSTEM_PROPERTY）行指定，其中属性名默认为 spring.security. strategy，属性值为对应 strategy 的名称。

2.2.2 获取当前用户的 SecurityContext

Spring Security 使用一个 Authentication 对象来描述当前用户的相关信息。SecurityContextHolder 中持有的是当前用户的Securitycontext，而 SecurityContext 持有的是代表当前用户相关信息的 Authentication 的引用。

这个 Authentication 对象不需要自己创建，Spring Security 会自动创建相应的 Authentication 对象，然后赋值给当前的 SecurityContext。但是，往往需要在程序中获取当前用户的相关信息，比如最常见的是获取当前登录用户的用户名。在程序的任何地方，可以通过如下方式获取到当前用 户的用户名。

public String getCurrentUsername() {
　　Object principal = SecurityContextHolder.getContext().getAuthentication().getPrincipal();
　　if (principal instanceof UserDetails){
　　　　return ((UserDetails) principal).getUsermame();
　　} 
　　if (principal instanceof Principal) {
　　　　return ((Principal) principal).getName()；
　　}
　　return String.valueOf(principal);
}

• getAuthentication() 方法会返回认证信息。
• getPrincipal() 方法返回身份信息，它是 UserDetails 对身份信息的封装。

获取当前用户的用户名，最简单的方式如下：

public String getCurrentUsername() (
　　return SecurityContextHolder.getContext().getAuthentication().getName();
)

在调用 SecurityContextHolder.getContext() 获取 Securitycontext 时，如果对应的 Securitycontext 不存在，则返回空的 SecurityContext。

2.3 ProviderManager

ProviderManager 会维护 一个认证的列表，以便处理不同认证方式的认证，因为系统可能会存在多种认证方式，比如手机号、用户名密码、邮箱方式。

在认证时，如果 ProviderManager 的认证结果不是 null，则说明认证成功，不再进行其他方式的认证，并且作为认证的结果保存在 SecurityContext 中。如果不成功，则抛出错误信息 ProviderNotFoundException。

2.4 DaoAuthenticationProvider

它是 AuthenticationProvider 最常用的实现，用来获取用户提交的用户名和密码，并进行正确性比对。如果正确，则返回一个数据库中的用户信息。

当用户在前台提交了用户名和密码后，就会被封装成 UsemamePasswordAuthenticationToken。

然后，DaoAuthenticationProvider 根据 retrieveUser 方法，交给 additionalAuthenticationChecks 方法完成 UsemamePasswordAuthenticationToken 和 UserDetails 密码的比对。如果这个方法没有抛出异常，则认为比对成功。

比对密码需要用到 PasswordEncoder 和 SaltSource。

2.5 UserDetails

UserDetails 是 Spring Security 的 用户实体类，包含用户名、密码、权限等信息。Spring Security 默认实现了内置的 User 类，供 Spring Security 安全认证使用。当然，也可以自己实现。

UserDetails 接口和 Authentication 接口很类似，都拥有 username 和 authorities。一定要区分清楚 Authentication 的 getCredentials() 与 UserDetails 中的 getPassword()。前者 是 用户提交的密码凭证，不一定是正确的，或数据库不一定存在；后者 是 用户正确的密码，认证器要进行比对的就是两者是否相同。

Authentication 中的 getAuthorities() 方法是由 UserDetails 的 getAuthorities() 传递而形成的。UserDetails 的用户信息是经过 AuthenticationProvider 认证之后被填充的。

UserDetails 中提供了以下几种方法。

• String getPassword()：返回验证用户密码，无法返回则显示为 null。
• String getUsername()：返回验证用户名，无法返回则显示为 null。
• boolean isAccountNonExpired()：账户是否过期，过期无法验证。
• boolean isAccountNonLocked()：指定用户是否被锁定或解锁，锁定的用户无法逬行身份验证。
• boolean isCredentialsNonExpired()：指定是否已过期的用户的凭据（密码），过期的凭据无法认证。
• boolean isEnabled()：是否被禁用。禁用的用户不能进行身份验证。

2.6 UserDetailsService

用户相关的信息是通过 UserDetailsService 接口来加载的。该接口的唯一方法是 loadUserByUsername(String username)，用来 根据用户名加载相关信息。

这个方法的返回值是 UserDetails 接口，其中包含了用户的信息，包括用户名、密码、权限、是否启用、是否被锁定、是否过期等。

2.7 GrantedAuthority

GrantedAuthority 中只定义了一个 getAuthority() 方法。该方法返回一个字符串，表示对应权限的字符串。如果对应权限不能用字符串表示，则返回 null。

GrantedAuthority 接口通过 UserDetailsService 进行加载，然后赋予 UserDetails。

Authentication 的 getAuthorities() 方法可以返回当前 Authentication 对象拥有的权限，其返回值是一个 GrantedAuthority 类型的数组。每一个 GrantedAuthority 对象代表赋予当前用户的一种权限。

2.8 Filter

Filter 类型	说明
SecurityContextPersistenceFilter	它从 SecurityContextRepository 中取出用户认证信息。为了提高效率，避免每次请求都要查询认证信息，它会从 Session 中取出已认证的用户信息，然后将其放入 SecurityContextHolder 中，以便其他 Filter 使用。
WebAsyncManagerlntegrationFilter	集成了 SecurityContext 和 WebAsyncManager，把 SecurityContext 设置到异步线程，使其也能获取到用户上下文认证信息。
HeaderWriterFilter	它对请求的 Header 添加相应的信息。
CsrfFilter	跨域请求伪造过滤器。通过客户端传过来的 token 与服务器端存储的 token 进行对比，来判断请求的合法性。
LogoutFilter	匹配登出 URL。匹配成功后，退出用户，并清除认证信息。
UsernamePasswordAuthenticationFilter	登录认证过滤器，默认是对 /login 的 POST 请求进行认证。该方法会调用 attemptAuthentication，尝试获取一个 Authentication 认证对象，以保存认证信息，然后转向下一个 Filter，最后调用 successfulAuthentication 执行认证后的事件。
AnonymousAuthenticationFilter	如果 SecurityContextHolder 中的认证信息为空，则会创建一个匿名用户到 SecurityContextHolder 中。
SessionManagementFilter	持久化登录的用户信息。用户信息会被保存到 Session、Cookie 或 Redis 中。