Spring Security的认证和授权

最新推荐文章于 2024-04-18 10:02:32 发布

小杨敲代码

最新推荐文章于 2024-04-18 10:02:32 发布

阅读量1.1k

点赞数 26

文章标签： spring java 数据库

本文链接：https://blog.csdn.net/m0_74777020/article/details/136410522

版权

前言

Spring Security是为基于Spring的应用程序提供声明式安全保护的安全性框架。Spring Security提供了完整的安全性解决方案，它能够在Web请求级别和方法调用级别处理身份认证和授权。因为基于Spring框架，所以Spring Security充分利用了依赖注入（dependency injection，DI）和面向切面（AOP）的技术。

基本概念

认证

以手机必装APP微信为例，在初次使用微信前需要注册成为微信用户，然后输入账号和密码即可登录微信，输入账号和密码登录微信的过程就是认证。

系统为什么要认证？

认证是为了保护系统的隐私数据与资源，用户的身份合法方可访问该系统的资源。用户认证就是判断一个用户的身份是否合法的过程，用户去访问系统资源时系统要求验证用户的身份信息，身份合法方可继续访问，不合法则拒绝访问。常见的用户身份认证方式有：用户名密码登录，二维码登录，手机短信登录，指纹认证等方式。

会话

用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保存在会话中。会话就是系统为了保持当前用户的登录状态所提供的机制，常见的有基于session方式、基于token方式等。

基于session的认证方式如下图：

它的交互流程是，用户认证成功后，在服务端生成用户相关的数据保存在session(当前会话)中，发给客户端的sesssion_id存放到cookie中，这样用户客户端请求时带上session_id就可以验证服务器端是否存在session数据，以此完成用户的合法校验，当用户退出系统或session过期销毁时，客户端的session_id也就无效了。

基于token方式如下图：

它的交互流程是，用户认证成功后，服务端生成一个token发给客户端，客户端可以放到cookie或localStorage等存储中，每次请求时带上token，服务端收到token通过验证后即可确认用户身份。

基于session的认证方式由Servlet规范定制，服务端存储session信息需要占用内存资源，客户端需要支持cookie；基于token的方式则一般不需要服务端存储token，并且不限制客户端的存储方式。如今移动互联网时代更多类型的客户端需要接入系统，系统多是采用前后端分离的架构进行实现，所以基于token的方式更适合。

授权

微信登录成功后用户即可使用微信的功能，比如，发红包、发朋友圈、添加好友等，没有绑定银行卡的用户是无法发送红包的，绑定银行卡的用户才可以发红包，发红包功能、发朋友圈功能都是微信的资源即功能资源，用户拥有发红包功能的权限才可以正常使用发送红包功能，拥有发朋友圈功能的权限才可以使用发朋友圈功能，这个根据用户的权限来控制用户使用资源的过程就是授权。

为什么要授权？

认证是为了保证用户身份的合法性，授权则是为了更细粒度的对隐私数据进行划分，授权是在认证通过后发生的，控制不同的用户能够访问不同的资源。

授权是用户认证通过根据用户的权限来控制用户访问资源的过程，拥有资源的访问权限则正常访问，没有权限则拒绝访问。

授权的数据模型

授权可简单理解为Who对What(which)进行How操作：

Who，即主体（Subject），主体一般是指用户，也可以是程序，需要访问系统中的资源。
What，即资源（Resource），如系统菜单、页面、按钮、代码方法、系统商品信息、系统订单信息等。系统菜单、页面、按钮、代码方法都属于系统功能资源，对于web系统每个功能资源通常对应一个URL；系统商品信息、系统订单信息都属于实体资源（数据资源），实体资源由资源类型和资源实例组成，比如商品信息为资源类型，商品编号为001的商品为资源实例。
How，权限/许可（Permission），规定了用户对资源的操作许可，权限离开资源没有意义，如用户查询权限、用户添加权限、某个代码方法的调用权限、编号为001的用户的修改权限等，通过权限可知用户对哪些资源都有哪些操作许可。

主体、资源、权限关系如下图：

我们一般并不会直接对主体授权，而是在主体和权限之间引入了角色的概念，让主体和权限解耦，使得配置更灵活。设计的数据模型如下图：

主体（用户id、账号、密码、…）
角色（角色id、角色名称、…）
权限（权限id、权限标识、权限名称、资源id、…）
资源（资源id、资源名称、访问地址、…）
主体（用户）和角色关系（用户id、角色id、…）
角色和权限关系（角色id、权限id、…）

通常企业开发中将资源和权限表合并为一张权限表：

资源（资源id、资源名称、访问地址、…）
权限（权限id、权限标识、权限名称、资源id、…）

合并为：

权限（权限id、权限标识、权限名称、资源名称、资源访问地址、…）

修改后数据模型之间的关系如下图：

RBAC

基于角色的访问控制

RBAC基于角色的访问控制（Role-Based Access Control）是按角色进行授权，比如：主体的角色为总经理可以查询企业运营报表，查询员工工资信息等，访问控制流程如下：

根据上图中的判断逻辑，授权代码可表示如下：

if(主体.hasRole("总经理角色id")){ 查询工资; }

如果上图中查询工资所需要的角色变化为总经理和部门经理，此时就需要修改判断逻辑为“判断用户的角色是否是总经理或部门经理”，修改代码如下：

if(主体.hasRole("总经理角色id") || 主体.hasRole("部门经理角色id")){ 查询工资; }

根据上边的例子发现，当需要修改角色的权限时就需要修改授权的相关代码，系统可扩展性差。

基于资源的访问控制

RBAC基于资源的访问控制（Resource-Based Access Control）是按资源（或权限）进行授权，比如：用户必须具有查询工资权限才可以查询员工工资信息等，访问控制流程如下：

根据上图中的判断，授权代码可以表示为：

