读书人
栏目▼

Acegi Security - Spring停最优秀的安

发布时间： 2012-08-14 10:39:57 作者： rapoo

Acegi Security -- Spring下最优秀的安全系统

一Acegi安全系统介绍

Author: cac 差沙

Acegi是Spring Framework下最成熟的安全系统，它提供了强大灵活的企业级安全服务，如完善的认证和授权机制，Http资源访问控制，Method 调用访问控制，AccessControl List (ACL) 基于对象实例的访问控制，Yale Central Authentication Service(CAS) 耶鲁单点登陆，X509 认证，当前所有流行容器的认证适配器，Channel Security频道安全管理等功能。

1.1 网站资源

官方网站 http://acegisecurity.sourceforge.net
论坛 http://forum.springframework.org/forumdisplay.php?f=33
Jira http://opensource.atlassian.com/projects/spring/browse/SEC

1.2 多方面的安全控制粒度
    URL 资源访问控制
    http://apps:8080/index.htm -> for public
    http://apps:8080/user.htm -> for authorized user 方法调用访问控制
    public void getData() -> all user
    public void modifyData() -> supervisor only 对象实例保护
    order.getValue() < $100 -> all user
    order.getValue() > $100 -> supervisor only
1.3 非入侵式安全架构
    基于Servlet Filter和Spring aop, 使商业逻辑和安全逻辑分开，结构更清晰 使用Spring 来代理对象，能方便地保护方法调用
1.4 其它安全架构

Acegi只是安全框架之一，其实还存在其它优秀的安全框架可供选择：

JAAS ：http://java.sun.com/products/jaas/ Seraph: http://opensource.atlassian.com/seraph/ jSai - Servlet Security : http://oss.ipov.org/jsai/ Gabriel : http://gabriel.codehaus.org/ JOSSO : http://www.josso.org/ Kasai: http://www.manentiasoftware.com/kasai/goToHome.action jPAM : http://jpam.sourceforge.net/ OpenSAML : http://www.opensaml.org/

二 Acegi安全系统的配置

Acegi 的配置看起来非常复杂,但事实上在实际项目的安全应用中我们并不需要那么多功能,清楚的了解Acegi配置中各项的功能，有助于我们灵活的运用Acegi于实践中。

2.1 在Web.xml中的配置

1) FilterToBeanProxy
　　Acegi通过实现了Filter接口的FilterToBeanProxy提供一种特殊的使用Servlet Filter的方式，它委托Spring中的Bean --FilterChainProxy来完成过滤功能，这好处是简化了web.xml的配置，并且充分利用了SpringIOC的优势。FilterChainProxy包含了处理认证过程的filter列表，每个filter都有各自的功能。

  <filter> <filter-name>Acegi Filter Chain Proxy</filter-name> <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class> <init-param> <param-name>targetClass</param-name> <param-value>org.acegisecurity.util.FilterChainProxy</param-value> </init-param> </filter>

2) filter-mapping
　　<filter-mapping>限定了FilterToBeanProxy的URL匹配模式,只有*.do和*.jsp和/j_acegi_security_check 的请求才会受到权限控制，对javascript,css等不限制。

 <filter-mapping> <filter-name>Acegi Filter Chain Proxy</filter-name> <url-pattern>*.do</url-pattern> </filter-mapping> <filter-mapping> <filter-name>Acegi Filter Chain Proxy</filter-name> <url-pattern>*.jsp</url-pattern> </filter-mapping> <filter-mapping> <filter-name>Acegi Filter Chain Proxy</filter-name> <url-pattern>/j_acegi_security_check</url-pattern>    </filter-mapping>

3) HttpSessionEventPublisher
　　<listener>的HttpSessionEventPublisher用于发布HttpSessionApplicationEvents和HttpSessionDestroyedEvent事件给spring的applicationcontext。

 <listener> <listener-class>org.acegisecurity.ui.session.HttpSessionEventPublisher</listener-class> </listener>

2.2 在applicationContext-acegi-security.xml中2.2.1 FILTER CHAIN

　　FilterChainProxy会按顺序来调用这些filter,使这些filter能享用Spring ioc的功能,CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON定义了url比较前先转为小写，PATTERN_TYPE_APACHE_ANT定义了使用Apache ant的匹配模式 

    <bean id="filterChainProxy" ref="jdbcDaoImpl"/> <property name="userCache" ref="userCache"/> <property name="passwordEncoder" ref="passwordEncoder"/> </bean>


