一、认证

    身份认证，就是判断一个用户是否为合法用户的处理过程。Spring Security 中支持多种不同方式的认证，但是无论开发者使用那种方式认证，都不会影响授权功能使用。因为 SpringSecurity 很好做到了认证和授权解耦。

 

二、授权

    授权，即访问控制，控制谁能访问哪些资源。简单的理解授权就是根据系统提前设置好的规则，给用户分配可以访问某一个资源的权限，用户根据自己所具有权限，去执行相应操作。

2.1权限管理核心概念

     我们得知认证成功之后会将当前登录用户信息保存到Authentication 对象中，Authentication 对象中有一个getAuthorities() 方法，用来返回当前登录用户具备的权限信息，也就是当前用户具有权限信息。该方法的返回值为 Collection<?extends GrantedAuthorit，当需要进行权限判断时，就回根据集合返回权限信息调用相应方法进行判断。

2.2 GrantedAuthority 解释

 

    那么问题来了，针对于这个返回值 GrantedAuthority 应该如何理解呢? 是角色还是权限?

我们针对于授权可以是 基于角色权限管理 和 基于资源权限管理 ，从设计层面上来说，角色和权限是两个完全不同的东西: 权限是一些具体操作，角色则是某些权限集合。如:READ_BOOK 和 ROLE_ADMIN 是完全不同的。因此至于返回值是什么取决于你的业务设计情况:。基于角色权限设计就是: 用户 => 角色 => 资源  三者关系 返回就是用户的 角色。基于资源权限设计就是:用户e=>双限<=>资源”三者关系 返回就是用户的 权限。基于角色和资源权限设计就是: 用户角色<>权限<>资源 返回统称为用户的 权限为什么可以统称为权限，因为从代码层面角色和权限没有太大不同都是权限，特别是在Spring Security中，角色和权限处理方式基本上都是一样的。唯一区别 SpringSecurity在很多时候会自动给角色添加一个 ROLE_前缀，而权限则不会自动添加。

 

2.3 权限管理策略

 

Spring Security 中提供的权限管理策略主要有两种类型:

1）、基于过滤器(URL)的权限管理(FilterSecurityinterceptor)

           基于过滤器的权限管理主要是用来拦截 HTTP 请求，拦截下来之后，根据 HTTP 请求地址进行权限校验。

2）、基于AOP 的权限管理 (MethodSecurityinterceptor)

        基于AOP 权限管理主要是用来处理方法级别的权限问题。当需要调用某一个方法时，通过AOP 将操作拦截下来，然后判断用户是否具备相关的权限。

2.3.1 基于URL 权限管理

  在配置中写死，/** 需要有xx角色或者权限才能访问

2.3.1.1 准备工作

 

 1）pom.xml 依赖包

 2）测试controller

 3）security 配置

我们在controller中创建了三个方法，分别为

/adminInf   这个url（可以匹配 /adminInf.   /adminInf/  /adminInf.htm 等等）需要拥有admin的角色才能访问

/rootInf  这个url 需要拥有root的角色才能访问

/getUser 这个url 需要拥有read:user的权限才能才能访问

2.3.1.2 security 配置

@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {


    /**
     *  定义自己的userDetail
     *
     */
    @Bean
    public UserDetailsService userDetailsService() {
        InMemoryUserDetailsManager im = new InMemoryUserDetailsManager();
        im.createUser(User.withUsername("admin").password("{noop}123").roles("admin","root").build());
        im.createUser(User.withUsername("root").password("{noop}123").roles("root").build());
        im.createUser(User.withUsername("test").password("{noop}123").authorities("read:user").build());
        return im;
    }

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(userDetailsService());
    }


    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
                .mvcMatchers("/adminInf").hasRole("admin") // /adminInf 这个url下面必须有 admin的角色才能访问
                .mvcMatchers("/rootInf").hasAnyRole("admin","root") // /rootInf 这个url下面 有 admin 或者root 角色均可以访问
                .mvcMatchers("/getUser").hasAnyAuthority("read:user") // /getUser 这个url 下面必须有 read:user 这个权限才能访问
                .anyRequest().authenticated()
                .and()
                .formLogin()// 开启form表单登录
                .and().csrf().disable();
    }
}

2.3.1.3 测试controller

@RestController
public class HelloController {


    @GetMapping("/getUser")
    public String getUser() {
        return "userinfo authority ok ";
    }


    @GetMapping("/adminInf")
    public String admin() {
        return "admin role ok ";
    }