if(主体.hasPermission("查询工资权限标识")){ 查询工资; }

优点：系统设计时定义好查询工资的权限标识，即使查询工资所需要的角色变化为总经理和部门经理也不需要修改授权代码，系统可扩展性强

Spring Security快速上手

介绍

Spring Security是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。由于它是Spring生态系统中的一员，因此它伴随着整个Spring生态系统不断修正、升级，在spring boot项目中加入Spring Security更是十分简单，使用Spring Security 减少了为企业系统安全控制编写大量重复代码的工作。

Spring Boot是一套Spring的快速开发框架，基于Spring 4.0设计，使用Spring Boot开发可以避免一些繁琐的工程搭建和配置，同时它集成了大量的常用框架，快速导入依赖包，避免依赖包的冲突。我们将采用Spring Boot提供的spring-boot-starter-security依赖包开发Spring Security应用。

创建工程

创建maven工程security-spring-boot，工程结构如下：

引入依赖

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.test.security</groupId>
    <artifactId>security-spring-boot</artifactId>
    <version>1.0-SNAPSHOT</version>

    <!-- 指定spring-boot版本 -->
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.3.RELEASE</version>
    </parent>

    <dependencies>
        <!-- 以下是spring boot依赖-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <!-- 以下是spring security依赖-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>

    </dependencies>
</project>

SpringBoot配置

SpringBoot工程启动会自动扫描启动类所在包下的所有Bean，加载到spring容器。

Spring Boot配置文件

在resources下添加application.properties，内容如下：

server.port=8080
server.servlet.context-path=/
spring.application.name=security-springboot

Spring Boot 启动类

@SpringBootApplication
public class SecuritySpringBootApp {
    public static void main(String[] args) {
        SpringApplication.run(SecuritySpringBootApp.class, args);
    }
}

认证页面

Spring Security默认提供认证页面，不需要额外开发。由于Spring boot starter自动装配机制，我们只需指定一个包含注解@Configuration的配置类WebConfig即可，在WebConfig.java中添加默认请求根路径跳转到/login，此url为spring security提供。

@Configuration//就相当于springmvc.xml文件
public class WebConfig implements WebMvcConfigurer {
    //默认Url根路径跳转到/login，此url为spring security提供 
    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/").setViewName("redirect:/login");
    }
}

Spring Security提供的默认登录页面/login：

Spring Security提供的默认登出页面为/logout：

安全配置

Spring Security提供了用户名密码登录、退出、会话管理等认证功能，只需要配置即可使用。

在config包下定义WebSecurityConfig，安全配置的内容包括：用户信息、密码编码器、安全拦截机制。

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    //定义用户信息服务（查询用户信息）
    @Bean
    public UserDetailsService userDetailsService(){
        InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
        manager.createUser(User.withUsername("zhangsan").password("123").authorities("p1").build());
        manager.createUser(User.withUsername("lisi").password("456").authorities("p2").build());
        return manager;
    }

    //密码编码器
    @Bean
    public PasswordEncoder passwordEncoder(){
        return NoOpPasswordEncoder.getInstance();  //不加密密码，明文比对
    }

    //安全拦截机制（最重要）
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
                .antMatchers("/r/r1").hasAuthority("p1")
                .antMatchers("/r/r2").hasAuthority("p2")
                .antMatchers("/r/**").authenticated()//所有/r/**的请求必须认证通过
                .anyRequest().permitAll()//除了/r/**，其它的请求可以访问
                .and()
                .formLogin()//允许表单登录
                .successForwardUrl("/login-success");//自定义登录成功的页面地址
    }
}

在userDetailsService方法中，我们返回了一个UserDetailsService给spring容器，Spring Security会使用它来获取用户信息。我们暂时使用InMemoryUserDetailsManager实现类，并在其中分别创建了zhangsan、lisi两个用户，并设置密码和权限。

在configure方法中，我们通过HttpSecurity设置了安全拦截规则，其中包含了以下内容：

url匹配/r/**的资源，经过认证后才能访问。
其他url完全开放。
授权：访问/r/r1资源的 url需要拥有p1权限，访问/r/r2资源的 url需要拥有p2权限.
支持form表单认证，认证成功后转向/login-success。

更多关于HttpSecurity的配置可参考附录：HttpSecurity配置列表。

测试

创建一个LoginController控制器类：

@RestController
public class LoginController {
    @RequestMapping(value = "/login-success",produces = {"text/plain;charset=UTF-8"})
    public String loginSuccess(){
        //用户登录成功后跳转到该页面
        return "登录成功";
    }

    /**
     * 测试资源1
     * @return
     */
    @GetMapping(value = "/r/r1",produces = {"text/plain;charset=UTF-8"})
    public String r1(){
        return "访问资源1";
    }

    /**
     * 测试资源2
     * @return
     */
    @GetMapping(value = "/r/r2",produces = {"text/plain;charset=UTF-8"})
    public String r2(){
        return "访问资源2";
    }
}

经测试我们可以发现，在没有登录的情况下访问url/r/r1或者/r/r2会跳转到登录页，访问非/r开头的url比如/a/b会提示404错误。我们可以用账号zhangsan和密码123或者lisi和密码456进行登录，输入其他会提示账号密码错误。在登录zhangsan后，可以正常访问/r/r1，访问/r/r2会提示403错误。

工作原理

结构总览

Spring Security所解决的问题就是安全访问控制，而安全访问控制功能其实就是对所有进入系统的请求进行拦截，校验每个请求是否能够访问它所期望的资源。Spring Security对Web资源的保护是靠Filter实现的，当初始化Spring Security时，会创建一个名为SpringSecurityFilterChain的Servlet过滤器，类型为org.springframework.security.web.FilterChainProxy，它实现了javax.servlet.Filter，因此外部的请求会经过此类，Spring Security过滤器链结构图：

