关于springsecurity:源码剖析用户信息的管理者UserDetailsManager

Spring Security 的作为守门员，其两大性能：认证（Authentication）和 受权（authorization）

学而思：

• Spring Security 是如何对用户进行治理的？

初始化我的项目并启动

初始化一个 Spring Boot 我的项目并编写一个接口，在没有引入 Spring Security 依赖时，接口是可能能失常拜访的。

@RestController
@RequestMapping("/user")
public class UmsAdminController {@GetMapping("/details")
    public Object userInfos() {return "用户详情";}
}

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-test</artifactId>
    <scope>test</scope>
</dependency>

在引入依赖后，再次申请接口 http://localhost:8080/user/details，页面跳转至了登录页面。

用户默认名为 user，默认明码是每次启动利用时随机生成的，启动利用时，显示在了控制台中。

UserDetailsManager

明明什么都没干，只是引入平安的框架，为什么申请接口就被拦挡？

这就与 Spring Security 的机制无关，Spring Security 采纳了”默认回绝“的安全策略。意思是资源默认对未认证受权用户禁止拜访。为须要凋谢的资源进行属性配置，而不是默认对资源进行凋谢，这被认为是一种良好的平安做法。

在申请接口前，Spring Security 采纳了过滤器对接口进行拦挡认证（过滤器是 Security 的外围局部，这个之后再详述）。认证过程中用到 UserDetailsManager，也就是本章的配角。

UserDetailsManager 是治理用户的接口，继承了 UserDetailsService 接口，UserDetailsService 提供了加载用户详细信息（UserDetails）的办法 (loadUserByUsername)。

• UserDetails：用户详细信息的接口，对用户的形象，提供了获取用户名和明码等办法
• UserDetailsService：提供了一个加载用户的办法，该办法依据用户名从存储（内存、数据库等）中查问出用户对象（UserDetails），认证过程最终就是通过调用该办法，来认证用户。
• UserDetailsManager：在 UserDetailsService 根底上减少了 增删改等性能，实现了对用户的治理。

两个实现类

在 Spring Security 中，UserDetailsManager 有两个实现类，如下图：

• InMemoryUserDetailsManager：基于内存的用户管理器，我的项目初始化时默认应用，不能满足业务需要
• JdbcUserDetailsManager：基于数据库的用户管理器，更合乎实在业务的需要

InMemoryUserDetailsManager

先来摸索 InMemoryUserDetailsManager 在 Security 中是如何构建的。

在 Spring Boot 中有一个主动配置类 UserDetailsServiceAutoConfiguration。向 Ioc 容器中注入了 InMemoryUserDetailsManager 对象。

在 构建 InMemoryUserDetailsManager 对象的同时，向其注入了一个 User 对象（UserDetails 的实现类），并把一个动态类 User 的 name 和 通过加工的 password¹ 作为 用户名和明码。

这正好对应了 后面登录时所需的用户名和明码。

然而这样的用户管理器很难满足实在业务需要，实在的用户数据存在于数据库中，因而能够从新构建 UserDetailsManager 的实现类，对性能进行扩大。

比方上面的 JdbcUserDetailsManager。

JdbcUserDetailsManager

未完待续。。。