相信side对Acegi的扩展会给你耳目一新的感觉,提供完整的扩展功能,管理界面,中文注释和靠近企业的安全策略。side只对Acegi不符合企业应用需要的功能进行扩展,尽量不改动其余部分来实现全套权限管理功能,以求能更好地适应Acegi升级。
基于角色的权限控制(RBAC)
Acegi 自带的 sample 表设计很简单: users表{username,password,enabled} authorities表{username,authority},这样简单的设计无法适应复杂的权限需求,故SpringSide选用RBAC模型对权限控制数据库表进行扩展。 RBAC引入了ROLE的概念,使User(用户)和Permission(权限)分离,一个用户拥有多个角色,一个角色拥有有多个相应的权限,从而减少了权限管理的复杂度,可更灵活地支持安全策略。
同时,我们也引入了resource(资源)的概念,一个资源对应多个权限，资源分为ACL,URL,和FUNTION三种。注意，URL和FUNTION的权限命名需要以AUTH_开头才会有资格参加投票, 同样的ACL权限命名需要ACL_开头。
管理和使用EhCache
设立缓存
在SpringSide里的 Acegi 扩展使用 EhCache 就作为一种缓存解决方案,以缓存用户和资源的信息和相对应的权限信息。
首先需要一个在classpath的 ehcache.xml 文件，用于配置 EhCache。
<ehcache> <defaultCache maxElementsInMemory="10000" eternal="false" overflowToDisk="true" timeToIdleSeconds="0" timeToLiveSeconds="0" diskPersistent="false" diskExpiryThreadIntervalSeconds= "120"/> <!-- acegi cache--> <cache name="userCache" maxElementsInMemory="10000" eternal="true" overflowToDisk= "true"/> <!-- acegi cache--> <cache name="resourceCache" maxElementsInMemory="10000" eternal="true" overflowToDisk="true"/> </ehcache>
maxElementsInMemory设定了允许在Cache中存放的数据数目，eternal设定Cache是否会过期，overflowToDisk设定内存不足的时候缓存到硬盘，timeToIdleSeconds和timeToLiveSeconds设定缓存游离时间和生存时间，diskExpiryThreadIntervalSeconds设定缓存在硬盘上的生存时间，注意当eternal="true"时，timeToIdleSeconds，timeToLiveSeconds和diskExpiryThreadIntervalSeconds都是无效的。
<defaultCache>是除制定的Cache外其余所有Cache的设置，针对Acegi 的情况, 专门设置了userCache和resourceCache，都设为永不过期。在applicationContext-acegi-security.xml中相应的调用是
<bean id="userCacheBackend" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
<property name="cacheManager" ref="cacheManager"/>
<property name="cacheName" value=" userCache"/>
</bean>
<bean id="userCache" class="org.acegisecurity.providers.dao.cache.EhCacheBasedUserCache" autowire="byName">
<property name="cache" ref="userCacheBackend"/>
</bean>
<bean id="resourceCacheBackend" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
<property name="cacheManager" ref="cacheManager"/>
<property name="cacheName" value=" resourceCache"/>
</bean>
<bean id="resourceCache" class="org.springside.modules.security.service.acegi.cache.ResourceCache" autowire="byName">
<property name="cache" ref="resourceCacheBackend"/>
</bean>
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"/>
"cacheName" 就是设定在ehcache.xml 中相应Cache的名称。
userCache使用的是Acegi 的EhCacheBasedUserCache(实现了UserCache接口), resourceCache是SpringSide的扩展类
public interface UserCache { public UserDetails getUserFromCache (String username); public void putUserInCache (UserDetails user); public void removeUserFromCache (String username); }
public class ResourceCache { public ResourceDetails getAuthorityFromCache (String resString) {... } public void putAuthorityInCache (ResourceDetails resourceDetails) {... } public void removeAuthorityFromCache (String resString) {... } public List getUrlResStrings() {... } public List getFunctions() {.. } }
UserCache 就是通过EhCache对UserDetails 进行缓存管理, 而ResourceCache 是对ResourceDetails 类进行缓存管理
public interface UserDetails extends Serializable { public boolean isAccountNonExpired(); public boolean isAccountNonLocked(); public GrantedAuthority[] getAuthorities(); public boolean isCredentialsNonExpired(); public boolean isEnabled(); public String getPassword(); public String getUsername(); }
public interface ResourceDetails extends Serializable { public String getResString(); public String getResType(); public GrantedAuthority[] getAuthorities(); }
UserDetails 包含用户信息和相应的权限，ResourceDetails 包含资源信息和相应的权限。
public interface GrantedAuthority {
public String getAuthority ();
}
GrantedAuthority 就是权限信息，在Acegi 的 sample 里GrantedAuthority 的信息如ROLE_USER, ROLE_SUPERVISOR, ACL_CONTACT_DELETE, ACL_CONTACT_ADMIN等等，网上也有很多例子把角色作为GrantedAuthority ，但事实上看看ACL 就知道， Acegi本身根本就没有角色这个概念，GrantedAuthority 包含的信息应该是权限，对于非ACL的权限用 AUTH_ 开头更为合理, 如SpringSide里的 AUTH_ADMIN_LOGIN, AUTH_BOOK_MANAGE 等等。
管理缓存
使用AcegiCacheManager对userCache和resourceCache进行统一缓存管理。当在后台对用户信息进行修改或赋权的时候, 在更新数据库同时就会调用acegiCacheManager相应方法, 从数据库中读取数据并替换cache中相应部分,使cache与数据库同步。
public class AcegiCacheManager extends BaseService { private ResourceCache resourceCache ; private UserCache userCache ; /** * 修改User时更改userCache */ public void modifyUserInCache (User user, String orgUsername) {... } /** * 修改Resource时更改resourceCache */ public void modifyResourceInCache (Resource resource, String orgResourcename) {... } /** * 修改权限时同时修改userCache和resourceCache */ public void modifyPermiInCache (Permission permi, String orgPerminame) {... } /** * User授予角色时更改userCache */ public void authRoleInCache (User user) {... } /** * Role授予权限时更改userCache和resourceCache */ public void authPermissionInCache (Role role) {... } /** * Permissioni授予资源时更改resourceCache */ public void authResourceInCache (Permission permi) {... } /** * 初始化userCache */ public void initUserCache () {... } /** * 初始化resourceCache */ public void initResourceCache () {... } /** * 获取所有的url资源 */ public List getUrlResStrings () {... } /** * 获取所有的Funtion资源 */ public List getFunctions () {... } /** * 根据资源串获取资源 */ public ResourceDetails getAuthorityFromCache (String resString) {... } ...... }
资源权限定义扩展
Acegi给出的sample里,资源权限对照关系是配置在xml中的,试想一下如果你的企业安全应用有500个用户,100个角色权限的时候,维护这个xml将是个繁重无比的工作,如何动态更改用户权限更是个头痛的问题。
<bean id="contactManagerSecurity" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor"> <property name="authenticationManager"><ref bean="authenticationManager"/></property> <property name="accessDecisionManager"><ref local="businessAccessDecisionManager"/></property> <property name="afterInvocationManager"><ref local="afterInvocationManager"/></property> <property name="objectDefinitionSource"> <value> sample.contact.ContactManager.create=ROLE_USER sample.contact.ContactManager.getAllRecipients=ROLE_USER sample.contact.ContactManager.getAll=ROLE_USER,AFTER_ACL_COLLECTION_READ sample.contact.ContactManager.getById=ROLE_USER,AFTER_ACL_READ sample.contact.ContactManager.delete=ACL_CONTACT_DELETE sample.contact.ContactManager.deletePermission=ACL_CONTACT_ADMIN sample.contact.ContactManager.addPermission=ACL_CONTACT_ADMIN </value> </property> </bean>
<bean id="filterInvocationInterceptor" class="org.acegisecurity.intercept.web.FilterSecurityInterceptor"> <property name="authenticationManager"><ref bean="authenticationManager"/></property> <property name="accessDecisionManager"><ref local="httpRequestAccessDecisionManager"/></property> <property name="objectDefinitionSource"> <value> CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /index.jsp=ROLE_ANONYMOUS,ROLE_USER /hello.htm=ROLE_ANONYMOUS,ROLE_USER /logoff.jsp=ROLE_ANONYMOUS,ROLE_USER /switchuser.jsp=ROLE_SUPERVISOR /j_acegi_switch_user=ROLE_SUPERVISOR /acegilogin.jsp*=ROLE_ANONYMOUS,ROLE_USER /**=ROLE_USER </value> </property> </bean>
对如此不Pragmatic的做法,SpringSide进行了扩展, 让Acegi 能动态读取数据库中的权限资源关系。
Aop Invocation Authorization
<bean id="methodSecurityInterceptor" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor"> <property name="authenticationManager" ref="authenticationManager"/> <property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/> <property name="objectDefinitionSource" ref="methodDefinitionSource"/> </bean> <bean id="methodDefinitionSource" class="org.springside.security.service.acegi.DBMethodDefinitionSource"> <property name="acegiCacheManager" ref="acegiCacheManager"/> </bean>
研究下Aceig的源码,ObjectDefinitionSource的实际作用是返回一个ConfigAttributeDefinition对象，而Acegi Sample 的方式是用MethodDefinitionSourceEditor把xml中的文本Function资源权限对应关系信息加载到MethodDefinitionMap ( MethodDefinitionSource 的实现类 )中, 再组成ConfigAttributeDefinition，而我们的扩展目标是从缓存中读取信息来组成ConfigAttributeDefinition。
MethodSecurityInterceptor是通过调用AbstractMethodDefinitionSource的lookupAttributes(method)方法获取ConfigAttributeDefinition。所以我们需要实现自己的ObjectDefinitionSource，继承AbstractMethodDefinitionSource并实现其lookupAttributes方法,从缓存中读取资源权限对应关系组成并返回ConfigAttributeDefinition即可。SpringSide中的DBMethodDefinitionSource类的部分实现如下 :
public class DBMethodDefinitionSource extends AbstractMethodDefinitionSource { ...... protected ConfigAttributeDefinition lookupAttributes(Method mi) { Assert.notNull(mi, "lookupAttrubutes in the DBMethodDefinitionSource is null"); String methodString = mi.getDeclaringClass().getName() + "." + mi.getName(); if (!acegiCacheManager.isCacheInitialized()) { //初始化Cache acegiCacheManager.initResourceCache(); } //获取所有的function List methodStrings = acegiCacheManager.getFunctions(); Set auths = new HashSet(); //取权限的合集 for (Iterator iter = methodStrings.iterator(); iter.hasNext();) { String mappedName = (String) iter.next(); if (methodString.equals(mappedName) || isMatch(methodString, mappedName)) { ResourceDetails resourceDetails = acegiCacheManager.getAuthorityFromCache(mappedName); if (resourceDetails == null) { break; } GrantedAuthority[] authorities = resourceDetails.getAuthorities(); if (authorities == null || authorities.length == 0) { break; } auths.addAll(Arrays.asList(authorities)); } } if (auths.size() == 0) return null; ConfigAttributeEditor configAttrEditor = new ConfigAttributeEditor(); String authoritiesStr = " "; for (Iterator iter = auths.iterator(); iter.hasNext();) { GrantedAuthority authority = (GrantedAuthority) iter.next(); authoritiesStr += authority.getAuthority() + ","; } String authStr = authoritiesStr.substring(0, authoritiesStr.length() - 1); configAttrEditor.setAsText(authStr); //组装并返回ConfigAttributeDefinition return (ConfigAttributeDefinition) configAttrEditor.getValue(); } ...... }
要注意几点的是:
1) 初始化Cache是比较浪费资源的，所以SpringSide中除第一次访问外的Cache的更新是针对性更新。
2) 因为method采用了匹配方式(详见 isMatch() 方法) , 即对于*Book和save*这两个资源来说，只要当前访问方法是Book结尾或以save开头都算匹配得上，所以应该取这些能匹配上的资源的相对应的权限的合集。
3) 使用ConfigAttributeEditor 能更方便地组装ConfigAttributeDefinition。
Filter Invocation Authorization
<bean id="filterInvocationInterceptor" class="org.acegisecurity.intercept.web.FilterSecurityInterceptor"> <property name="authenticationManager" ref="authenticationManager"/> <property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/> <property name="objectDefinitionSource" ref="filterDefinitionSource"/> </bean> <bean id="filterDefinitionSource" class="org.springside.security.service.acegi.DBFilterInvocationDefinitionSource"> <property name="convertUrlToLowercaseBeforeComparison" value="true"/> <property name="useAntPath" value="true"/> <property name="acegiCacheManager" ref="acegiCacheManager"/> </bean>
PathBasedFilterInvocationDefinitionMap和RegExpBasedFilterInvocationDefinitionMap都是 FilterInvocationDefinitionSource的实现类,当PATTERN_TYPE_APACHE_ANT字符串匹配上时时,FilterInvocationDefinitionSourceEditor 选用PathBasedFilterInvocationDefinitionMap 把xml中的文本URL资源权限对应关系信息加载。
FilterSecurityInterceptor通过FilterInvocationDefinitionSource的lookupAttributes(url)方法获取ConfigAttributeDefinition。 所以，我们可以通过继承FilterInvocationDefinitionSource的抽象类AbstractFilterInvocationDefinitionSource，并实现其lookupAttributes方法,从缓存中读取URL资源权限对应关系即可。SpringSide的DBFilterInvocationDefinitionSource类部分实现如下:
public class DBFilterInvocationDefinitionSource extends AbstractFilterInvocationDefinitionSource { ...... public ConfigAttributeDefinition lookupAttributes(String url) { if (!acegiCacheManager.isCacheInitialized()) { acegiCacheManager.initResourceCache(); } if (isUseAntPath()) { // Strip anything after a question mark symbol, as per SEC-161. int firstQuestionMarkIndex = url.lastIndexOf("?"); if (firstQuestionMarkIndex != -1) { url = url.substring(0, firstQuestionMarkIndex); } } List urls = acegiCacheManager.getUrlResStrings(); //URL资源倒叙排序 Collections.sort(urls); Collections.reverse(urls); //是否先全部转为小写再比较 if (convertUrlToLowercaseBeforeComparison) { url = url.toLowerCase(); } GrantedAuthority[] authorities = new GrantedAuthority[0]; for (Iterator iterator = urls.iterator(); iterator.hasNext();) { String resString = (String) iterator.next(); boolean matched = false; //可选择使用AntPath和Perl5两种不同匹配模式 if (isUseAntPath()) { matched = pathMatcher.match(resString, url); } else { Pattern compiledPattern; Perl5Compiler compiler = new Perl5Compiler(); try { compiledPattern = compiler.compile(resString, Perl5Compiler.READ_ONLY_MASK); } catch (MalformedPatternException mpe) { throw new IllegalArgumentException( "Malformed regular expression: " + resString); } matched = matcher.matches(url, compiledPattern); } if (matched) { ResourceDetails rd = acegiCacheManager.getAuthorityFromCache(resString); authorities = rd.getAuthorities(); break; } } if (authorities.length > 0) { String authoritiesStr = " "; for (int i = 0; i < authorities.length; i++) { authoritiesStr += authorities[i].getAuthority() + ","; } String authStr = authoritiesStr.substring(0, authoritiesStr .length() - 1); ConfigAttributeEditor configAttrEditor = new ConfigAttributeEditor(); configAttrEditor.setAsText(authStr); return (ConfigAttributeDefinition) configAttrEditor.getValue(); } return null; } ...... }
继承AbstractFilterInvocationDefinitionSource注意几点：
1) 需要先把获取回来的URL资源按倒序派序，以达到 a/b/c/d.* 在 a/.* 之前的效果(详见 Acegi sample 的applicationContext-acegi-security.xml 中的filterInvocationInterceptor的注释)，为的是更具体的URL可以先匹配上，而获取具体URL的权限，如a/b/c/d.*权限AUTH_a, AUTH_b 才可查看, a/.* 需要权限AUTH_a 才可查看，则如果当前用户只拥有权限AUTH_b,则他只可以查看a/b/c/d.jsp 而不能察看a/d.jsp。
2) 基于上面的原因，故第一次匹配上的就是当前所需权限，而不是取权限的合集。
3) 可以选用AntPath 或 Perl5 的资源匹配方式，感觉AntPath匹配方式基本足够。
4) Filter 权限控制比较适合于较粗颗粒度的权限，如设定某个模块下的页面是否能访问等，对于具体某个操作如增删修改，是否能执行，用Method Invocation 会更佳些，所以注意两个方面一起控制效果更好
授权操作
RBAC模型中有不少多对多的关系，这些关系都能以一个中间表的形式来存放，而Hibernate中可以不建这中间表对应的hbm.xml , 以资源与权限的配置为例，如下:
<hibernate-mapping package="org.springside.modules.security.domain"> <class name="Permission" table="PERMISSIONS" dynamic-insert="true" dynamic-update="true"> <cache usage="nonstrict-read-write"/> <id name="id" column="ID"> <generator class="native"/> </id> <property name="name" column="NAME" not-null="true"/> <property name="descn" column="DESCN"/> <property name="operation" column="OPERATION"/> <property name="status" column="STATUS"/> <set name="roles" table="ROLE_PERMIS" lazy="true" inverse="true" cascade="save-update" batch-size="5"> <key> <column name="PERMIS_ID" not-null="true"/> </key> <many-to-many class="Role" column="ROLE_ID" outer-join="auto"/> </set> <set name="resources" table="PERMIS_RESC" lazy="true" inverse="false" cascade="save-update" batch-size="5"> <key> <column name="PERMIS_ID" not-null="true"/> </key> <many-to-many class="Resource" column="RESC_ID"/> </set> </class> </hibernate-mapping>
<hibernate-mapping package="org.springside.modules.security.domain"> <class name="Resource" table="RESOURCES" dynamic-insert="true" dynamic-update="true"> <cache usage="nonstrict-read-write"/> <id name="id" column="ID"> <generator class="native"/> </id> <property name="name" column="NAME" not-null="true"/> <property name="resType" column="RES_TYPE" not-null="true"/> <property name="resString" column="RES_STRING" not-null="true"/> <property name="descn" column="DESCN"/> <set name="permissions" table="PERMIS_RESC" lazy="true" inverse="true" cascade="save-update" batch-size="5"> <key> <column name="RESC_ID" not-null="true"/> </key> <many-to-many class="Permission" column="PERMIS_ID" outer-join="auto"/> </set> </class> </hibernate-mapping>
配置时注意几点:
1) 因为是分配某个权限的资源，所以权限是主控方，把inverse设为false，资源是被控方inverse设为true
2) cascade是"save-update"，千万别配成delete
3) 只需要 permission.getResources().add(resource)， permission.getResources()..remove(resource) 即可很方便地完成授权和取消授权操作
82
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