FilterChainProxy是一个代理，真正起作用的是FilterChainProxy中SecurityFilterChain所包含的各个Filter，同时这些Filter作为Bean被Spring管理，它们是Spring Security核心，各有各的职责，但他们并不直接处理用户的认证，也不直接处理用户的授权，而是把它们交给了认证管理器（AuthenticationManager）和决策管理器（AccessDecisionManager）进行处理，下图是FilterChainProxy相关类的UML图示：

Spring Security功能的实现主要是由一系列过滤器链相互配合完成。

过滤器链中几个主要的过滤器及其作用：

SecurityContextPersistenceFilter 这个Filter是整个拦截过程的入口和出口（也就是第一个和最后一个拦截器），会在请求开始时从配置好的SecurityContextRepository中获取SecurityContext，然后把它设置给SecurityContextHolder。在请求完成后将SecurityContextHolder持有的SecurityContext再保存到配置好的SecurityContextRepository，同时清除 SecurityContextHolder所持有的SecurityContext；
UsernamePasswordAuthenticationFilter 用于处理来自表单提交的认证。该表单必须提供对应的用户名和密码，其内部还有登录成功或失败后进行处理的AuthenticationSuccessHandler和 AuthenticationFailureHandler，这些都可以根据需求做相关改变；
FilterSecurityInterceptor 是用于保护web资源的，使用AccessDecisionManager对当前用户进行授权访问；
ExceptionTranslationFilter 能够捕获来自FilterChain所有的异常并进行处理。但是它只会处理两类异常：AuthenticationException和AccessDeniedException，其它的异常它会继续抛出

认证流程

用户提交用户名、密码被SecurityFilterChain中的UsernamePasswordAuthenticationFilter过滤器获取到，封装为请求Authentication，通常情况下是UsernamePasswordAuthenticationToken这个实现类；
然后过滤器将Authentication提交至认证管理器AuthenticationManager进行认证；
认证成功后，AuthenticationManager认证管理器返回一个被填充满了信息（包括上面提到的权限信息，身份信息，细节信息，但密码通常会被移除）的Authentication实例。
SecurityContextHolder安全上下文容器将第3步填充了信息的Authentication，通过SecurityContextHolder.getContext().setAuthentication(…)方法，设置到其中。

可以看出AuthenticationManager接口（认证管理器）是认证相关的核心接口，也是发起认证的出发点，它的实现类为ProviderManager。而Spring Security支持多种认证方式，因此ProviderManager维护着一个List<AuthenticationProvider> 列表，存放多种认证方式，最终实际的认证工作是由AuthenticationProvider完成的。例如web表单的对应的AuthenticationProvider实现类为DaoAuthenticationProvider，它的内部又维护着一个UserDetailsService负责UserDetails的获取。最终AuthenticationProvider将UserDetails填充至Authentication。

认证核心组件的大体关系如下：

AuthenticationProvider

认证管理器（AuthenticationManager）委托AuthenticationProvider完成认证工作。AuthenticationProvider是一个接口，定义如下：

public interface AuthenticationProvider {
    Authentication authenticate(Authentication var1) throws AuthenticationException;
    boolean supports(Class<?> var1);
}

authenticate()方法定义了认证的实现过程，它的参数是一个Authentication，里面包含了登录用户所提交的用户、密码等。而返回值也是一个Authentication，这个Authentication则是在认证成功后，将用户的权限及其他信息重新组装后生成。

Spring Security中维护着一个List<AuthenticationProvider>列表，存放多种认证方式，不同的认证方式使用不同的AuthenticationProvider。如使用用户名密码登录时，使用AuthenticationProvider1，短信登录时使用AuthenticationProvider2等等这样的例子很多。

每个AuthenticationProvider需要实现supports()方法来表明自己支持的认证方式，如我们使用表单方式认证，在提交请求时Spring Security会生成UsernamePasswordAuthenticationToken，它是一个Authentication，里面封装着用户提交的用户名、密码信息。那么对应的，哪个AuthenticationProvider会来处理它？

我们在DaoAuthenticationProvider的基类AbstractUserDetailsAuthenticationProvider发现以下代码：

public boolean supports(Class<?> authentication) {
    return UsernamePasswordAuthenticationToken.class.isAssignableFrom(authentication);
}

也就是说当web表单提交用户名密码时，将由DaoAuthenticationProvider处理认证。

最后，我们来看一下Authentication(认证信息)的结构，它是一个接口，我们之前提到的UsernamePasswordAuthenticationToken就是它的实现之一：

//Authentication是spring security包中的接口，直接继承自Principal类，而Principal是位于 java.security 包中的。
//它是表示着一个抽象主体身份，任何主体都有一个名称，因此包含一个getName()方法。
public interface Authentication extends Principal, Serializable {
    //权限信息列表，默认是GrantedAuthority接口的一些实现类，通常是代表权限信息的一系列字符串。
    Collection<? extends GrantedAuthority> getAuthorities();

    //凭证信息，用户输入的密码字符串，在认证过后通常会被移除，用于保障安全
    Object getCredentials();

    //细节信息，web应用中的实现接口通常为 WebAuthenticationDetails，它记录了访问者的ip地址和sessionId的值
    Object getDetails();

    //身份信息，大部分情况下返回的是UserDetails接口的实现类，UserDetails代表用户的详细信息，
    //那从Authentication中取出来的UserDetails就是当前登录用户信息，它也是框架中的常用接口之一
    Object getPrincipal();

    boolean isAuthenticated();

    void setAuthenticated(boolean var1) throws IllegalArgumentException;
}

UserDetailsService