3) passwordEncoder
　　使用加密器对用户输入的明文进行加密。Acegi提供了三种加密器:
PlaintextPasswordEncoder—默认，不加密，返回明文.
ShaPasswordEncoder—哈希算法(SHA)加密
Md5PasswordEncoder—消息摘要(MD5)加密

<bean id="passwordEncoder" ref="dataSource"/> <property name="usersByUsernameQuery"> <value>select loginid,passwd,1 from users where loginid = ?</value> </property> <property name="authoritiesByUsernameQuery"> <value>select u.loginid,p.name from users u,roles r,permissions p,user_role ur,role_permis rp where u.id=ur.user_id and r.id=ur.role_id and p.id=rp.permis_id and r.id=rp.role_id and p.status='1' and u.loginid=?</value> </property></bean>

5) userCache　& resourceCache
　　缓存用户和资源相对应的权限信息。每当请求一个受保护资源时，daoAuthenticationProvider就会被调用以获取用户授权信息。如果每次都从数据库获取的话，那代价很高，对于不常改变的用户和资源信息来说，最好是把相关授权信息缓存起来。(详见 2.6.3 资源权限定义扩展 )
userCache提供了两种实现: NullUserCache和EhCacheBasedUserCache, NullUserCache实际上就是不进行任何缓存，EhCacheBasedUserCache是使用Ehcache来实现缓功能。

 <bean id="userCacheBackend" ref="cacheManager"/> <property name="cacheName" value="userCache"/> </bean> <bean id="userCache" autowire="byName"> <property name="cache" ref="userCacheBackend"/>   </bean> <bean id="resourceCacheBackend" ref="cacheManager"/> <property name="cacheName" value="resourceCache"/> </bean> <bean id="resourceCache" autowire="byName"> <property name="cache" ref="resourceCacheBackend"/> </bean>


6) basicProcessingFilter
　　用于处理HTTP头的认证信息，如从Spring远程协议(如Hessian和Burlap)或普通的浏览器如IE,Navigator的HTTP头中获取用户信息，将他们转交给通过authenticationManager属性装配的认证管理器。如果认证成功，会将一个Authentication对象放到会话中，否则，如果认证失败，会将控制转交给认证入口点(通过authenticationEntryPoint属性装配)

 <bean id="basicProcessingFilter" ref="authenticationManager"/> <property name="authenticationEntryPoint" ref="basicProcessingFilterEntryPoint"/> </bean>

7) basicProcessingFilterEntryPoint
　　通过向浏览器发送一个HTTP401(未授权)消息，提示用户登录。
处理基于HTTP的授权过程， 在当验证过程出现异常后的"去向"，通常实现转向、在response里加入error信息等功能。

 <bean id="basicProcessingFilterEntryPoint" value="SpringSide Realm"/></bean>

8) authenticationProcessingFilterEntryPoint
　　当抛出AccessDeniedException时，将用户重定向到登录界面。属性loginFormUrl配置了一个登录表单的URL,当需要用户登录时，authenticationProcessingFilterEntryPoint会将用户重定向到该URL

 <bean id="authenticationProcessingFilterEntryPoint" value="false"/></bean>
2.2.3 HTTP安全请求

1) httpSessionContextIntegrationFilter
　　每次request前HttpSessionContextIntegrationFilter从Session中获取Authentication对象，在request完后, 又把Authentication对象保存到Session中供下次request使用,此filter必须其他Acegifilter前使用，使之能跨越多个请求。

<bean id="httpSessionContextIntegrationFilter" value="false"/> <property name="decisionVoters"> <list> <ref bean="roleVoter"/> </list> </property></bean>


2) httpRequestAccessDecisionManager
　　经过投票机制来决定是否可以访问某一资源(URL或方法)。allowIfAllAbstainDecisions为false时如果有一个或以上的decisionVoters投票通过,则授权通过。可选的决策机制有ConsensusBased和UnanimousBased

 <bean id="httpRequestAccessDecisionManager" value="false"/> <property name="decisionVoters"> <list> <ref bean="roleVoter"/> </list> </property> </bean>


3) roleVoter
　　必须是以rolePrefix设定的value开头的权限才能进行投票,如AUTH_ , ROLE_

 <bean id="roleVoter" value="AUTH_"/> </bean>

4）exceptionTranslationFilter
　　异常转换过滤器，主要是处理AccessDeniedException和AuthenticationException，将给每个异常找到合适的"去向"

 <bean id="exceptionTranslationFilter" ref="authenticationProcessingFilterEntryPoint"/> </bean>

