Servlet 身份验证体系结构

SecurityContextHolder

在Spring Security的身份验证模型的核心是SecurityContextHolder。它包含SecurityContext。

SecurityContextHolder 是 Spring Security 存储被验证者的详细信息的地方。Spring Security 不关心 SecurityContextHolder 是如何填充的。如果它包含一个值，则将其用作当前经过身份验证的用户。
表明用户已通过身份验证的最简单方法是直接设置 SecurityContextHolder。如下代码：

// 我们首先创建一个空的SecurityContext。
// 创建新的SecurityContext实例，而不是使用SecurityContextHolder.getContext().setAuthentication(authentication)来避免多个线程之间的争用情况非常重要。
SecurityContext context = SecurityContextHolder.createEmptyContext();
// 接下来我们创建一个新的 Authentication 对象。
// Spring Security 不关心 SecurityContext 上设置了什么类型的身份验证实现。
// 这里我们使用 TestingAuthenticationToken，因为它非常简单。一个更常见的生产场景是 UsernamePasswordAuthenticationToken (userDetails、 password、 authorities)。
Authentication authentication = new TestingAuthenticationToken("username", "password", "ROLE_USER");
context.setAuthentication(authentication);
// 最后，我们在SecurityContextHolder上设置SecurityContext。Spring Security将使用此信息进行授权。
SecurityContextHolder.setContext(context);

如果希望获得有关经过身份验证的主体的信息，可以通过访问 SecurityContextHolder 来实现。

SecurityContext context = SecurityContextHolder.getContext();
Authentication authentication = context.getAuthentication();
String username = authentication.getName();
Object principal = authentication.getPrincipal();
Collection<? extends GrantedAuthority> authorities = authentication.getAuthorities();

默认情况下 SecurityContextHolder 使用 ThreadLocal 来存储这些细节，这意味着 SecurityContext 总是可用于同一线程中的方法，即使 SecurityContext 没有作为参数显式地传递给这些方法。如果在处理当前主体的请求之后注意清除线程，那么以这种方式使用 ThreadLocal 是非常安全的。Spring Security 的 FilterChainProxy 确保 SecurityContext 总是被清除。

有些应用程序并不完全适合使用ThreadLocal，因为它们使用线程的特定方式。例如，Swing客户端可能希望Java虚拟机中的所有线程使用相同的安全上下文。SecurityConextHolder可以在启动时配置策略，以指定您希望如何存储上下文。对于独立的应用程序，您将使用SecurityConextHolder.MODE_GLOBAL策略。其他应用程序可能希望由安全线程产生的线程也采用相同的安全标识。这是通过使用SecurityContextHolder.MODE_INHERITABLETHREADLOCAL.实现的。您可以通过两种方式更改默认的SecurityContextHolder.MODE_THREADLOCAL模式。第一种是设置系统属性，第二种是调用SecurityConextHolder上的静态方法。大多数应用程序不需要更改默认设置，但如果您需要更改，请查看用于SecurityConextHolder的Javadoc以了解更多信息。

SecurityContext

SecurityContext是从SecurityConextHolder获取的。SecurityContext包含一个 Authentication 对象。

Authentication

在 Spring Security 中，Authentication 主要用于两个目的:

• AuthenticationManager 的输入，用于提供用户提供的身份验证凭据。在此场景中使用时，isAuthenticated ()返回 false。
• 表示当前经过身份验证的用户。可以从 SecurityContext 获取当前 Authentication 。

Authentication 包含：

• principal - 标识用户。当使用用户名/密码进行身份验证时，这通常是 UserDetails 的一个实例。
• credentials - 通常是密码。在许多情况下，在用户经过身份验证以确保其不泄漏之后，这些信息将被清除。
• authorities - GrantedAuthority 是授予用户的权限。比如：角色或权限范围。

GrantedAuthority

GrantedAuthoritys 是授予用户的权限。
GrantedAuthoritys 可以从Authation.getAuthoritys() 方法获取。此方法提供 GrantedAuthority 对象的集合。毫不奇怪，GrantedAuthority 是授予主体的权限。这类权限通常是“角色”，如ROLE_ADMANAGER或ROLE_HR_SUPERSOR。这些角色稍后配置为Web授权、方法授权和域对象授权。Spring Security的其他部分能够解释这些权限，并期望它们出现。当使用基于用户名/密码的身份验证时，GrantedAuthoritys通常由UserDetailsService加载。

通常 GrantedAuthority 对象是应用程序范围的权限。它们并不特定于给定的域对象。因此，您不太可能一个 GrantedAuthority 来表示对编号为54的Employee对象的权限，因为如果有数千个这样的权限，您将很快耗尽内存(或者，至少，导致应用程序需要很长时间来验证用户)。当然，Spring Security 是专门为处理这一常见需求而设计的，但您可以使用项目的域对象安全功能来实现这一目的。

AuthenticationManager