我们已经知道DaoAuthenticationProvider处理web表单的认证逻辑，认证成功后即得到一个Authentication(UsernamePasswordAuthenticationToken实现)，里面包含了身份信息（Principal）。这个身份信息就是一个Object ，大多数情况下它可以被强转为UserDetails对象。 DaoAuthenticationProvider中包含了一个UserDetailsService实例，它负责根据用户名提取用户信息UserDetails(包含密码)，而后DaoAuthenticationProvider会去对比UserDetailsService提取的用户密码与用户提交的密码是否匹配作为认证成功的关键依据，因此可以通过将自定义的UserDetailsService公开为spring bean来定义自定义身份验证。

public interface UserDetailsService {
    UserDetails loadUserByUsername(String var1) throws UsernameNotFoundException;
}

很多人可能会把DaoAuthenticationProvider和UserDetailsService的职责搞混淆，其实UserDetailsService只负责从特定的地方（通常是数据库）加载用户信息，仅此而已。而DaoAuthenticationProvider的职责更大，它完成完整的认证流程，同时会把UserDetails填充至Authentication。

UserDetails是用户信息，它的接口定义如下：

public interface UserDetails extends Serializable {
    Collection<? extends GrantedAuthority> getAuthorities();

    String getPassword();

    String getUsername();

    boolean isAccountNonExpired();

    boolean isAccountNonLocked();

    boolean isCredentialsNonExpired();

    boolean isEnabled();
}

它和Authentication接口很类似，比如它们都拥有username，authorities。Authentication的getCredentials()与UserDetails中的getPassword()需要被区分对待，前者是用户提交的密码凭证，后者是用户实际存储的密码，认证其实就是对这两者的比对。Authentication中的getAuthorities()实际是由UserDetails的getAuthorities()传递而形成的。还记得Authentication接口中的getDetails()方法吗？其中的UserDetails用户详细信息便是经过了AuthenticationProvider认证之后被填充的。

通过实现UserDetailsService和UserDetails，我们可以完成对用户信息获取方式以及用户信息字段的扩展。 Spring Security提供的InMemoryUserDetailsManager(内存认证)，JdbcUserDetailsManager(jdbc认证)就是UserDetailsService的实现类，主要区别无非就是从内存还是从数据库加载用户。

创建一个自定义UserDetailsService的实现类SpringDataUserDetailsService：

@Service
public class SpringDataUserDetailsService implements UserDetailsService {
    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        //登录账号
        System.out.println("username=" + username);
        // 根据账号去数据库查询...
        // 这里暂时使用静态数据
        UserDetails userDetails = User.withUsername(username).password("123").authorities("p1").build();
        return userDetails;
    }
}

屏蔽掉原先安全配置类WebSecurityConfig中UserDetailsService的定义：

 //定义用户信息服务（查询用户信息）
/* @Bean
 public UserDetailsService userDetailsService(){
     InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
     manager.createUser(User.withUsername("zhangsan").password("123").authorities("p1").build());
     manager.createUser(User.withUsername("lisi").password("456").authorities("p2").build());
     return manager;
 }*/

启动工程，测试登录，SpringDataUserDetailsService的loadUserByUsername方法被调用，查询用户信息。

PasswordEncoder

DaoAuthenticationProvider认证处理器通过UserDetailsService获取到UserDetails后，它是如何与请求Authentication中的密码做对比呢？在这里Spring Security为了适应多种多样的加密类型又做了抽象，DaoAuthenticationProvider通过PasswordEncoder接口的matches方法进行密码的对比，而具体的密码对比细节取决于实现：

public interface PasswordEncoder {
    String encode(CharSequence var1);

    boolean matches(CharSequence var1, String var2);

    default boolean upgradeEncoding(String encodedPassword) {
        return false;
    }
}

Spring Security提供很多内置的PasswordEncoder，能够开箱即用，使用某种PasswordEncoder只需要进行如下声明即可，如下：

@Bean
public PasswordEncoder passwordEncoder(){
    return NoOpPasswordEncoder.getInstance();
}

NoOpPasswordEncoder采用字符串匹配方法，不对密码进行加密比较处理，密码比较流程如下：

用户输入密码（明文）
DaoAuthenticationProvider获取UserDetails（其中存储了用户的正确密码）
DaoAuthenticationProvider使用PasswordEncoder对输入的密码和正确的密码进行校验，密码一致则校验通过，否则校验失败

实际项目中推荐使用BCryptPasswordEncoder, Pbkdf2PasswordEncoder, SCryptPasswordEncoder等，感兴趣的大家可以看看这些PasswordEncoder的具体实现。

以使用BCryptPasswordEncoder为例，修改安全配置类WebSecurityConfig的密码编码器：

//密码编码器
@Bean
public PasswordEncoder passwordEncoder(){
    //return NoOpPasswordEncoder.getInstance();
    return new BCryptPasswordEncoder();
}

添加测试类，对登录密码进行加密

添加SpringBoot测试依赖：

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

编写测试方法：

@RunWith(SpringRunner.class)
public class TestBCrypt {
    @Test
    public void test1() {
        //对原始密码加密
        String hashpw = BCrypt.hashpw("123", BCrypt.gensalt());
        System.out.println(hashpw);
        //校验原始密码和BCrypt密码是否一致
        boolean checkpw = BCrypt.checkpw("123", "$2a$10$NlBC84MVb7F95EXYTXwLneXgCca6/GipyWR5NHm8K0203bSQMLpvm");
        System.out.println(checkpw);
    }
}

修改安全配置类WebSecurityConfig，将UserDetails中的原始密码修改为BCrypt格式：

manager.createUser(User.withUsername("zhangsan").password("$2a$10$1b5mIkehqv5c4KRrX9bUj.A4Y2hug3I GCnMCL5i4RpQrYV12xNKye").authorities("p1").build());

实际项目中存储在数据库中的密码并不是原始密码，都是经过加密处理的密码。

授权流程

通过前面快速上手的例子我们知道，Spring Security可以通过http.authorizeRequests()对web请求进行授权保护。Spring Security使用标准Filter建立了对web请求的拦截，最终实现对资源的授权访问。Spring Security的授权流程如下：