5) authenticationProcessingFilter
　　和servlet spec差不多,处理登陆请求.当身份验证成功时，AuthenticationProcessingFilter会在会话中放置一个Authentication对象，并且重定向到登录成功页面
authenticationFailureUrl定义登陆失败时转向的页面
defaultTargetUrl定义登陆成功时转向的页面
filterProcessesUrl定义登陆请求的页面
rememberMeServices用于在验证成功后添加cookie信息

 <bean id="authenticationProcessingFilter" ref="authenticationManager"/> <property name="authenticationFailureUrl"> <value>/security/login.jsp?login_error=1</value> </property> <property name="defaultTargetUrl"> <value>/admin/index.jsp</value> </property> <property name="filterProcessesUrl"> <value>/j_acegi_security_check</value> </property> <property name="rememberMeServices" ref="rememberMeServices"/> </bean>

6) filterInvocationInterceptor
　　在执行转向url前检查objectDefinitionSource中设定的用户权限信息。首先，objectDefinitionSource中定义了访问URL需要的属性信息(这里的属性信息仅仅是标志，告诉accessDecisionManager要用哪些voter来投票)。然后，authenticationManager掉用自己的provider来对用户的认证信息进行校验。最后，有投票者根据用户持有认证和访问url需要的属性，调用自己的voter来投票，决定是否允许访问。

 <bean id="filterInvocationInterceptor" ref="authenticationManager"/> <property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/> <property name="objectDefinitionSource" ref="filterDefinitionSource"/> </bean>


7) filterDefinitionSource (详见 2.6.3 资源权限定义扩展)
　　自定义DBFilterInvocationDefinitionSource从数据库和cache中读取保护资源及其需要的访问权限信息

<bean id="filterDefinitionSource" value="true"/> <property name="useAntPath" value="true"/> <property name="acegiCacheManager" ref="acegiCacheManager"/></bean>
2.2.4 方法调用安全控制

(详见 2.6.3 资源权限定义扩展)

1) methodSecurityInterceptor
　　在执行方法前进行拦截，检查用户权限信息
2) methodDefinitionSource
　　自定义MethodDefinitionSource从cache中读取权限

 <bean id="methodSecurityInterceptor" ref="authenticationManager"/> <property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/> <property name="objectDefinitionSource" ref="methodDefinitionSource"/> </bean> <bean id="methodDefinitionSource" ref="acegiCacheManager"/> </bean>
2.3 Jcaptcha验证码

采用 http://jcaptcha.sourceforge.net作为通用的验证码方案，请参考SpringSide中的例子，或网上的：
http://www.coachthrasher.com/page/blog?entry=jcaptcha_with_appfuse。

差沙在此过程中又发现acegi logout filter的错误，进行了修正。

另外它默认提供的图片比较难认，我们custom了一个美观一点的版本。

三Acegi安全系统扩展

相信side对Acegi的扩展会给你耳目一新的感觉,提供完整的扩展功能,管理界面,中文注释和靠近企业的安全策略。side只对Acegi不符合企业应用需要的功能进行扩展,尽量不改动其余部分来实现全套权限管理功能,以求能更好地适应Acegi升级。

3.1 基于角色的权限控制(RBAC)

Acegi 自带的 sample 表设计很简单: users表{username,password,enabled}authorities表{username,authority},这样简单的设计无法适应复杂的权限需求,故SpringSide选用RBAC模型对权限控制数据库表进行扩展。RBAC引入了ROLE的概念,使User(用户)和Permission(权限)分离,一个用户拥有多个角色,一个角色拥有有多个相应的权限,从而减少了权限管理的复杂度,可更灵活地支持安全策略。

Acegi Security - Spring停最优秀的安全系统

同时,我们也引入了resource(资源)的概念,一个资源对应多个权限，资源分为ACL,URL,和FUNTION三种。注意，URL和FUNTION的权限命名需要以AUTH_开头才会有资格参加投票, 同样的ACL权限命名需要ACL_开头。

?

3.2管理和使用EhCache3.2.1 设立缓存

在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" ref="cacheManager"/> <property name="cacheName" value="  userCache"/> </bean> <bean id="userCache" autowire="byName"> <property name="cache" ref="userCacheBackend"/> </bean> <bean id="resourceCacheBackend" ref="cacheManager"/> <property name="cacheName" value="  resourceCache"/> </bean> <bean id="resourceCache" autowire="byName"> <property name="cache" ref="resourceCacheBackend"/> </bean><bean id="cacheManager" 就是设定在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 等等。 

3.2.2 管理缓存
 使用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) {... }......}

?

