一、概述

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<FilterSecurityInterceptor>(){ @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<FilterInvocation> { @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<ConfigAttribute> 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 自定义动态鉴权的例子，具体鉴权逻辑和各种细节需要根据不同的需求进行不同定制化操作，同时需要注意在进行定制化操作时，要保证鉴权过程的高效性和安全性，避免可能存在的安全漏洞和性能问题。此外，还需要考虑系统的可扩展性和可维护性，以便在未来的需求变更或升级过程中能够方便地进行扩展和维护。