拦截请求，已认证用户访问受保护的web资源将被SecurityFilterChain中的FilterSecurityInterceptor的子类拦截；

获取资源访问策略，FilterSecurityInterceptor会从SecurityMetadataSource的子类DefaultFilterInvocationSecurityMetadataSource获取要访问当前资源所需要的权限Collection<ConfigAttribute>。SecurityMetadataSource其实就是读取访问策略的抽象，而读取的内容，其实就是我们配置的访问规则，读取访问策略如

http.authorizeRequests()
               .antMatchers("/r/r1").hasAuthority("p1")
               .antMatchers("/r/r2").hasAuthority("p2")
               ...

授权决策，最后，FilterSecurityInterceptor会调用AccessDecisionManager进行授权决策，若决策通过，则允许访问资源，否则将禁止访问。

AccessDecisionManager（访问决策管理器）的核心接口如下:

public interface AccessDecisionManager { 
    /** * 通过传递的参数来决定用户是否有访问对应受保护资源的权限 */
    void decide(Authentication authentication , Object object, Collection<ConfigAttribute> 
                configAttributes) throws AccessDeniedException, InsufficientAuthenticationException; 
    //略.. 
}

这里着重说明一下decide的参数：

authentication：要访问资源的访问者的身份
object：要访问的受保护资源，web请求对应FilterInvocation
configAttributes：是受保护资源的访问策略，通过SecurityMetadataSource获取。

decide接口就是用来鉴定当前用户是否有访问对应受保护资源的权限。

授权决策

AccessDecisionManager采用投票的方式来确定是否能够访问受保护资源。

通过上图可以看出，AccessDecisionManager中包含的一系列AccessDecisionVoter将会被用来对Authentication是否有权访问受保护对象进行投票，AccessDecisionManager根据投票结果，做出最终决策。

AccessDecisionVoter是一个接口，其中定义有三个方法，具体结构如下所示：

public interface AccessDecisionVoter<S> {
    int ACCESS_GRANTED = 1;
    int ACCESS_ABSTAIN = 0;
    int ACCESS_DENIED = -1;

    boolean supports(ConfigAttribute var1);

    boolean supports(Class<?> var1);

    int vote(Authentication var1, S var2, Collection<ConfigAttribute> var3);
}

vote()方法的返回结果会是AccessDecisionVoter中定义的三个常量之一。ACCESS_GRANTED表示同意，ACCESS_DENIED表示拒绝，ACCESS_ABSTAIN表示弃权。如果一个AccessDecisionVoter不能判定当前Authentication是否拥有访问对应受保护对象的权限，则其vote()方法的返回值应当为弃权ACCESS_ABSTAIN。

Spring Security内置了三个基于投票的AccessDecisionManager实现类：

AffirmativeBased的逻辑是：

只要有AccessDecisionVoter的投票为ACCESS_GRANTED则同意用户进行访问；
如果全部弃权也表示通过；
如果没有一个人投赞成票，但是有人投反对票，则将抛出AccessDeniedException。

Spring security默认使用的是AffirmativeBased。

ConsensusBased的逻辑是：

如果赞成票多于反对票则表示通过；
反过来，如果反对票多于赞成票则将抛出AccessDeniedException；
如果赞成票与反对票相同且不等于0，并且属性allowIfEqualGrantedDeniedDecisions的值为true，则表示通过，否则将抛出异常AccessDeniedException。参数allowIfEqualGrantedDeniedDecisions的值默认为true；
如果所有的AccessDecisionVoter都弃权了，则将视参数allowIfAllAbstainDecisions的值而定，如果该值为true则表示通过，否则将抛出异常AccessDeniedException。参数allowIfAllAbstainDecisions的值默认为false。

UnanimousBased的逻辑与另外两种实现有点不一样，另外两种会一次性把受保护对象的配置属性全部传递给AccessDecisionVoter进行投票，而UnanimousBased会一次只传递一个ConfigAttribute给AccessDecisionVoter进行投票。这也就意味着如果我们的AccessDecisionVoter的逻辑是只要传递进来的ConfigAttribute中有一个能够匹配则投赞成票，但是放到UnanimousBased中其投票结果就不一定是赞成了。UnanimousBased的逻辑具体来说是这样的：

如果受保护对象配置的某一个ConfigAttribute被任意的AccessDecisionVoter反对了，则将抛出AccessDeniedException；
如果没有反对票，但是有赞成票，则表示通过；
如果全部弃权了，则将视参数allowIfAllAbstainDecisions的值而定，true则通过，false则抛出AccessDeniedException。

Spring Security也内置一些投票者实现类如RoleVoter、AuthenticatedVoter和WebExpressionVoter等。

自定义认证

Spring Security提供了非常好的认证扩展方法，比如快速上手中将用户信息存储到内存中，实际开发中用户信息通常在数据库，Spring security可以实现从数据库读取用户信息，Spring Security还支持多种授权方法。

自定义登录页面

在快速上手中，你可能会想知道登录页面从哪里来的？因为我们并没有提供任何的HTML或JSP文件。Spring Security的默认配置没有明确设定一个登录页面的URL，因此Spring Security会根据启用的功能自动生成一个登录页面URL，并使用默认URL处理登录的提交内容，登录后跳转的到默认URL等等。尽管自动生成的登录页面很方便快速启动和运行，但大多数应用程序都希望定义自己的登录页面。

在快速上手工程security-spring-boot中创建登录页面login.jsp，目录结构如下：

由于是在SpringBoot项目中创建jsp文件，需在项目属性中配置web资源文件夹路径，这里指向我们刚刚创建的webapp文件夹：

<%@ page contentType="text/html;charset=UTF-8" pageEncoding="utf-8" %>
<html>
<head>
    <title>用户登录</title>