3.3 资源权限定义扩展
 Acegi给出的sample里,资源权限对照关系是配置在xml中的,试想一下如果你的企业安全应用有500个用户,100个角色权限的时候,维护这个xml将是个繁重无比的工作,如何动态更改用户权限更是个头痛的问题。

 <bean id="contactManagerSecurity" ref="authenticationManager"/> <property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/> <property name="objectDefinitionSource" ref="methodDefinitionSource"/> </bean> <bean id="methodDefinitionSource" 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。 

3.3.2 Filter Invocation Authorization
 <bean id="filterInvocationInterceptor" ref="authenticationManager"/> <property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/> <property name="objectDefinitionSource" ref="filterDefinitionSource"/> </bean> <bean id="filterDefinitionSource" 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 extendsAbstractFilterInvocationDefinitionSource {...... 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 权限控制比较适合于较粗颗粒度的权限，如设定某个模块下的页面是否能访问等，对于具体某个操作如增删修改，是否能执行，用MethodInvocation 会更佳些，所以注意两个方面一起控制效果更好


3.4 授权操作
 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 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 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 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 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 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) 即可很方便地完成授权和取消授权操作


四Acegi ACL使用

4.1 基本概念
 在google中搜索'acl'会找到很多相关的介绍，而且涉及的范围也特别广泛。ACL是(Access Control List)的缩写，顾名思义，ACL是‘访问控制列表’的意思。通俗点说，ACL保存了所有用户或角色对资源的访问权限。最典型的ACL实现是流行操作系统(window, unix)的文件访问控制系统，精确定义了某个用户或角色对某个特定文件的读、写、执行等权限，更通俗的例子是可以定义某个管理员只能管一部分的订单，而另一个管理员只能管另一部分的。

4.2 Acegi ACL配置
Acegi好早就实现了ACL（好像是0.5），但是使用起来确实有点麻烦，所以用的不是太广泛。这里简单的说明一下使用方法，希望有更多的朋友来试试。

首先要理解Acegi里面Voter的概念，ACL正是在一个Voter上扩展起来的。现来看一下AclVoter的配置。

<beanid="aclBeanReadVoter"class="org.acegisecurity.vote.BasicAclEntryVoter">
<propertyname="processConfigAttribute">
<value>ACL_READ</value>
</property>
<propertyname="processDomainObjectClass">
<value>org.springside.modules.security.acl.domain.AclDomainAware</value>
</property>
<propertyname="aclManager">
<reflocal="aclManager"/>
</property>
<propertyname="requirePermission">
<list>
<reflocal="org.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/>
<reflocal="org.acegisecurity.acl.basic.SimpleAclEntry.READ"/>
</list>
</property>
</bean>

    ACL_READ指的是这个Voter对哪些SecurityConfig起作用，我们可以把ACL_READ配置在想要拦截的Method上。比方说我们要拦截readOrder这个方法，以实现ACL控制，可以这样配置。
    orderManager.readOrder=ACL_READ     
    processDomainObjectClass指出哪些DomainObject是要进行ACL校验的。     
    aclManager是一个比较重要的概念，主要负责在权限列表中根据用户和DomainObject取得acl列表。     
    requirePermission指出要进行这个操作必须具备的acl权限，比方说read操作就必须有ADMINISTRATION或READ两个权限。

其实整个过程看下来比较清晰，下面来看一下AclManager如何配置。

<!--=========ACCESSCONTROLLISTLOOKUPMANAGERDEFINITIONS=========-->

<beanid="aclManager"class="org.acegisecurity.acl.AclProviderManager">
<propertyname="providers">
<list>
<reflocal="basicAclProvider"/>
</list>
</property>
</bean>

<beanid="basicAclProvider"class="org.acegisecurity.acl.basic.BasicAclProvider">
<propertyname="basicAclDao">
<reflocal="basicAclExtendedDao"/>
</property>
</bean>

<beanid="basicAclExtendedDao"class="org.acegisecurity.acl.basic.jdbc.JdbcExtendedDaoImpl">
<propertyname="dataSource">
<refbean="dataSource"/>
</property>
</bean>

很明显ACLManager继承了Acegi的一贯风格，Provider可以提供多种取得ACL访问列表的途径，默认的是用basicAclProvider在数据库中取得。既然提到了数据库，那我们就来看一下Acegi默认提供的ACL在数据库里的保存表结构：



    acl_object_identity表存放了所有受保护的domainObject的信息。其中object_identity字段保存了domainObject的class和id，默认的保存格式是：domainClass:domainObjectId。     
    acl_permission就是ACL权限列表了，recipient是用户或角色信息，mask表示了这个用户或角色对这个domainObject的访问权限。注意这些信息的保存格式都是可以根据自己的需要改变的。

