在上一篇文章中，我们沿用了 Spring Security 默认的安全机制；仅有一个用户，仅有一种角色。在实际开发中，这自然是无法满足需求的。本篇文章将更加深入地对 Spring Security 进行配置，且初步使用授权机制。
一、默认数据库模型的认证和授权：
1、资源准备：
首先，新建 controller 包，并创建 3 个控制器，并分别在控制器中建立一些测试路由，三个类的代码如下所示：
@RestController
@RequestMapping("/admin/api")
public class AdminController {
@GetMapping("/hello")
public String hello() {
return "hello admin";
}
}
@RestController
@RequestMapping("/app/api")
public class AppController {
@GetMapping("/hello")
public String hello() {
return "hello app";
}
}
@RestController
@RequestMapping("/user/api")
public class UserController {
@GetMapping("/hello")
public String hello() {
return "hello user";
}
}假设在 /admin/api 下的内容是系统后台管理相关的 API，在 /app/api 下的内容是面向客户端公开访问的 API，在 /user/api/ 下的内容是用户操作自身数据相关的 API；显然，/admin/api 必须拥有管理员权限才能进行操作，而 /user/api 必须在用户登录后才能进行操作。
2、资源授权的配置：
为了能正常访问前面的路由，我们需要修改配置类 WebSecurityConfig ，代码如下所示：
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter{
protected void configure(HttpSecurity http) throws Exception{
http.authorizeRequests().
antMatchers("/admin/api/**").hasRole("ADMIN").
antMatchers("/user/api/**").hasRole("USER").
antMatchers("/app/api/**").permitAll().
anyRequest().authenticated().
and().formLogin();
}
}antMatchers() 是一个采用 ANT 模式的 URL 匹配器。ANT 模式使用？匹配任意单个字符，使用 * 匹配 0 或任意数量的字符，使用 ** 匹配 0 或者更多目录。antMatchers("/admin/api/**") 相当于匹配了 /admin/api/ 下所有的 API 。此处我们指定当其必须为 ADMIN 角色时才能访，/user/api/ 与之同理。/app/api/ 下的 API 会调用 permitAll() 公开其权限。
授权相关的配置看起来并不复杂，但似乎缺少了什么？这里暂且忽略。
重启服务，尝试访问 localhost:8080/app/api/hello，页面打印 “hello app”，验证了 /app/api/ 下的服务确实是权限公开的。接着访问 localhost:8080/user/api/hello，这次需要登录了。我们尝试输入前面在 application.properties 中定义的用户名和密码，登录之后，页面打印 “hello user” 。然而，我们并没有 user 用户，为什么可以成功访问路由呢？为了验证不是授权环节出现了问题，我们尝试访问 localhost:8080/admin/api/hello，出现的内容如下所示：
页面显示 403 错误，表示该用户授权失败（ 401 代表该用户认证失败）。也就是说，本次访问已经通过了认证环节，只是在授权的时候被驳回了。认证环节是没有问题的，因为 Spring Security 默认的用户角色正是 user。
HTTP 状态码（HTTP Status Code）是由 RFC 2616 定义的一种用来表示一个 HTTP 请求响应状态的规范，由 3 位数字组成。通常用 2XX 表示本次操作成功，用 4XX 表示是客户端导致的失败，用 5XX 表示是服务器引起的错误。
3、基于内存的多用户支持：
到目前为止，我们仍然只有一个可登录的用户，怎样引入多用户呢？非常简单，我们只需实现一 个自定义的 UserDetailsService 即可，代码如下所示：
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter{
protected void configure(HttpSecurity http) throws Exception{
http.authorizeRequests().
antMatchers("/admin/api/**").hasRole("ADMIN").
antMatchers("/user/api/**").hasRole("USER").
antMatchers("/app/api/**").permitAll().
anyRequest().authenticated().
and().formLogin();
}
@Bean
public UserDetailsService userDetailsService() {
InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
manager.createUser(User.withUsername("user").password("123").roles("USER").build());
manager.createUser(User.withUsername("admin").password("123").roles("USER","ADMIN").build());
return manager;
}
}为其添加一个 @bean 注解，便可被 Spring Security 发现并使用。Spring Security 支持各种来源的用户数据，包括内存、数据库、LDAP 等。它们被抽象为一个 UserDetailsService 接口，任何实现了 UserDetailsService 接口的对象都可以作为认证数据源。在这种设计模式下，Spring Security 显得尤为灵活。
InMemoryUserDetailsManager 是 UserDetailsService 接口中的一个实现类，它将用户数据源寄存在内存里，在一些不需要引入数据库这种重数据源的系统中很有帮助。 这里仅仅调用createUser() 生成两个用户，并赋予相应的角色。它会工作得很好，多次重启服务也不会出现问题。为什么要强调多次重启服务呢？稍后揭晓答案。
4、基于默认数据库模型的认证与授权：
除了 InMemoryUserDetailsManager ，Spring Security 还提供另一个 UserDetailsService 实现类： JdbcUserDetailsManager。
JdbcUserDetailsManager 帮助我们以 JDBC 的方式对接数据库和 Spring Security，它设定了一个默认的数据库模型，只要遵从这个模型，在简便性上，JdbcUserDetailsManager 甚至可以媲美 InMemoryUserDetailsManager。
4.1、数据库准备：
在 pom.xml 中引入 jdbc 和 mysql 的数据库依赖，如下所示：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
</dependency>接着在 application.properties 中配置数据库连接参数。
spring.datasource.url = jdbc:mysql://localhost:3306/springDemo?useUnicode=true&characterEncoding=utf-8&useSSL=false
spring.datasource.username = root
spring.datasource.password = Rfid123456这里连接的数据库名为 springDemo（不配置 driverClassName 也不会出现问题，因为 SpringBoot 会自动根据 URL 去推断），用户名和密码分别为 root 和 Rfid123456，读者可根据实际情况，自行修改。 前面介绍过，JdbcUserDetailsManager 设定了一个默认的数据库模型，SpringSecurity 将该模型定义在 /org/springframework/security/core/userdetails/jdbc/users.ddl 内。
接下来是建表语句，如下所示：
create database springDemo;
use springDemo;
create table users(
username varchar(50) not null primary key,
password varchar(500) not null,
enabled boolean not null
);
create table authorities(
username varchar(50) not null,
authority varchar(50) not null,
constraint fk_authorities_user foreign key(username) references users(username)
);
create unique index ix_auth_username on authorities(username,authority);
JdbcUserDetailsManager 需要两个表，其中 users 表用来存放用户名、密码和是否可用三个信息， authorities 表用来存放用户名及其权限的对应关系。
4.2、编码实现：
下面构建一个 JdbcUserDetailsManager 实例，让 Spring Security 使用数据库来管理用户。
import org.apache.tomcat.jdbc.pool.DataSource;
@Autowired
private DataSource dataSource;
@Bean
public UserDetailsService userDetailsService() {
JdbcUserDetailsManager manager = new JdbcUserDetailsManager();
manager.setDataSource(dataSource);
manager.createUser(User.withUsername("user").password("123").roles("USER").build());
manager.createUser(User.withUsername("admin").password("123").
roles("USER","ADMIN").build());
return manager;
}
JdbcUserDetailsManager 与 InMemoryUserDetailsManager 在用法上没有太大区别，只是多了设置 DataSource 的环节。Spring Security 通过 DataSource 执行设定好的命令。例如，此处的 createUser 函数实际上就是执行了下面的 SQL 语句：
insert into users(username,password,enabled) values(?,?,?)查看 JdbcUserDetailsManager 的源代码可以看到更多定义好的 SQL 语句，诸如deleteUserSql、 updateUserSql 等，这些都是 JdbcUserDetailsManager 与数据库实际交互的形式。当然， JdbcUserDetailsManager 也允许我们在特殊情况下自定义这些 SQL 语句，如有必要，调用对应的 setXxxSql方法即可。
现在重启服务，看看在数据库中 Spring Security 生成了哪些数据，如下图所示。
authorities 表的 authority 字段存放的是前面设定的角色，只是会被添上 “ROLE_” 前缀。下面尝试通过 SQL 命令创建一个测试账号。
insert into users values("test","123",1);
insert into authorities values("test","ROLE_USER");清空缓存并使用 test 账号访问系统，发现可以访问 user 路由，但不能访问 admin 路由，与预期的行为一致。
到目前为止，一切都工作得很好，但是只要我们重启服务，应用就会报错。这是因为 users 表在创建语句时，username 字段为主键，主键是唯一不重复的，但重启服务后会再次创建 admin 和 user，导致数据库报错（在内存数据源上不会出现这种问题，因为重启服务后会清空 username 字段中的内容）。 所以如果需要在服务启动时便生成部分用户，那么建议先判断用户名是否存在。如下所示：
import org.apache.tomcat.jdbc.pool.DataSource;
@Autowired
private DataSource dataSource;
@Bean
public UserDetailsService userDetailsService() {
JdbcUserDetailsManager manager = new JdbcUserDetailsManager();
manager.setDataSource(dataSource);
if(!manager.userExists("user")){
manager.createUser(User.withUsername("user").password("123").
roles("USER").build());
}
if(!manager.userExists("admin")) {
manager.createUser(User.withUsername("admin").password("123").
roles("USER","ADMIN").build());
}
return manager;
}
在自定义表单登录页中，WebSecurityConfigurerAdapter 类定义了三个 configure() 方法。
protected void configure(AuthenticationManagerBuilder auth) throws Exception {
this.disableLocalConfigureAuthenticationBldr = true;
}
public void configure(WebSecurity web) throws Exception {
}
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.anyRequest().authenticated()
.and()
.formLogin().and()
.httpBasic();
}我们只用到了一个 http 参数，用来接收 HttpSecurity 对象的配置方法。另外两个参数也有各自的用途，其中，AuthenticationManagerBuilder 的 configure 同样允许我们配置认证用户。
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter{
protected void configure(HttpSecurity http) throws Exception{
http.authorizeRequests().
antMatchers("/admin/api/**").hasRole("ADMIN").
antMatchers("/user/api/**").hasRole("USER").
antMatchers("/app/api/**").permitAll().
anyRequest().authenticated().
and().formLogin();
}
protected void configure(AuthenticationManagerBuilder auth) throws Exception {
auth.inMemoryAuthentication()
.withUser("user").password("123").roles("user")
.and()
.withUser("admin").password("123").roles("admin");
}
}使用方法大同小异，这里不再赘述。
当使用 Spring Security 默认数据库模型应对各种用户系统时，难免灵活性欠佳。尤其是在对现有的系统做 Spring Security 嵌入时，原本的用户数据已经固定，为了适配 Spring Security 而在数据库层面进行修改显然得不偿失。强大而灵活的 Spring Security 对这方面进行了改进。