</head>
<body>
<form action="login" method="post">
    用户名：<input type="text" name="username"><br>
    密&nbsp;&nbsp;&nbsp;码:
    <input type="password" name="password"><br>
    <input type="submit" value="登录">
</form>
</body>
</html>

添加jsp依赖，修改porm.xml文件：

<!--用于编译jsp -->
<dependency>
    <groupId>org.apache.tomcat.embed</groupId>
    <artifactId>tomcat-embed-jasper</artifactId>
</dependency>
<!--jsp页面使用jstl标签 -->
<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>jstl</artifactId>
</dependency>

在application.properties文件中添加如下信息：

spring.mvc.view.prefix=/WEB-INF/view/
spring.mvc.view.suffix=.jsp

在WebConfig.java中配置认证页面地址：

public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/").setViewName("redirect:/login‐view");
        registry.addViewController("/login‐view").setViewName("login");
    }
}

在安全配置WebSecurityConfig中配置表单登录信息：

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            .antMatchers("/r/**").authenticated()//所有/r/**的请求必须认证通过
            .anyRequest().permitAll()//除了/r/**，其它的请求可以访问
            .and()
            .formLogin()//允许表单登录
            .loginPage("/login-view")//指定我们自己的登录页,spring security以重定向方式跳转到/login-view
            .loginProcessingUrl("/login")//指定登录处理的URL，也就是用户名、密码表单提交的目的路径，此URL由Spring Security提供
            .successForwardUrl("/login-success");//指定登录成功后的跳转URL，自定义登录成功的页面地址
}

测试：当用户没有认证时访问系统的资源会重定向到login-view页面

输入账号和密码，点击登录，报错：

问题原因：

spring security为防止CSRF（Cross-site request forgery跨站请求伪造）的发生，限制了除了get以外的大多数方法。

解决方法1：

屏蔽CSRF控制，即spring security不再限制CSRF。配置WebSecurityConfig：

@Override
   protected void configure(HttpSecurity http) throws Exception {
       http.csrf().disable()  //屏蔽CSRF控制，即spring security不再限制CSRF
               ...
   }

解决方法2：

在login.jsp页面添加一个token，spring security会验证token，如果token合法则可以继续请求。修改login.jsp：

<form action="login" method="post"> 
    <input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>
    ... 
</form>

本案例我们采用解决方案1。

连接数据库认证

前边的例子我们是将用户信息存储在内存中，实际项目中用户信息存储在数据库中，根据前边对认证流程研究，只需要重新定义UserDetailService即可实现根据用户账号查询数据库。

创建数据库

//创建user_db数据库
CREATE DATABASE `user_db` CHARACTER SET 'utf8' COLLATE 'utf8_general_ci';
//创建t_user表
CREATE TABLE `t_user` ( 
    `id` bigint(20) NOT NULL COMMENT '用户id', 
    `username` varchar(64) NOT NULL, 
    `password` varchar(64) NOT NULL, 
    `fullname` varchar(255) NOT NULL COMMENT '用户姓名', 
    `mobile` varchar(11) DEFAULT NULL COMMENT '手机号', 
    PRIMARY KEY (`id`) USING BTREE 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC

代码实现

在application.properties配置mysql连接信息：

spring.datasource.url=jdbc:mysql://localhost:3306/user_db 
spring.datasource.username=root 
spring.datasource.password=mysql 
spring.datasource.driver‐class‐name=com.mysql.jdbc.Driver

添加数据库访问依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.47</version>
</dependency>

定义模型类型，在model包定义UserDto：

@Data
public class UserDto {
    private String id;
    private String username;
    private String password;
    private String fullname;
    private String mobile;
}

在Dao包定义UserDao：

@Repository
public class UserDao {
    @Autowired
    JdbcTemplate jdbcTemplate;

    public UserDto getUserByUsername(String username) {
        String sql = "select id,username,password,fullname from t_user where username = ?";
        List<UserDto> list = jdbcTemplate.query(sql, new Object[]{username}, new BeanPropertyRowMapper<>(UserDto.class));
        if (list.size() <= 0) {
            return null;
        }
        return list.get(0);
    }
}

在service包下定义SpringDataUserDetailsService：

@Service
public class SpringDataUserDetailsService implements UserDetailsService {
    @Autowired
    private UserDao userDao;

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        //登录账号
        System.out.println("username=" + username);
        // 根据账号去数据库查询...
        UserDto user = userDao.getUserByUsername(username);
        if (user == null)
            return null;
        UserDetails userDetails = User.withUsername(user.getUsername()).password(user.getPassword()).authorities("p1").build();
        return userDetails;
    }
}

注意：如果我们采用的是BCryptPasswordEncoder的密码编码器，数据库中也应该存储的是用此加密的密码。

会话

用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保存在会话中。spring security提供会话管理，认证通过后将身份信息放入SecurityContextHolder上下文，SecurityContext与当前线程进行绑定，方便获取用户身份。

获取用户身份

Spring Security获取当前登录用户信息的方法为SecurityContextHolder.getContext().getAuthentication()，我们可以在LoginController中定义一个getUsername方法：

/*** 获取当前登录用户名
 * @return
 */
private String getUsername() {
    Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
    if (!authentication.isAuthenticated()) {
        return null;
    }
    Object principal = authentication.getPrincipal();
    String username = null;
    if (principal instanceof org.springframework.security.core.userdetails.UserDetails) {
        username = ((org.springframework.security.core.userdetails.UserDetails) principal).getUsername();
    } else {
        username = principal.toString();
    }
    return username;
}

会话控制

我们可以通过以下选项准确控制会话何时创建以及Spring Security如何与之交互：

通过修改安全配置类WebSecurityConfig对该选项进行配置：

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED);
}

默认情况下，Spring Security会为每个登录成功的用户会新建一个Session，就是ifRequired。