AuthenticationManager 是定义Spring Security的过滤器如何执行身份验证的接口类。然后由调用 AuthenticationManager 的控制器(即 Spring Security 的 Filterss)在 SecurityContextHolder 上设置返回的 Authentication。如果你没有集成 Spring Security 的 Filterss，你可以直接设置 SecurityContextHolder，并且不需要使用 AuthenticationManager。

虽然 AuthenticationManager 的实现可以是任何东西，但最常见的实现是 ProviderManager。

ProviderManager

ProviderManager 是 AuthenticationManager 最常用的实现。ProviderManager 委托到 AuthenticationProvider 列表。每个AuthenticationProvider 都有机会指示身份验证应该成功、失败或指示它不能做出决定，并允许下游 AuthenticationProvider 做出决定。如果配置的 AuthenticationProvider 没有一个能够进行身份验证，那么身份验证将失败，并引发ProviderNotFoundException 异常，这是一种特殊的身份验证异常，指示 ProviderManager 未配置支持传入的身份验证类型。

实际上，每个 AuthenticationProvider 都知道如何执行特定类型的身份验证。例如，一个 AuthenticationProvider 可能能够验证用户名/密码，而另一个可能能够验证 SAML 断言。这允许每个 AuthenticationProvider 执行特定类型的身份验证，同时支持多种类型的身份验证，并且只公开一个 AuthenticationManager bean。

ProviderManager 还允许配置可选的父身份验证管理器，在没有身份验证提供程序可以执行身份验证的情况下，可以查询该父身份验证管理器。父级可以是任何类型的 AuthenticationManager，但它通常是 ProviderManager 的实例。

实际上，多个 ProviderManager 实例可能共享同一个父 AuthenticationManager。这在多个 SecurityFilterChain 实例具有一些共同的身份验证(共享的父身份验证管理器)以及不同的身份验证机制(不同的 ProviderManager 实例)的场景中有些常见。

默认情况下，ProviderManager 将尝试从成功的身份验证请求返回的 Authentication 对象中清除任何敏感的凭据信息。这可以防止诸如密码在 HttpSession 中保留的时间超过必要的时间等信息。

例如，当您使用用户对象缓存时，这可能会导致问题，以提高无状态应用程序的性能。如果 Authentication 在缓存中包含对某个对象的引用(例如 UserDetails 实例) ，并且该对象的凭据已被删除，那么将不再可能根据缓存的值进行身份验证。如果您正在使用缓存，则需要考虑到这一点。一个显而易见的解决方案是首先在缓存实现中或在创建返回的 Authentication 对象的 AuthenticationProvider 中创建对象的副本。或者，您可以在 ProviderManager 上禁用 eraseCredentialsAfterAuthentication 属性。有关更多信息，请参见 Javadoc。

AuthenticationProvider

可以将多个 AuthenticationProvider 注入到 ProviderManager 中。每个 AuthenticationProvider 执行特定类型的身份验证。例如，DaoAuthenticationProvider 支持基于用户名/密码的身份验证，而 JwtAuthenticationProvider 支持对 JWT 令牌进行身份验证。

AuthenticationEntryPoint

AuthenticationEntryPoint 用于发送向客户端请求凭据的HTTP响应。

有时，客户机会主动包含凭据，例如用户名/密码来请求资源。在这些情况下，Spring Security 不需要提供从客户机请求凭据的 HTTP 响应，因为它们已经包含在内。

在其他情况下，客户机将对未经授权访问的资源发出未经身份验证的请求。在这种情况下，AuthenticationEntryPoint 的实现用于从客户机请求凭据。AuthenticationEntryPoint 实现可能会执行到登录页面的重定向，以 WWW-Authenticate 标头响应等。

AbstractAuthenticationProcessingFilter

Abstractauthentigationprocessingfilter 用作验证用户凭据的基本筛选器。在可以对凭据进行身份验证之前，Spring Security 通常使用 AuthenticationEntryPoint 请求凭据。
接下来，Abstractauthentigationprocessingfilter 可以对提交给它的任何身份验证请求进行身份验证。

① 当用户提交他们的凭证时，AbstractAuthenticationProcessingFilter 从 HttpServletRequest 创建一个身份验证，以进行身份验证。所创建的身份验证的类型取决于 AbstractAuthenticationProcessingFilter 的子类。例如，UsernamePasswordAuthenticationFilter 从 HttpServletRequest 中提交的用户名和密码创建一个 UsernamePasswordAuthenticationToken。
② 接下来，身份验证被传递到 AuthenticationManager 以进行身份验证。
③ 如果身份验证失败，则失败：
- SecurityContextHolder被清空
- 调用 RememberMeServices.loginFail。如果没有配置 remember me，这是一个 no-op。
- 调用 AuthenticationFailureHandler
④ 如果身份验证成功，则为成功：
- 调用 RememberMeServices.loginSuccess。如果没有配置 remember me，这是一个 no-op。
- ApplicationEventPublisher 发布 InteractiveAuthenticationSuccessEvent
- 调用 AuthenticationSuccessHandler

参考 SpringSecurity 官方文档