本文将详细探讨spring security中的鉴权操作,包括AbstractSecurityInterceptor的不同实现,后面章节还会讨论更加精确的域对象访问控制。
1.架构
1.1 组件之Authorities
在 核心组件章节,我们知道认证后的Authentication中都会存储一个GrantedAuthority列表,代表着当前认证用户所具有的权限信息。在鉴权阶段AccessDecisionManager从Authentication中读取到这个列表,并据此作出是否允许用户操作执行的判断。GrantedAuthority是一个接口,里面只有一个方法
String getAuthority();
通过这个方法,AccessDecisionManager能获取一个明确的代表权限信息的字符串,如果某个GrantedAuthority不能单纯的通过一个字符串来代表权限信息,这个GrantedAuthority应该被认为是一个“复合”权限,对应的getAuthority()方法必须返回null。
spring security为我们提供了一个GrantedAuthority的具体实现类:SimpleGrantedAuthority,这个类可以把用户设定的字符串转换成GrantedAuthority,spring security提供的各种AuthenticationProvider都是用SimpleGrantedAuthority这个类来组装Authentication的。
1.2 组件之AccessDecisionManager
spring security是通过拦截器来控制安全访问的,一个请求最终能否被执行是通过AccessDecisionManager类的decide来判断的。这个类是被AbstractSecurityInterceptor调用的,AccessDecisionManager接口包含下面三个方法
void decide(Authentication authentication, Object secureObject, Collectionattrs) throws AccessDeniedException; boolean supports(ConfigAttribute attribute); boolean supports(Class clazz);
AccessDecisionManager的decide方法会传入所有做出决定所需的信息。通常情况下,通过传入的安全对象,我们就可以获取到大部分所需的参数信息,例如:假定传入的对象是MethodInvocation,可以很容易的通过MethodInvocation获取任意的自定义参数,然后通过AccessDecisionManager中的判断逻辑来确保当前用户是可以针对这些参数执行操作的,如果不允许,应该抛出AccessDeniedException异常。
在应用启动时AbstractSecurityInterceptor会调用AccessDecisionManager的supports(ConfigAttribute)方法来检查当前的ConfigAttribute是否能被对应的Interceptor支持,如FilterSecurityInterceptor支持FilterInvocationSecurityMetadataSource对应的ConfigAttribute,MethodSecurityInterceptor支持MethodSecurityMetadataSource对应的ConfigAttribute。
supports(Class)用来判断当前Interceptor是否支持对应的Security object对象。
1.3 基于投票机制的AccessDecisionManager实现
尽管用户可以实现自己的AccessDecisionManager来控制鉴权的所有处理,为了方便,spring security也提供了几种基于投票机制的AccessDecisionManager实现,相关类关系如下:
从上图可以看出,AccessDecisionManager就是利用各种各样的AccessDecisionVoter的投票结果来做最后的决定的。AccessDecisionVoter接口的内容如下
int vote(Authentication authentication, Object object, Collectionattrs); boolean supports(ConfigAttribute attribute); boolean supports(Class clazz);
具体的AccessDecisionVoter实现者vote方法返回一个int值,对应的具体值在AccessDecisionVoter中定义成了常量:ACCESS_ABSTAIN, ACCESS_DENIED , ACCESS_GRANTED,分别代表弃权、拒绝、同意。
具体的AccessDecisionManager实现类有三个
- ConsensusBased 统计所有的投票结果,如果赞成大于反对旧赞成,如果发对大于赞成就抛异常,如果赞成和反对一样多,就看配置的allowIfEqualGrantedDeniedDecisions属性值,true的话就赞成,false就抛异常。
- AffirmativeBased(默认)只要有赞成的投票就赞成,如果所有的投票结果都没有赞成,并且有反对的票就抛出异常,否则就是所有的投票结果都是弃权,也是看看配置的allowIfEqualGrantedDeniedDecisions属性值,true的话就赞成,false就抛异常
- UnanimousBased 只要有反对的票就抛出异常,如果没有反对票并且有赞成票,也认为是赞成,否则就是所有的投票结果都是弃权,也是看看配置的allowIfEqualGrantedDeniedDecisions属性值,true的话就赞成,false就抛异常
我们也可以通过自定义实现AccessDecisionManager,例如可以对各种投票的结果追加权重计算等。
1.4 组件之RoleVoter
实际应用中最常用AccessDecisionVoter的具体实现类是RoleVoter,以及有继承功能的RoleHierarchyVoter,这两个实现都是把配置属性单纯的当作角色名称,当用户有对应的角色权限时就投赞成票。
具体逻辑如下:
- 当一个安全对象对应的ConfigAttribute以ROLE_开头,则进行投票,否则就弃权
- 获取当前认证对象authentication中的权限列表,权限列表里面有和ConfigAttribute.getAttribute()返回值相同的权限时就赞成,否则投拒绝票
1.5 组件之AuthenticatedVoter
不同于RoleVoter,这个实现类会根据当前的认证类型进行投票,主要用来区分匿名认证、remember-me认证、fully-authenticated认证。这种鉴权方式主要用在那种对remember-me认证有特殊访问限制的系统中
1.6 调用完后处理(After Invocation Handling)
AccessDecisionManager是AbstractSecurityInterceptor在执行安全对象之前进行调用的,没有权限抛出异常,从而用户限制调用。实际应用中,有的系统可能会希望在调用完成后再对返回结果进行修改,当然,借助spring aop,我们自己也能实现相应的逻辑,spring security给我们提供了更加便捷和ACL进行继承的默认实现,相关联的类如下:
核心类是AfterInvocationManager,在调用完安全对象(FilterInvocation)后,会调用这个类的decide方法,具体的实现类是AfterInvocationProviderManager,里面有一个AfterInvocationProvider列表,每一个AfterInvocationProvider要么修改一下的结果,要么抛出异常。
1.7 继承角色
具体例子参考 java config-sample之rolehierarchy