    @GetMapping("/rootInf")
    public String root() {
        return "root role ok ";
    }
}

2.3.1.4 测试结果

         1）、当我们登录admin 的用户时候访问,因为getUser没有配置权限，所以不能访问

        2）、当我们登录test 的用户时候访问,因为rootinfo/ adminInfo没有配置角色，所以不能访问

 

 

2.3.1.5 基于多种匹配规则

 

MvcMatchersAuthorizedUrl 、mvcMatchers 基于mvc 的匹配规则

 /test     可以匹配  /test.   /test/   /test.h...   多种

 

org.springframework.security.config.annotation.web.AbstractRequestMatcherRegistry#antMatchers(java.lang.String...)

.antMatchers()  早期 4.0 之前使用，基于全路径匹配

 /test     只能匹配  /test  这个路径下的方法

 

从用法上来看两个使用基本没有区别，区别主要是在于匹配的路径上，mvc 可以匹配范围更广，ant 是全匹配

org.springframework.security.config.annotation.web.AbstractRequestMatcherRegistry#regexMatchers(java.lang.String...)  基于正则方案，当我们写一个正则表达式就可以

 

---

2.4 基于方法的权限管理

     基于方法的权限管理主要是通过AOP 来实现的，Spring Security 中通过

MethodSecuritvInterceptor 来提供相关的实现。不同在于Filter Security interceptor 只是在请

求之前进行前置处理，MethodSecuritvinterceptor 除了前置处理之外还可以进行后置处理。

前置处理就是在请求之前判断是否具备相应的权限，后置处理则是对方法的执行结果进行二

次过滤。前置处理和后置处理分别对应了不同的实现类。

2.4.1 开启注解支持

@EnableGlobalMethodSecurity

1）、perPostEnabled: 开启 Spring Security 提供的四个权限注解，@PostAuthorize

@PostFilter、@PreAuthorize 以及 @PreFilter。

2）、securedEnabled: 开启 Spring Security 提供的 @Secured 注解支持，该注解不支持权限表达式

3）、jsr250Enabled:开启JSR-250 提供的注解，主要是@DenyAll、@PermitAll、@RolesAll 同

样这些注解也不支持权限表达式

# 以上注解含义如下:

- @PostAuthorize: 在日标方法执行之后进行权限校验。

- @PostFiter: 在目标方法执行之后对方法的返回结果进行过滤。

- @PreAuthorize: 在目标方法执行之前进行权限校验。

- @PreFiter: 在日标方法执行之前对方法参数进行过滤

- @secured: 访问目标方法必须具各相应的角色

- @DenyA11: 拒绝所有访问。

- @PermitA1l: 允许所有访问。

- @RolesAllowed: 访问目标方法必须具备相应的角色

这些基于方法的权限管理相关的注解，一般来说只要设置 prePostEnabled=true 就够用了

 

2.4.2 权限表达式

 

 

2.4.3 角色权限实战

1） ：

    /**

     *  登录用户必须是  admin  而且角色必须是 ADMIN

     * @return

     */

    @PreAuthorize("hasRole('ADMIN') and authentication.name == 'admin'")

    @RequestMapping("hello")

    public String hello() {

        return "hello";

    }

---

2)、

    /**

     *  登录的用户名必须和传过来的用户名一致才能通过  spe 表达式

     * @param username

     * @return

     */

    @PreAuthorize("authentication.name == #username")

    @RequestMapping("username")

    public String username(String username) {

        return "hello:" + username;

}

---

3）、

    /**

     *  过滤 users 对象里面的属性  id % 2 的数据，保留 不能整除的

     *  users 必须是一个集合，否则没法过滤  filterObject 固定写法

     * @param users

     * @return

     */

    @PreFilter(value = "filterObject.id % 2 != 0",filterTarget = "users")

    @RequestMapping("users")

    public String addUser(@RequestBody List<SecurityUser> users) {

        System.out.println(users);

        try {

            String userStr = new ObjectMapper().writeValueAsString(users);

            return userStr;

        } catch (JsonProcessingException e) {

            e.printStackTrace();

        }

        return "null ";

}

---

4、    

   /**

     *  后置过滤   当请求过来的  id值为1的时候，那么就返回，否则就不返回

     * @param id

     * @return

     */

    @PostAuthorize(value = "returnObject.id ==1 ")

    @RequestMapping("getUserId")

    public SecurityUser getUserId(Integer id) {

       return new SecurityUser(id,"lq");

}

