乐趣区

关于java:Spring-Security自定义用户认证过程1

jiezi

通过后面对 SpringSecurity 平安过滤器工作原理的剖析（Spring Security 平安过滤器工作原理）咱们晓得 Spring Security 的用户认证过程的工作原理大略为：

  1. SecurityContextPersistenceFilter 过滤器负责基于 session 的用户认证信息的治理。
  2. UsernamePasswordAuthenticationFilter 负责用户登录认证，认证胜利后将认证信息写入 SecurityContextHolder 中。
  3. FilterSecurityInterceptor 负责验证以后用户是否合乎以后申请的安全策略要求。

所以咱们晓得用户认证是在 UsernamePasswordAuthenticationFilter 过滤器实现的，如果咱们要实现自定义的用户登录认证的话，只有想方法替换掉 UsernamePasswordAuthenticationFilter 过滤器中的原装缺省用户认证过程，应该就能够了。

接下来咱们钻研：

  1. 什么是用户认证。
  2. UsernamePasswordAuthenticationFilter 过滤器的缺省认证过程。
  3. 如何替换掉 UsernamePasswordAuthenticationFilter 的缺省用户认证过程。

什么是用户认证

这个问题其实咱们并不钻研、只是申明，明确一下咱们所要钻研的问题的主题。

Spring Security 官网 overview 局部开宗明义阐明 SpringSecurity 是什么的时候就明确提过用户认证：

Spring Security is a framework that provides authentication, authorization, and protection against common attacks.

阐明用户认证是 Spring Security 的重要主题之一。

咱们简化、明确一下明天要钻研的用户认证这个主题理论就是：用户身份认证，让零碎搞清楚你是否是非法用户的过程。

目前我的项目上或者咱们见过的零碎中用的最多的身份认证形式还是用户名、明码（或者短信验证码），用户身份认证其实蕴含两局部内容：

  1. 身份确认：通过登录形式实现。
  2. 身份放弃及验证：就是登录验证实现之后，用户身份认证信息在保留以及后续的用户拜访过程中的验证问题。

第一个问题比较简单明确，第二个问题就会引入两种不同的支流框架，次要区别是用户身份认证信息如何保留：

  1. 服务器端保留：最常见的 session 形式。
  2. 客户端持有：比方 JWT 的形式

咱们明天要探讨的是 身份认证 的过程，疏忽或简化身份信息的保留和持有过程，或者说咱们就以传统的、Spring Security 默认提供的通过 session 形式在服务器端持有用户身份认证信息的形式，来把明天钻研的主题聚焦在 身份认证 这个问题上。

UsernamePasswordAuthenticationFilter 过滤去的身份认证过程

先来意识几个概念：

  1. Authentication：或者叫 AuthenticationToken，默认实现是 UsernamePasswordAuthenticationToken，用来持有申请上来的用户名、明码等信息，以及最终通过认证后的用户认证信息。
  2. AuthenticationManager：认证管理器，由他来发动认证，然而他不实现认证，而是有他持有的 AuthenticationProvider 实现。
  3. AuthenticationProvider：如上。
  4. UserDetails：零碎非法用户信息，比方你的零碎的非法用户保留在数据库中，那么在发动认证的过程中就须要从数据库获取到后保留在 UserDetails 中，对应的有一个叫 UserDetailsService 的家伙，负责干这个事。
  5. PasswordEncoder：顾名思义，明码编码器，零碎用户的明码在零碎中肯定是以密文保留，前台提交上来的个别是明文，须要通过 PasswordEncoder 验密。说白了你的明码加密算法就是在 PasswordEncoder 中实现。

差不多够了，咱们就用下面几个概念来阐明一下 UsernamePasswordAuthenticationFilter 过滤器的用户登录认证过程。

第一步用 request 生成 UsernamePasswordAuthenticationToken，此时生成的 UsernamePasswordAuthenticationToken 对象中只有前端登录页面传上来的用户名、明码，该 token 尚未实现认证。咱们假如前台送上来的用户叫：user。前台录入的明码是：123456。

第二步，获取到 AuthenticationManager 进行认证，下面说过了，他是 manager，他不干活，交给 AuthenticationProvider 去干。

第三步，AuthenticationProvider 开始干活，他首先获取到 UserDetailsService，让他获取到零碎中叫 user 的用户信息，返回 UserDetails 对象（假如获取到了，对象名叫 sysUser）。

第四步，仍然是由 AuthenticationProvider 持续干，拿着前端送上来的用户名、明码（以后由 UsernamePasswordAuthenticationToken 对象持有）、以及后盾获取到的用户对象（sysUser），交给 PasswordEncoder 去验密。

第五步，AuthenticationProvider 持续拼命干活，如果认证通过的话（明码一样），从新生成一个 UsernamePasswordAuthenticationToken，这是曾经实现认证的 token。

第六步，AuthenticationProvider 干完活了交给经理 AuthenticationManager，经理甩手把后果交给过滤器 UsernamePasswordAuthenticationFilter。

第七步，过滤器把最终认证过的 UsernamePasswordAuthenticationToken 保留在 SecurityContextHolder 中，供后续过滤器、尤其是 FilterSecurityInterceptor 验证应用。

UsernamePasswordAuthenticationFilter 完成使命！

如何替换掉 UsernamePasswordAuthenticationFilter 的缺省用户认证过程

这个题目长的我有点不太适应，然而就这样吧。

这个问题你如果去百度或者 google 的话，会有很多不同的答案，我了解因为 Spring Security 自身是 Spring 家族的一员，与 Spring 或 SpringBoot 联合之后留给用户的客户化形式泛滥，所以咱们能够任选其一进行客户化。

任何既可能实现你的指标、又没有给你的我的项目带来负面影响计划，都是可行的。

上面咱们开始实现这一指标。

通过上面对 UsernamePasswordAuthenticationFilter 工作过程的剖析，咱们能够先构想一个思路：替换掉上述第三步中的 UserDetailsService，让咱们本人的 UserDetailsService 干活，去获取咱们本人的用户。

我认为这是比较简单的计划，你当然能够替换掉整个 UsernamePasswordAuthenticationFilter，然而这样的话你就相当于是替换掉了 Spring Security 的一个重要模块，你就能够狐疑他还是不是 Spring Security 了。

篇幅起因，本篇剖析原理，下一篇文章具体操作。

上一篇 Spring Security 平安过滤器工作原理
下一篇 Spring Security 自定义用户认证过程（2）

退出移动版