本文假设你对Acegi其他部分已经比较熟悉。Acegi 的ACL控制是建立在对相应业务方法拦截的基础上的。这里以Acegi自带的contacts例子来说明。
先看看总的配置:
该 拦截器实现了org.aopalliance.intercept.MethodInterceptor接口。在方法被调用之前,拦截器会先调用 AuthenticationManager判断用户身份是否已验证,然后从objectDefinitionSource中获取方法所对应的权限,再调 用AccessDecisionManager来匹配用户权限和方法对应的权限。如果用户没有足够权限调用当前方法,则抛出 AccessDeniedException使方法不能被调用。方法调用后会调用AfterInvocationManager对返回的结果进行再次处 理。下面依次说明。
AccessDecisionManager的配置:
AccessDecisionManager 接口有decide()和support()方法。decide()方法决策是否批准通过即方法是否容许调用,如果没抛出 AccessDeniedException则为允许访问资源,否则拒绝访问。support()方法是根据配置属性和受保护资源的类来判断是否需要对该 资源作出决策判断。
AccessDecisionManager的 decisionVoters属性需要一个或多个Voter(投票者),Voter必须实现AccessDecisionVoter 接口。Voter的工作是去匹配用户已拥有的权限和受保护的资源要求的权限,在该资源有相应权限的情况下,如果匹配则投允许票,否则投反对票。
allowIfAllAbstainDecisions属性表示是否允许所有都弃权时就通过。Voter的实现类RoleVoter在当受保护资源的名字由ROLE_开始时才参与投票。
AccessDecisionManager有三个实现类,功能各不相同:
AffirmativeBased: 当至少有一个Voter投允许票时才通过
UnanimousBased: 没有Voter投反对票时才通过
ConsensusBased: 当所有Voter都投允许票时才通过
下面列出一个Voter的配置:
上面第一个配置里有这么一行:sample.contact.ContactManager.delete=ACL_CONTACT_DELETE
所 以在调用sample.contact.ContactManager.delete这个方法时aclContactDeleteVoter会参与投票, 它会获得sample.contact.Contact这个对象(这个对象从delete方法的参数中获得),然后通过aclManager去获得当前用 户对该Contact实例的ACL权限,最后拿这个权限与我们需要的权限比对,我们配置需要的权限是 org.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION和 org.acegisecurity.acl.basic.SimpleAclEntry.DELETE。如果我们通过aclManager获得的权限包 括这两个配置的权限之一,Voter就投容许票,方法容许调用。如果不包括,那对不起,反对票,AccessDecisionManager就会抛出 AccessDeniedException。方法拒绝调用。
AclManager的配置:
AclManager是整个ACL中一个很核心的概念,它包含了两个方法AclEntry[] getAcls(Object domainInstance)和
AclEntry[] getAcls(Object domainInstance, Authentication authentication)。在了解这两个方法前,我们先了解AclEntry这个对象。AclEntry只是一个接口,系统中一般都是造型为 BasicAclEntry。它包括了这个Entry所保护的domainObject instance(这里是Contact),实际它实现上是以AclObjectIdentity来替代这个domainObject的 (domainClass+domainObjectId);它包括了谁(Recipient)拥有这个domainObject instance以及他所对这个domainObject instance的操作权限(mask)。
一个domainObject instance对应了多个AclEntry,比如一条通讯录张三可以查看,而李四可以管理,一个Contact instance就对应了两个AclEntry,第一个AclEntry包含信息:所保护的domainObject(Contact),谁(张三),权 限(查看);第二个AclEntry包含信息:所保护的domainObject(Contact),谁(李四),权限(管理)。
这样AclManager的两个方法就很好理解了getAcls(Object domainInstance)返回所有这个domainInstance所对应的权限信息,
getAcls(Object domainInstance, Authentication authentication)在第一个方法返回结果的基础上做了过滤,过滤出和authentication(当前用户)相关的权限信息。如果当前用户 是张三,则返回与张三对应的记录。
这样Acegi就会拦截业务方法发挥相应的作用,但是在业务方法返回一个List或是单个 domainObject instance的时候,同样也是需要把用户没有权限查看的domainObject instance过滤掉的,这时就要用afterInvocationManager了, 看配置:
afterAclCollectionRead 会对配置AFTER_ACL_COLLECTION_READ的方法进行拦截,这里是 sample.contact.ContactManager.getAll方法,它会遍历方法返回的domainObject,然后挨个通过 aclManager判断当前用户对domainObject的权限,如果和需要的权限不和,则过滤掉。呵呵,传说中的虎牙子就在此时产生了!
afterAclRead则依次类推。
参考了ss wiki里相关的文档,特别是差沙和cac的文档,写的相当好。另外acegi的代码也是相当的易读。
先看看总的配置:
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.getAll=AFTER_ACL_COLLECTION_READ
- sample.contact.ContactManager.getById=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>
该 拦截器实现了org.aopalliance.intercept.MethodInterceptor接口。在方法被调用之前,拦截器会先调用 AuthenticationManager判断用户身份是否已验证,然后从objectDefinitionSource中获取方法所对应的权限,再调 用AccessDecisionManager来匹配用户权限和方法对应的权限。如果用户没有足够权限调用当前方法,则抛出 AccessDeniedException使方法不能被调用。方法调用后会调用AfterInvocationManager对返回的结果进行再次处 理。下面依次说明。
AccessDecisionManager的配置:
xml 代码
- <bean id="businessAccessDecisionManager" class="org.acegisecurity.vote.AffirmativeBased">
- <property name="allowIfAllAbstainDecisions"><value>falsevalue>property>
- <property name="decisionVoters">
- <list>
- <ref local="roleVoter"/>
- <ref local="aclContactReadVoter"/>
- <ref local="aclContactDeleteVoter"/>
- <ref local="aclContactAdminVoter"/>
- list>
- property>
- bean>
AccessDecisionManager 接口有decide()和support()方法。decide()方法决策是否批准通过即方法是否容许调用,如果没抛出 AccessDeniedException则为允许访问资源,否则拒绝访问。support()方法是根据配置属性和受保护资源的类来判断是否需要对该 资源作出决策判断。
AccessDecisionManager的 decisionVoters属性需要一个或多个Voter(投票者),Voter必须实现AccessDecisionVoter 接口。Voter的工作是去匹配用户已拥有的权限和受保护的资源要求的权限,在该资源有相应权限的情况下,如果匹配则投允许票,否则投反对票。
allowIfAllAbstainDecisions属性表示是否允许所有都弃权时就通过。Voter的实现类RoleVoter在当受保护资源的名字由ROLE_开始时才参与投票。
AccessDecisionManager有三个实现类,功能各不相同:
AffirmativeBased: 当至少有一个Voter投允许票时才通过
UnanimousBased: 没有Voter投反对票时才通过
ConsensusBased: 当所有Voter都投允许票时才通过
下面列出一个Voter的配置:
xml 代码
- <bean id="aclContactDeleteVoter" class="org.acegisecurity.vote.BasicAclEntryVoter">
- <property name="processConfigAttribute"><value>ACL_CONTACT_DELETEvalue>property>
- <property name="processDomainObjectClass"><value>sample.contact.Contactvalue>property>
- <property name="aclManager"><ref local="aclManager"/>property>
- <property name="requirePermission">
- <list>
- <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/>
- <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.DELETE"/>
- <list>
- <property>
- <bean>
上面第一个配置里有这么一行:sample.contact.ContactManager.delete=ACL_CONTACT_DELETE
所 以在调用sample.contact.ContactManager.delete这个方法时aclContactDeleteVoter会参与投票, 它会获得sample.contact.Contact这个对象(这个对象从delete方法的参数中获得),然后通过aclManager去获得当前用 户对该Contact实例的ACL权限,最后拿这个权限与我们需要的权限比对,我们配置需要的权限是 org.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION和 org.acegisecurity.acl.basic.SimpleAclEntry.DELETE。如果我们通过aclManager获得的权限包 括这两个配置的权限之一,Voter就投容许票,方法容许调用。如果不包括,那对不起,反对票,AccessDecisionManager就会抛出 AccessDeniedException。方法拒绝调用。
AclManager的配置:
xml 代码
- <bean id="aclManager" class="org.acegisecurity.acl.AclProviderManager">
- <property name="providers">
- <list>
- <ref local="basicAclProvider"/>
- <list>
- <property>
- <bean>
- <bean id="basicAclProvider" class="org.acegisecurity.acl.basic.BasicAclProvider">
- <property name="basicAclDao"><ref local="basicAclExtendedDao"/><property>
- bean>
- <bean id="basicAclExtendedDao" class="org.acegisecurity.acl.basic.jdbc.JdbcExtendedDaoImpl">
- <property name="dataSource"><ref bean="dataSource"/><property>
- <bean>
AclManager是整个ACL中一个很核心的概念,它包含了两个方法AclEntry[] getAcls(Object domainInstance)和
AclEntry[] getAcls(Object domainInstance, Authentication authentication)。在了解这两个方法前,我们先了解AclEntry这个对象。AclEntry只是一个接口,系统中一般都是造型为 BasicAclEntry。它包括了这个Entry所保护的domainObject instance(这里是Contact),实际它实现上是以AclObjectIdentity来替代这个domainObject的 (domainClass+domainObjectId);它包括了谁(Recipient)拥有这个domainObject instance以及他所对这个domainObject instance的操作权限(mask)。
一个domainObject instance对应了多个AclEntry,比如一条通讯录张三可以查看,而李四可以管理,一个Contact instance就对应了两个AclEntry,第一个AclEntry包含信息:所保护的domainObject(Contact),谁(张三),权 限(查看);第二个AclEntry包含信息:所保护的domainObject(Contact),谁(李四),权限(管理)。
这样AclManager的两个方法就很好理解了getAcls(Object domainInstance)返回所有这个domainInstance所对应的权限信息,
getAcls(Object domainInstance, Authentication authentication)在第一个方法返回结果的基础上做了过滤,过滤出和authentication(当前用户)相关的权限信息。如果当前用户 是张三,则返回与张三对应的记录。
这样Acegi就会拦截业务方法发挥相应的作用,但是在业务方法返回一个List或是单个 domainObject instance的时候,同样也是需要把用户没有权限查看的domainObject instance过滤掉的,这时就要用afterInvocationManager了, 看配置:
xml 代码
- <bean id="afterInvocationManager" class="org.acegisecurity.afterinvocation.AfterInvocationProviderManager">
- <property name="providers">
- <list>
- <ref local="afterAclRead"/>
- <ref local="afterAclCollectionRead"/>
- </list>
- </property>
- </bean>
- <!-- Processes AFTER_ACL_COLLECTION_READ configuration settings -->
- <bean id="afterAclCollectionRead" class="org.acegisecurity.afterinvocation.BasicAclEntryAfterInvocationCollectionFilteringProvider">
- <property name="aclManager"><ref local="aclManager"/></property>
- <property name="requirePermission">
- <list>
- <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/>
- <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.READ"/>
- </list>
- </property>
- </bean>
- <!-- Processes AFTER_ACL_READ configuration settings -->
- <bean id="afterAclRead" class="org.acegisecurity.afterinvocation.BasicAclEntryAfterInvocationProvider">
- <property name="aclManager"><ref local="aclManager"/></property>
- <property name="requirePermission">
- <list>
- <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/>
- <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.READ"/>
- </list>
- </property>
- </bean>
afterAclCollectionRead 会对配置AFTER_ACL_COLLECTION_READ的方法进行拦截,这里是 sample.contact.ContactManager.getAll方法,它会遍历方法返回的domainObject,然后挨个通过 aclManager判断当前用户对domainObject的权限,如果和需要的权限不和,则过滤掉。呵呵,传说中的虎牙子就在此时产生了!
afterAclRead则依次类推。
参考了ss wiki里相关的文档,特别是差沙和cac的文档,写的相当好。另外acegi的代码也是相当的易读。