一、概述
Spring Security 是 Spring 框架内高度可定制化的安全框架，也是 Spring 应用的标准安全框架，提供了包括认证和鉴权在内的两大部分。其高度集成于 Spring 框架，无需引入第三方扩展模块，可以避 免大量的数据接口适配问题，大幅度减少开发成本和时间。
如下图所示，Spring Security 的认证鉴权过程实际上位于请求过滤器和拦截器中，在请求通过了所有的过滤器和拦截器之后才会进行 API 适配。换言之，定制 Spring Security 就是修改过滤链中的各种过滤器和拦截器。
认证过程是图中绿色的部分，Spring Security 提供了非常多的认证方式，如密码认证、预认证等；橙色的部分是动态鉴权部分，其内置的 Security Interceptor 会将请求委托给各个具体的 AccessDecisionManager 进行鉴权。
![1.jpg]()
Spring Security 的整个数据流程
在 Spring Security 中，AccessDecisionManager 是以投票器为蓝本进行的鉴权：Manager 下面会有多个 AccessDecisionVoter，每个 Voter 将结果返回至 Manager，最后由 Manager 确定是否授予权限。
Manager 共有三类：
之所以会用投票器，一是方便添加和扩展 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);
}
该应用是基于角色赋予不同的权限，在后续进行权限判定的过程中，包括但不限于以下两种解决方案：
-
将所有需要判定的 URI 放入数据库，检查权限时取出；
-
设计文档中规定涉及到的操作和 URI 模版，相互间独立不干涉；鉴权时用正则表达式进行判断；后续添加的新操作需要依据改模版构建 URI。
第一种策略应用模块众多，后续需要新增大量人员，将需要判定的 URI 放入数据库并用表进行连接，可能导致占用较多的数据库存储空间，并不合适。因此我们采用第二种策略进行操作 URI 的判定，缺点是编码量比较大，优点是不会占用太多的额外存储空间。
在构建自定义鉴权投票器的过程中，可能会发现一些需要直接放行的操作，涉及到这部分操作的 URI 我们将其放在配置文件中，并在构建过滤链的时候进行注入，达到绕开投票的目的。
三、总结
以上便是一个根据 SpringBoot DecisionVoter 自定义动态鉴权的例子，具体鉴权逻辑和各种细节需要根据不同的需求进行不同定制化操作，同时需要注意在进行定制化操作时，要保证鉴权过程的高效性和安全性，避免可能存在的安全漏洞和性能问题。此外，还需要考虑系统的可扩展性和可维护性，以便在未来的需求变更或升级过程中能够方便地进行扩展和维护。