若选用never，则指示Spring Security对登录成功的用户不创建Session了，但若你的应用程序在某地方新建了session，那么Spring Security会用它的。

若使用stateless，则说明Spring Security对登录成功的用户不会创建Session了，你的应用程序也不会允许新建session，并且它会暗示不使用cookie，所以每个请求都需要重新进行身份验证。这种无状态架构适用于REST API及其无状态认证机制。

会话超时

可以再sevlet容器中设置Session的超时时间，比如设置Session有效期为3600秒，修改spring boot配置文件：

server.servlet.session.timeout=3600s

session超时之后，可以通过Spring Security设置跳转的路径：

http.sessionManagement().invalidSessionUrl("/login‐view?error=INVALID_SESSION").maximumSessions(1)
                .expiredUrl("/login‐view?error=EXPIRED_SESSION");

invalidSession指传入的sessionid无效，expired指session过期，maximumSessions指最大session并发数，比如当有2个admin账号登录时，前一个登录的admin账号session会失效。

安全会话cookie

我们可以使用httpOnly和secure标签来保护我们的会话cookie，修改spring boot配置文件：

server.servlet.session.cookie.http‐only=true //如果为true，那么浏览器脚本将无法访问cookie 
server.servlet.session.cookie.secure=true //如果为true，则cookie将仅通过HTTPS连接发送

退出

前面说过spring security默认实现了logout退出页面，我们也可以自定义退出成功的页面，以及退出登录的行为。

http.csrf().disable()
                .authorizeRequests()
				...
                .and()
                .logout()               //提供系统退出支持，使用 WebSecurityConfigurerAdapter 会自动被应用
                .logoutUrl("/logout")   //设置触发退出操作的URL (默认是 /logout )
                .logoutSuccessUrl("/login‐view?logout")        //退出之后跳转的URL。默认是 /login?logout
                .logoutSuccessHandler(logoutSuccessHandler)    //定制的 LogoutSuccessHandler，用于实现用户退出成功时的处理。如果指定了这个选项那么 logoutSuccessUrl() 的设置会被忽略
                .addLogoutHandler(logoutHandler)    //添加一个 LogoutHandler ，用于实现用户退出时的清理工作.默认 SecurityContextLogoutHandler 会被添加为最后一个 LogoutHandler
                .invalidateHttpSession(true);       //指定是否在退出时让 HttpSession 无效。 默认设置为 true

当退出操作出发时，将发生：

使HTTP Session无效
清除 SecurityContextHolder
跳转到/login-view?logout

注意：如果让logout在GET请求下生效，必须关闭防止CSRF攻击csrf().disable()。如果开启了CSRF必须使用post方式请求logout。

logoutHandler

一般来说，LogoutHandler的实现类被用来执行必要的清理，因而他们不应该抛出异常。

下面是Spring Security提供的一些实现：

PersistentTokenBasedRememberMeServices 基于持久化token的RememberMe功能的相关清理
TokenBasedRememberMeService 基于token的RememberMe功能的相关清理
CookieClearingLogoutHandler 退出时Cookie的相关清理
CsrfLogoutHandler 负责在退出时移除csrfToken
SecurityContextLogoutHandler 退出时SecurityContext的相关清理

授权

授权的方式包括 web授权和方法授权，web授权是通过url拦截进行授权，方法授权是通过方法拦截进行授权。它们都会调用accessDecisionManager进行授权决策，若为web授权则拦截器为FilterSecurityInterceptor；若为方法授权则拦截器为MethodSecurityInterceptor。如果同时通过web授权和方法授权则先执行web授权，再执行方法授权，最后决策通过，则允许访问资源，否则将禁止访问。类关系如下：

环境配置

在我们之前创建的user_db数据库中执行如下脚本：

