如何实现高效的动态鉴权

 一、概述

Spring Security 是 Spring 框架内高度可定制化的安全框架，也是 Spring 应用的标准安全框架，提供了包括认证和鉴权在内的两大部分。其高度集成于 Spring 框架，无需引入第三方扩展模块，可以避  免大量的数据接口适配问题，大幅度减少开发成本和时间。

如下图所示，Spring Security 的认证鉴权过程实际上位于请求过滤器和拦截器中，在请求通过了所有的过滤器和拦截器之后才会进行 API 适配。换言之，定制 Spring Security 就是修改过滤链中的各种过滤器和拦截器。

认证过程是图中绿色的部分，Spring Security 提供了非常多的认证方式，如密码认证、预认证等；橙色的部分是动态鉴权部分，其内置的 Security Interceptor 会将请求委托给各个具体的 AccessDecisionManager 进行鉴权。

Spring Security 的整个数据流程

在 Spring Security 中，AccessDecisionManager 是以投票器为蓝本进行的鉴权：Manager 下面会有多个 AccessDecisionVoter，每个 Voter 将结果返回至 Manager，最后由 Manager 确定是否授予权限。

Manager 共有三类：

• AffirmativeBased 一票通过制（默认选项）

• UnanimousBased 一票反对制

• ConsensusBased 少数服从多数制

之所以会用投票器，一是方便添加和扩展 voters，二是量化鉴权结果简化框架实现。

二、鉴权模块构建

根据概述部分，我们可修改的地方有很多，例如 FilterSecurityInterceptor, AccessDecisionManager, AccessDecisionVoter。但是无论修改 Interceptor 还是 Manager 都非常花费时间，因此我们选择直接添加一个新的 Voter 来进行动态鉴权。

http.authorizeRequests().withObjectPostProcessor(new ObjectPostProcessor(){
  @Override
  public < 0 extends FilterSecurityInterceptor > 0 postProcess(0 o){
     o.setAccessDecisionManager(new AffirmativeBased(Arrays.asList(new WebExpressionVotor(),userAccessDecisionVoter)));//决策管理器
     o.setSecurityMetadataSource(userFilterInvocationSecurityMetadataSource);//安全元数据
     return o;
  }
}};

在这里我们使用 AffirmativeBased 投票器进行投票，是因为进行自定义过滤的过程中，我们并没有包含 Spring 默认的属性，因此 WebExpressionVoter 会自动弃权，剩余步骤自然由我们自己的投票器 UserAccessDecisionVoter 进行投票和鉴权。

@Component
public class UserAccessDecisionVoter implements AccessDecisionVoter { 
  @Override 
  public boolean supports(ConfigAttribute attribute) { 
     return true; 
  } 
                                    
  @Override 
  public boolean supports(Class clazz) { 
    return true; 
  } 
                                                                             
  @Autowired
  AnalysisUserRoleUtil analysisUserRoleUtil; 
                                                                                             
  @Autowired
  JwtConfig jwtConfig;

  /**         
  * @param authentication   用户信息         
  * @param filterInvocation 请求信息         
  * @param attributes       安全配置属性，这里指的是角色         
  * @return 1：同意、-1：反对，返回1时表示有访问权限，-1表示没有访问权限         
  */        
  @Override        
  public int vote(Authentication authentication, FilterInvocation filterInvocation, Collection attributes) {                
    assert authentication != null;                
    assert filterInvocation != null;                         

    // 没有URL, 拒绝访问                
    String requestURL = getRequestURL(attributes);                
    if (null == requestURL) {                        
      return AccessDecisionVoter.ACCESS_DENIED;                
    }                         

    // 匿名用户, 拒绝访问                
    String userName = authentication.getPrincipal().toString();                
    if (userName.equals("anonymousUser")) {                        
      return AccessDecisionVoter.ACCESS_DENIED;                
    }                          

    // 获取用户信息                
    SystemUser systemUser = systemUserService.queryUserByName(userName);                         

    // 任何人不能删除自己                
    if (this.isDeletingSelf(requestURL, systemUser)) {                        
      return AccessDecisionVoter.ACCESS_DENIED;                
    }                         

    // 依据不同的权限判断是否需要同意操作                
    if (analysisUserRoleUtil.isSuperAdmin(systemUser)) {                        
      return this.superAdminPrivilegeCheck(requestURL, systemUser);                
    }                
    if (analysisUserRoleUtil.isInSuperAdminGroup(systemUser)) {                        
      return this.superAdminGroupMemberPrivilegeCheck(requestURL, systemUser);                
    }                
    if (analysisUserRoleUtil.isGroupAdmin(systemUser)) {                        
      return this.groupAdminPrivilegeCheck(requestURL, systemUser);                
    }                    
      return this.regularUserPrivilegeCheck(requestURL, systemUser);        
  }

该应用是基于角色赋予不同的权限，在后续进行权限判定的过程中，包括但不限于以下两种解决方案：

1. 将所有需要判定的 URI 放入数据库，检查权限时取出；

2. 设计文档中规定涉及到的操作和 URI 模版，相互间独立不干涉；鉴权时用正则表达式进行判断；后续添加的新操作需要依据改模版构建 URI。

第一种策略应用模块众多，后续需要新增大量人员，将需要判定的 URI 放入数据库并用表进行连接，可能导致占用较多的数据库存储空间，并不合适。因此我们采用第二种策略进行操作 URI 的判定，缺点是编码量比较大，优点是不会占用太多的额外存储空间。

在构建自定义鉴权投票器的过程中，可能会发现一些需要直接放行的操作，涉及到这部分操作的 URI 我们将其放在配置文件中，并在构建过滤链的时候进行注入，达到绕开投票的目的。

三、总结

以上便是一个根据 SpringBoot DecisionVoter 自定义动态鉴权的例子，具体鉴权逻辑和各种细节需要根据不同的需求进行不同定制化操作，同时需要注意在进行定制化操作时，要保证鉴权过程的高效性和安全性，避免可能存在的安全漏洞和性能问题。此外，还需要考虑系统的可扩展性和可维护性，以便在未来的需求变更或升级过程中能够方便地进行扩展和维护。