3.Spring Security

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

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

@Configuration
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    //定义用户信息服务（查询用户信息）
    @Bean
    public UserDetailsService userDetailsService(){
        InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
        manager.createUser(User.withUsername("zhangsan").password("$2a$10$aFsOFzujtPCnUCUKcozsHux0rQ/3faAHGFSVb9Y.B1ntpmEhjRtru").build());
        return manager;
    }

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


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

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

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 地址或子网

(3)默认根路径请求

@Configuration//就相当于springmvc.xml文件
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/").setViewName("redirect:/login");
    }
}

 退出地址：http://localhost:8080/security/logout

   /**
     * 测试资源1
     * @return
     */
    @GetMapping(value = "/r/r1",produces = {"text/plain;charset=UTF-8"})
    @PreAuthorize("hasAuthority('p1')")//拥有p1权限才可以访问
    public String r1(){
        return "访问资源1";
    }

    /**
     * 测试资源2
     * @return
     */
    @GetMapping(value = "/r/r2",produces = {"text/plain;charset=UTF-8"})
    @PreAuthorize("hasAuthority('p2')")//拥有p2权限才可以访问
    public String r2(){
        return "访问资源2";
    }

在安全配置类 WebSecurityConfifig.java 中配置授权规则：

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

4.2 工作原理

4.2.1 结构总览

Spring Security 所解决的问题就是 安全访问控制 ，而安全访问控制功能其实就是对所有进入系统的请求进行拦截， 校验每个请求是否能够访问它所期望的资源。根据前边知识的学习，可以通过 Filter 或 AOP 等技术来实现， Spring Security 对 Web 资源的保护是靠 Filter 实现的，所以从这个 Filter 来入手，逐步深入 Spring Security 原理。

当初始化 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 ，其它的异常它会继续抛出。

4.2.2. 认证流程

4.2.2.1 认证流程

让我们仔细分析认证过程：

1. 用户提交用户名、密码被 SecurityFilterChain 中的 UsernamePasswordAuthenticationFilter 过滤器获取到， 封装为请求 Authentication ，通常情况下是 UsernamePasswordAuthenticationToken 这个实现类。

2. 然后过滤器将 Authentication 提交至认证管理器（ AuthenticationManager ）进行认证

3. 认证成功后， AuthenticationManager 身份管理器返回一个被填充满了信息的（包括上面提到的权限信息， 身份信息，细节信息，但密码通常会被移除） Authentication 实例。

4. SecurityContextHolder 安全上下文容器将第 3 步填充了信息的 Authentication ，通过

SecurityContextHolder.getContext().setAuthentication(…) 方法，设置到其中。 可以看出 AuthenticationManager 接口（认证管理器）是认证相关的核心接口，也是发起认证的出发点，它 的实现类为 ProviderManager 。而 Spring Security 支持多种认证方式，因此 ProviderManager 维护着一个 List<AuthenticationProvider> 列表，存放多种认证方式，最终实际的认证工作是由

AuthenticationProvider 完成的。咱们知道 web 表单的对应的 AuthenticationProvider 实现类为

DaoAuthenticationProvider ，它的内部又维护着一个 UserDetailsService 负责 UserDetails 的获取。最终AuthenticationProvider 将 UserDetails 填充至 Authentication 。

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

4.3.2.2.AuthenticationProvider

通过前面的 Spring Security 认证流程 我们得知，认证管理器（ AuthenticationManager ）委托

AuthenticationProvider 完成认证工作。

AuthenticationProvider 是一个接口，定义如下：

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

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

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

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

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

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

UsernamePasswordAuthenticationToken 就是它的实现之一：

（ 1 ） Authentication 是 spring security 包中的接口，直接继承自 Principal 类，而 Principal 是位于 java.security包中的。它是表示着一个抽象主体身份，任何主体都有一个名称，因此包含一个 getName() 方法。

（ 2 ） getAuthorities() ，权限信息列表，默认是 GrantedAuthority 接口的一些实现类，通常是代表权限信息的一系 列字符串。

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

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

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

4.3.2.3.UserDetailsService

1 ）认识 UserDetailsService

现在咱们现在知道 DaoAuthenticationProvider 处理了 web 表单的认证逻辑，认证成功后既得到一个

Authentication(UsernamePasswordAuthenticationToken 实现 ) ，里面包含了身份信息（ Principal ）。这个身份 信息就是一个 Object ，大多数情况下它可以被强转为 UserDetails 对象。