//创建角色表
CREATE TABLE `t_role` ( 
    `id` varchar(32) NOT NULL, 
    `role_name` varchar(255) DEFAULT NULL, 
    `description` varchar(255) DEFAULT NULL, 
    `create_time` datetime DEFAULT NULL, 
    `update_time` datetime DEFAULT NULL, 
    `status` char(1) NOT NULL, 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `unique_role_name` (`role_name`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 
insert into `t_role`(`id`,`role_name`,`description`,`create_time`,`update_time`,`status`) 
values ('1','管理员',NULL,NULL,NULL,'');

//创建用户角色关联表
CREATE TABLE `t_user_role` ( 
    `user_id` varchar(32) NOT NULL, 
    `role_id` varchar(32) NOT NULL, 
    `create_time` datetime DEFAULT NULL, 
    `creator` varchar(255) DEFAULT NULL, 
    PRIMARY KEY (`user_id`,`role_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 
insert into `t_user_role`(`user_id`,`role_id`,`create_time`,`creator`) 
values ('1','1',NULL,NULL);

//创建权限表
CREATE TABLE `t_permission` ( 
    `id` varchar(32) NOT NULL, 
    `code` varchar(32) NOT NULL COMMENT '权限标识符', 
    `description` varchar(64) DEFAULT NULL COMMENT '描述', 
    `url` varchar(128) DEFAULT NULL COMMENT '请求地址', 
    PRIMARY KEY (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 
insert into `t_permission`(`id`,`code`,`description`,`url`) 
values ('1','p1','测试资源 1','/r/r1'),('2','p3','测试资源2','/r/r2');

//角色权限关联表
CREATE TABLE `t_role_permission` ( 
    `role_id` varchar(32) NOT NULL, 
    `permission_id` varchar(32) NOT NULL, 
    PRIMARY KEY (`role_id`,`permission_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 
insert into `t_role_permission`(`role_id`,`permission_id`) values ('1','1'),('1','2');

在UserDao中添加根据用户id查询用户权限方法：

//根据用户id查询用户权限
public List<String> findPermissionsByUserId(String userId) {
    String sql = "SELECT * FROM t_permission WHERE id IN(\n" +
            "SELECT permission_id FROM t_role_permission WHERE role_id IN(\n" +
            "\tSELECT role_id FROM t_user_role WHERE user_id = ? \n" +
            ")\n" +
            ")";
    List<PermissionDto> list = jdbcTemplate.query(sql, new Object[]{userId}, new BeanPropertyRowMapper<>(PermissionDto.class));
    List<String> permissions = new ArrayList<>();
    list.iterator().forEachRemaining(c-> permissions.add(c.getCode()));
    return permissions;
}

修改UserDetailService，实现从数据库读取权限：

@Override
public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
    //登录账号
    System.out.println("username=" + username);
    // 根据账号去数据库查询...
    UserDto user = userDao.getUserByUsername(username);
    if (user == null)
        return null;
    //查询用户权限
    List<String> permissions = userDao.findPermissionsByUserId(user.getId());
    String[] perarray = new String[permissions.size()];
    permissions.toArray(perarray);
    UserDetails userDetails = User.withUsername(user.getUsername()).password(user.getPassword()).authorities(perarray).build();
    return userDetails;
}

Web授权

前面例子中我们已经完成了对URL的认证拦截，我们可以通过给http.authorizeRequests()添加多个子节点实现灵活的授权控制，以定制需求到我们的URL。

http.authorizeRequests()         //http.authorizeRequests()方法有多个子节点，每个macher按照他们的声明顺序执行
    .antMatchers("/r/r1").hasAuthority("p1")   //指定"/r/r1"URL，拥有p1权限能够访问
    .antMatchers("/r/r2").hasAuthority("p2")   //指定"/r/r2"URL，拥有p2权限能够访问
    .antMatchers("/r/r3").access("hasAuthority('p1') and hasAuthority('p2')")  //指定了"/r/r3"URL，同时拥有p1和p2权限才能够访问，这里使用SpEL（Spring Expression Language）表达式
    .antMatchers("/r/**").authenticated()  //指定了除了r1、r2、r3之外的"/r/**"资源，只要通过身份认证就能够访问
    .anyRequest().permitAll()         //剩余的尚未匹配的资源，不做保护

保护URL常用的方法有：

authenticated() 保护URL，需要用户登录
permitAll() 指定URL无需保护，一般应用与静态资源文件
hasRole(String role) 限制单个角色访问，角色将被增加 “ROLE_” .所以”ADMIN” 将和 “ROLE_ADMIN”进行比较.
hasAuthority(String authority) 限制单个权限访问
hasAnyRole(String… roles)允许多个角色访问
hasAnyAuthority(String… authorities) 允许多个权限访问
access(String attribute) 该方法使用 SpEL表达式, 所以可以创建复杂的限制
hasIpAddress(String ipaddressExpression) 限制IP地址或子网

注意：规则的顺序是重要的，更具体的规则应该先写。因为一旦前面的规则匹配上，后面的规则会忽略。比如如果将.antMatchers("/r/**").authenticated()放置到最前面的话，那么资源r1、r2、r3因满足/r/**的匹配条件，不会再去验证权限。

方法授权

我们已经知道如何使用http.authorizeRequests()对web资源进行授权保护，从Spring Security2.0版本开始，它支持服务层方法的安全性的支持，通过@PreAuthorize,@PostAuthorize, @Secured这三类注解实现方法授权。

我们可以在任何@Configuration实例上使用@EnableGlobalMethodSecurity注释来启用基于注解的安全性。如以下内容将启用Spring Security的@Secured注解：

@EnableGlobalMethodSecurity(securedEnabled = true)
@Configuration
public class MethodSecurityConfig {// ...}

然后向方法（在类或接口上）添加注解就会限制对该方法的访问。Spring Security的原生注释支持为该方法定义了一组属性，这些将被传递给AccessDecisionManager以供它作出实际的决定：

public interface BankService { 
    @Secured("IS_AUTHENTICATED_ANONYMOUSLY")
    public Account readAccount(Long id); 

    @Secured("IS_AUTHENTICATED_ANONYMOUSLY")
    public Account[] findAccounts(); 
    
    @Secured("ROLE_TELLER")
    public Account post(Account account, double amount); 
}

以上配置标明readAccount、findAccounts方法可匿名访问，底层使用WebExpressionVoter投票器，post方法需要有TELLER角色才能访问，底层使用RoleVoter投票器。

@PreAuthorize和@PostAuthorize声明权限的格式一样，区别是前者在方法执行之前拦截，后者在方法执行之后拦截。使用如下代码可启用prePost注解的支持：

@EnableGlobalMethodSecurity(prePostEnabled = true) 
@Configuration
public class MethodSecurityConfig {// ...}

相应Java代码如下：

public interface BankService { 
    @PreAuthorize("isAnonymous()") 
    public Account readAccount(Long id); 
    
    @PreAuthorize("isAnonymous()") 
    public Account[] findAccounts();
    
    @PreAuthorize("hasAuthority('p_transfer') and hasAuthority('p_read_account')") 
    public Account post(Account account, double amount);
}

以上配置标明readAccount、findAccounts方法可匿名访问，post方法需要同时拥有p_transfer和p_read_account权限才能访问，底层使用WebExpressionVoter投票器。

使用注解后，可以移除安全配置中的http.authorizeRequests()设置访问控制的代码，如果方法不包含授权注解，则方法可以不受限制的访问。

小杨敲代码

关注

26
点赞
踩
32

收藏

觉得还不错? 一键收藏
1
评论
Spring Security的认证和授权

Spring Security是为基于Spring的应用程序提供声明式安全保护的安全性框架。Spring Security提供了完整的安全性解决方案，它能够在Web请求级别和方法调用级别处理身份认证和授权。因为基于Spring框架，所以Spring Security充分利用了依赖注入（dependency injection，DI）和面向切面（AOP）的技术。Spring Security是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。
复制链接

扫一扫