这样读取和删除的时候Acegi就能很好的完成拦截工作，但是读取一个List的时候，如何才能把该用户不能操作的domainObject剔除掉呢？这就需要afterInvocationManager来完成这个工作。下面来看下配置：

<!--=============="AFTERINTERCEPTION"AUTHORIZATIONDEFINITIONS===========-->

<beanid="afterInvocationManager"class="org.acegisecurity.afterinvocation.AfterInvocationProviderManager">
<propertyname="providers">
<list>
<reflocal="afterAclCollectionRead"/>
</list>
</property>
</bean>
<!--ProcessesAFTER_ACL_COLLECTION_READconfigurationsettings-->
<beanid="afterAclCollectionRead"class="org.acegisecurity.afterinvocation.BasicAclEntryAfterInvocationCollectionFilteringProvider">
<propertyname="aclManager">
<reflocal="aclManager"/>
</property>
<propertyname="requirePermission">
<list>
<reflocal="org.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/>
<reflocal="org.acegisecurity.acl.basic.SimpleAclEntry.READ"/>
</list>
</property>
</bean>

afterAclCollectionRead会在拦截的方法执行结束的时候执行。主要的作用就是在返回的List中挨个检查domainObject的操作权限，然后根据requirePermission来剔除不符合的domainObject。

4.3 使用RuleEngine设置的ACL规则
在SpringSide里使用了RuleEngine来设置ACL规则，具体规则见
bookstore-sample/resources/rules/drl


五FAQ

5.1 FAQ

    Q:  能否脱离Spring框架来使用Acegi?
    A: 虽然Acegi 没有要求必须使用Spring Framework，但事实上Acegi很大程度上利用了Spring的IOC和AOP,很难脱离Spring的单独使用。     
    Q: Acegi有对xfire的支持吗?
    A: 有,详见http://jira.codehaus.org/browse/XFIRE-389     
    Q: 为何无论怎么设置都返回到登陆页面无法成功登陆?
    A: 检查登陆页面或登陆失败页面是否只有ROLE_ANONYMOUS权限

5.2 Acegi 补习班
要了解Acegi,首先要了解以下几个重要概念： 



    Authentication 
    Authentication对象包含了principal, credentials 和 authorities(authorities要赋予给principal的),同时也可以包含一些附加的认证请求信息,如TCP/IP地址和Session id等。 

    SecurityContextHolder
    SecurityContextHolder包含ThreadLocal私有属性用于存取SecurityContext, SecurityContext包含Authentication私有属性, 看以下一段程序
    public void getSecurityContextInformations() {SecurityContext sc = SecurityContextHolder.getContext();Authentication auth = sc.getAuthentication();Object principal = auth.getPrincipal();if (principal instanceof UserDetails) {//用户密码String password = ((UserDetails) principal).getPassword();//用户名称String username = ((UserDetails) principal).getUsername();//用户权限GrantedAuthority[] authorities = ((UserDetails) principal).getAuthorities();for (int i = 0; i < authorities.length; i++) {String authority = authorities[i].getAuthority();}}Object details = auth.getDetails();if (details instanceof WebAuthenticationDetails) {//用户session idString SessionId = ((WebAuthenticationDetails) details).getSessionId();}}


    AuthenticationManager
    通过Providers验证在当前 ContextHolder中的Authentication对象是否合法。     
    AccessDecissionManager
    经过投票机制来审批是否批准操作     
    RunAsManager
    当执行某个操作时,RunAsManager可选择性地替换Authentication对象     
    Interceptors
    拦截器(如FilterSecurityInterceptor,JoinPoint,MethodSecurityInterceptor等)用于协调授权,认证等操作


CREATETABLEacl_object_identity(
idIDENTITYNOTNULL,
object_identityVARCHAR_IGNORECASE(250)NOTNULL,
parent_objectINTEGER,
acl_classVARCHAR_IGNORECASE(250)NOTNULL,
CONSTRAINTunique_object_identityUNIQUE(object_identity),
FOREIGNKEY(parent_object)REFERENCESacl_object_identity(id)
);
CREATETABLEacl_permission(
idIDENTITYNOTNULL,
acl_object_identityINTEGERNOTNULL,
recipientVARCHAR_IGNORECASE(100)NOTNULL,
maskINTEGERNOTNULL,
CONSTRAINTunique_recipientUNIQUE(acl_object_identity,recipient),
FOREIGNKEY(acl_object_identity)REFERENCESacl_object_identity(id)
);

读书人网 >开源软件

热点推荐

触屏版 | 电脑版

读书人网 m.reader8.net