DaoAuthenticationProvider 中包含了一个 UserDetailsService 实例，它负责根据用户名提取用户信息UserDetails( 包含密码 ) ，而后 DaoAuthenticationProvider 会去对比 UserDetailsService 提取的用户密码与用户提交 的密码是否匹配作为认证成功的关键依据，因此可以通过将自定义的 UserDetailsService 公开为 spring bean 来定 义自定义身份验证。

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

上面一直提到UserDetails是用户信息，咱们看一下它的真面目：

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

通过实现 UserDetailsService 和 UserDetails ，我们可以完成对用户信息获取方式以及用户信息字段的扩展。 Spring Security 提供的 InMemoryUserDetailsManager( 内存认证 ) ，

JdbcUserDetailsManager(jdbc 认证 ) 就是UserDetailsService 的实现类，主要区别无非就是从内存还是从数据库加载用户。

4.2.3. 授权流程

4.2.3.1 授权流程

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

Spring Security 的授权流程如下：

分析授权流程：

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

2. 获取资源访问策略 ， FilterSecurityInterceptor 会从 SecurityMetadataSource 的子类

DefaultFilterInvocationSecurityMetadataSource 获取要访问当前资源所需要的权限

Collection<ConfigAttribute> 。SecurityMetadataSource 其实就是读取访问策略的抽象，而读取的内容，其实就是我们配置的访问规则， 读 取访问策略如

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

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

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

authentication ：要访问资源的访问者的身份

object ：要访问的受保护资源， web 请求对应 FilterInvocation

confifigAttributes ：是受保护资源的访问策略，通过 SecurityMetadataSource 获取。

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

4.2.3.2 授权决策

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

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

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

 

vote()方法的返回结果会是AccessDecisionVoter中定义的三个常量之一。ACCESS_GRANTED表示同意，

ACCESS_DENIED 表示拒绝， ACCESS_ABSTAIN 表示弃权。如果一个 AccessDecisionVoter 不能判定当前

Authentication 是否拥有访问对应受保护对象的权限，则其 vote() 方法的返回值应当为弃权 ACCESS_ABSTAIN 。

Spring Security 内置了三个基于投票的 AccessDecisionManager 实现类如下，它们分别是

AffirmativeBased 、 ConsensusBased 和 UnanimousBased ，。

AffirmativeBased 的逻辑是：

（ 1 ）只要有 AccessDecisionVoter 的投票为 ACCESS_GRANTED 则同意用户进行访问；

（ 2 ）如果全部弃权也表示通过；

（ 3 ）如果没有一个人投赞成票，但是有人投反对票，则将抛出 AccessDeniedException 。

Spring security 默认使用的是 AffiffiffirmativeBased 。

ConsensusBased 的逻辑是：

（ 1 ）如果赞成票多于反对票则表示通过。

（ 2 ）反过来，如果反对票多于赞成票则将抛出 AccessDeniedException 。

（ 3 ）如果赞成票与反对票相同且不等于 0 ，并且属性 allowIfEqualGrantedDeniedDecisions 的值为 true ，则表

示通过，否则将抛出异常 AccessDeniedException 。参数 allowIfEqualGrantedDeniedDecisions 的值默认为 true 。

（ 4 ）如果所有的 AccessDecisionVoter 都弃权了，则将视参数 allowIfAllAbstainDecisions 的值而定，如果该值

为 true 则表示通过，否则将抛出异常 AccessDeniedException 。参数 allowIfAllAbstainDecisions 的值默认为 false 。

UnanimousBased 的逻辑与另外两种实现有点不一样，另外两种会一次性把受保护对象的配置属性全部传递给 AccessDecisionVoter 进行投票，而 UnanimousBased 会一次只传递一个 ConfifigAttribute 给 AccessDecisionVoter 进行投票。这也就意味着如果我们的 AccessDecisionVoter 的逻辑是只要传递进来的

ConfifigAttribute 中有一个能够匹配则投赞成票，但是放到 UnanimousBased 中其投票结果就不一定是赞成了。 UnanimousBased 的逻辑具体来说是这样的：

（ 1 ）如果受保护对象配置的某一个 ConfifigAttribute 被任意的 AccessDecisionVoter 反对了，则将抛出AccessDeniedException 。

（ 2 ）如果没有反对票，但是有赞成票，则表示通过。