---

5）

   /** 

     *  保留  id % 2 ==0 的数据返回，用来对方法返回值进行过滤

     * @return

     */

    @PostFilter(value = "filterObject.id %2==0 ")

    @RequestMapping("getAllUser")

    public List<SecurityUser> getAllUser() {

        List<SecurityUser> userList = new ArrayList<>();

        IntStream.rangeClosed(0,10)

                .forEach(index -> userList.add(new SecurityUser(index,"lq-"+index)));

 

        return userList;

 

    }

jsr250 使用比较少的，因为功能比较单一

/**
 *  只能判断角色，而且需要自己加前缀  ROLE_     当前用户必须有 ADMIN 权限才能查看
 * @return
 */
@Secured({"ROLE_ADMIN"})
@RequestMapping(value = "getUser1")
public SecurityUser getUser1() {
    return new SecurityUser(1,"lisi");
}


/**
 *  判断用户有  ADMIN或者 ROOT 角色就可以访问
 * @return
 */
@Secured({"ROLE_ADMIN","ROLE_ROOT"})
@RequestMapping(value = "getUser2")
public SecurityUser getUser2() {
    return new SecurityUser(1,"王五");
}


/**
 *  所有的用户都可以访问
 * @return
 */
@PermitAll
@RequestMapping(value = "permitAll")
public String perAll() {
    return "permitAll ok ";
}


/**
 *  所有的用户都拒绝访问
 * @return
 */
@DenyAll
@RequestMapping(value = "denyAll")
public String denyAll() {
    return "denyAll ok ";
}



/**
 *  判断用户有  ADMIN或者 ROOT 角色就可以访问
 * @return
 */
@RolesAllowed({"ROLE_ADMIN","ROLE_ROOT"})
@RequestMapping(value = "rolesAllowed")
public String rolesAllowed() {
    return "rolesAllowed ok ";
}

---

 

 

三、授权原理分析

 

 3.1 AccessDecisionManager

(访问决策管理器)，用来决定此次访问是否被允许

 

3.2 AccessDecisionVoter

(访问决定投票器)，投票器会检查用户是否具备应有的角色，进而投出赞成、反对或者弃权票。

AccesDecisionVoter和AccessDecisionManager 都有众多的实现类,在 AccessDecisionManager 中会换个遍历 AccessDecisionVoter，进而决定是否允许用户访问，因而 AaccesDecisionVoter 和 AccessDecisionManager 两者的关系类似于 AuthenticationProvider 和ProviderManager 的关系。

 

3.3 ConfigAttribute

用来保存授权时的角色信息

   在 Spring Security 中，用户请求一个资源(通常是一个接口或者一个 Java 方法)需要的角色会被封装成一个 ConfigAttribute 对象，在configAttribute 中只有一个 getAttribute方法，该方法返回一个 Strng 字符串，就是角色的名称。一般来说，角色名称都带有一个 ROLE_前缀，投票器 AccessDecisionVoter 所做的事情，其实就是比较用户所具各的角色和请求某个资源所需的 ConfigAtuibute 之间的关系。

3.4 核心类 FilterSecurityInterceptor

 

3.4.1 源码

        

org.springframework.security.web.access.intercept.FilterSecurityInterceptor

        org.springframework.security.web.access.intercept.FilterSecurityInterceptor#invoke

                         org.springframework.security.access.intercept.AbstractSecurityInterceptor#beforeInvocation

                        org.springframework.security.web.access.intercept.DefaultFilterInvocationSecurityMetadataSource#getAttributes

org.                                springframework.security.access.intercept.AbstractSecurityInterceptor#attemptAuthorization

 

3.4.2  SecurityMetadataSource

后期可以实现这个类，自定义过滤规则，我们下一章讲解动态从数据库如何配置，以及重写这个类的实现        

 

---

 

四、我们自己的角色如何放进去

我们通过参考

org.springframework.security.core.userdetails.User 类中的roles方法

 

4.1 代码实现

 // 获取权限信息 todo:后期从数据库查询

List<String>perList=Arrays.asList("new:query", "news:delete"); 

#角色 我们将这两个角色加上前缀

List<String>roles=Arrays.asList("ADMIN","USER");

List<String>roleList=roles.stream().map(r ->"ROLE_"+ r).collect(Collectors.toList());

 perList.addAll(roleList);

 

LoginSessionUserInf loginSessionUserInf=new LoginSessionUserInf(tUserInf, perList);