咻pur慢 2012-02-19
访问控制:
由于我们配置了访问控制(授权)的默认拦截器org.springframework.security.web.access.intercept.FilterSecurityInterceptor。其主要业务方法是InterceptorStatusTokenbeforeInvocation(Objectobject)
该方法会将URL传给SecurityMetadataSource获取匹配该URL所有参数ConfigAttribute(拥有权限的角色)的集合。
如果该用户尚未认证(登录),或拦截器配置了“始终认证”,则拦截器会将该用户的登录信息(未登录则跳转到登陆页面)重新认证,并加载角色信息。
随后将用户认证信息(Authentication),用户请求访问的URL,以及配置集合(Collection<ConfigAttribute>)交由accessDecisionManager的decide方法。通过则方法继续,否则抛出AccessDeniedException。
调用runAsManager尝试转换认证信息,这是为了方便适应两层访问控制架构。runAsManager就可以将外部公开的认证,转换为内部认证,继续之后的访问。
之后返回包含访问拦截信息的对象InterceptorStatusToken。以便afterInvocation(InterceptorStatusToken,Object)方法运行。
安全信息元数据提供者:
默认实现DefaultFilterInvocationSecurityMetadataSource构造时通过addSecureUrl(Stringpattern,Stringmethod,Collection<ConfigAttribute>attrs)方法将传入参数转换为私有成员变量Map<String,Map<Object,Collection<ConfigAttribute>>>httpMethodMap缓存,并通过Collection<ConfigAttribute>lookupAttributes(Stringurl,Stringmethod)获得第一个能匹配的上的URL模式,并返回其所需要的角色集合Collection<ConfigAttribute>
访问控制管理者:
访问控制管理者AccessDecisionManager需要投票者AccessDecisionVoter列表,调用后者的vote方法。而前者则负责统计所有投票者的投票情况,并做出是否授权的决定。而框架提供了三个统计策略,分别是“只要有一个投票者同意即同意”,“需要所有投票者同意才同意”,“少数服从多数”。分别对应着
AbstractAccessDecisionManager的三个子类AffirmativeBased, UnanimousBased,ConsensusBased。
基于角色的投票者:RoleVoter实现了AccessDecisionVoter接口,其vote方法是这样写的。
public int vote(Authentication authentication, Object object, Collection<ConfigAttribute> attributes) { int result = ACCESS_ABSTAIN; Collection<GrantedAuthority> authorities = extractAuthorities(authentication); for (ConfigAttribute attribute : attributes) { if (this.supports(attribute)) { result = ACCESS_DENIED; // 查找匹配角色 for (GrantedAuthority authority : authorities) { if (attribute.getAttribute().equals(authority.getAuthority())) { return ACCESS_GRANTED; } } } } return result; } Collection<GrantedAuthority> extractAuthorities(Authentication authentication) { return authentication.getAuthorities(); }
ps:DefaultFilterInvocationSecurityMetadataSource初始化过程详解
SpringSecurity3访问验证模块的初始化,主要是FilterInvocationSecurityMetadataSource对象加载配置信息的过程。
而FilterInvocationSecurityMetadataSource的实现,我选用了框架提供的默认实现DefaultFilterInvocationSecurityMetadataSource。
在DefaultFilterInvocationSecurityMetadataSource构造的时候,需要UrlMatcher和LinkedHashMap<RequestKey,Collection<ConfigAttribute>>两个参数。
前者是解析Url的匹配器,框架提供两种选择:一个是AntUrlPathMatcher,另一个是正则匹配。当然也可以自己写,只要实现UrlMatcher接口就行。
第二个参数需要提供所有的请求URL模板,与其对应所有的配置属性(在RBAC系统中即为“角色码”)。
例如:RequestKey为/user!add**,Collection<ConfigAttribute>为[ROLE_HR,ROLE_ADMIN]。就是说,能有权限访问用户添加模块的角色为HR,和管理员。
在DefaultFilterInvocationSecurityMetadataSource的构造方法当中,其通过addSecureUrl(Stringpattern,Stringmethod,Collection<ConfigAttribute>attrs)方法将传入参数转换为私有成员变量Map<String,Map<Object,Collection<ConfigAttribute>>>httpMethodMap;
key是Http方法:主要“GET”"和POST",Value是Key的HTTP方法对应的配置属性集合。key为null时,value为不特定方法的配置属性集合。而Value也是一个Map,它的主键是编译后的URL模板,值为各种角色的ConfigAttribute对象。