（ 3 ）如果全部弃权了，则将视参数 allowIfAllAbstainDecisions 的值而定，

true 则通过，false 则抛出AccessDeniedException 。

4.4 会话

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

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

    //获取当前用户信息
    private String getUsername(){
        String username = null;
        //当前认证通过的用户身份
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        //用户身份
        Object principal = authentication.getPrincipal();
        if(principal == null){
            username = "匿名";
        }
        if(principal instanceof org.springframework.security.core.userdetails.UserDetails){
            UserDetails userDetails = (UserDetails) principal;
            username = userDetails.getUsername();
        }else{
            username = principal.toString();
        }
        return username;
    }

测试成功访问资源，如下：

4.4.2会话控制

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

 通过以下配置方式对该选项进行配置：

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

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

会话超时

可以再 sevlet 容器中设置 Session 的超时时间，如下设置 Session 有效期为 3600s ；

spring boot 配置文件：

server.servlet.session.timeout = 3600s

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

 expired指session过期，invalidSession指传入的sessionid无效。

安全会话 cookie

我们可以使用 httpOnly 和 secure 标签来保护我们的会话 cookie ：

• httpOnly：如果为true，那么浏览器脚本将无法访问cookie
• secure：如果为true，则cookie将仅通过HTTPS连接发送

spring boot 配置文件

server.servlet.session.cookie.http‐only = true

server.servlet.session.cookie.secure = true

4.6 退出

Spring security 默认实现了 logout 退出，访问 /logout ，果然不出所料，退出功能 Spring 也替我们做好了。

点击 “Log Out” 退出 成功。

退出后访问其它 url 判断是否成功退出。

这里也可以自定义退出成功的页面：

在 WebSecurityConfifig 的 protected void confifigure(HttpSecurity http) 中配置：

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

使 HTTP Session 无效

清除 SecurityContextHolder

跳转到 /login - view?logout

但是，类似于配置登录功能，咱们可以进一步自定义退出功能：

（ 1 ）提供系统退出支持，使用 WebSecurityConfigurerAdapter 会自动被应用

（ 2 ）设置触发退出操作的 URL ( 默认是 /logout ).

（ 3 ）退出之后跳转的 URL 。默认是 /login?logout 。

（ 4 ）定制的 LogoutSuccessHandler ，用于实现用户退出成功时的处理。如果指定了这个选项那么logoutSuccessUrl() 的设置会被忽略。

（ 5 ）添加一个 LogoutHandler ，用于实现用户退出时的清理工作 . 默认 SecurityContextLogoutHandler 会被添加 为最后一个 LogoutHandler 。

（ 6 ）指定是否在退出时让 HttpSession 无效。 默认设置为 true 。

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

logoutHandler ：

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

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

 链式API提供了调用相应的 LogoutHandler 实现的快捷方式，比如deleteCookies()。

4.5.web授权

在上面例子中我们完成了认证拦截，并对 /r/** 下的某些资源进行简单的授权保护，但是我们想进行灵活的授权控 制该怎么做呢？通过给 http.authorizeRequests() 添加多个子节点来定制需求到我们的 URL ，如下代码：

（ 1 ） http.authorizeRequests() 方法有多个子节点，每个 macher 按照他们的声明顺序执行。

（ 2 ）指定 "/r/r1"URL ，拥有 p1 权限能够访问

（ 3 ）指定 "/r/r2"URL ，拥有 p2 权限能够访问

（ 4 ）指定了 "/r/r3"URL ，同时拥有 p1 和 p2 权限才能够访问

（ 5 ）指定了除了 r1 、 r2 、 r3 之外 "/r/**" 资源，同时通过身份认证就能够访问，这里使用 SpEL （ Spring Expression Language ）表达式。。

（ 6 ）剩余的尚未匹配的资源，不做保护

注意 ：

规则的顺序是重要的 , 更具体的规则应该先写 . 现在以 / admin 开始的所有内容都需要具有 ADMIN 角色的身份验证用户 , 即使是 / admin / login 路径 ( 因为 / admin / login 已经被 / admin / ** 规则匹配 , 因此第二个规则被忽略 ).

因此,登录页面的规则应该在/ admin / **规则之前.例如.

保护 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 地址或子网

4.6.方法授权

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

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

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

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

使用如下代码可启用 prePost 注解的支持

相应 Java 代码如下：

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