本文假设你对Acegi其他部分已经比较熟悉。Acegi 的ACL控制是建立在对相应业务方法拦截的基础上的。这里以Acegi自带的contacts例子来说明。
先看看总的配置：
<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的配置：
<bean id="businessAccessDecisionManager" class="org.acegisecurity.vote.AffirmativeBased">
<property name="allowIfAllAbstainDecisions"><value>false</value></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的配置：
<bean id="aclContactDeleteVoter" class="org.acegisecurity.vote.BasicAclEntryVoter">
<property name="processConfigAttribute"><value>ACL_CONTACT_DELETE</value></property>
<property name="processDomainObjectClass"><value>sample.contact.Contact</value></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的配置：
<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了，
看配置：
<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的代码也是相当的易读。