1、三种表决方式，默认是 一票制AffirmativeBased
public interface AccessDecisionManager {
/**
* 通过传递的参数来决定用户是否有访问对应受保护对象的权限
* @param authentication 当前正在请求受包含对象的Authentication
* @param object 受保护对象，其可以是一个MethodInvocation、JoinPoint或FilterInvocation。
* @param configAttributes 与正在请求的受保护对象相关联的配置属性
*/
void decide(Authentication authentication, Object object, Collection<ConfigAttribute> configAttributes)
throws AccessDeniedException, InsufficientAuthenticationException;
/*表示当前AccessDecisionManager是否支持对应的ConfigAttribute*/
boolean supports(ConfigAttribute attribute);
/*表示当前AccessDecisionManager是否支持对应的受保护对象类型*/
boolean supports(Class<?> clazz);
}
decide()方法用于决定authentication是否符合受保护对象要求的configAttributes。
supports(ConfigAttribute attribute)方法是用来判断AccessDecisionManager是否能够处理对应的ConfigAttribute的。
supports(Class<?> clazz)方法用于判断配置的AccessDecisionManager是否支持对应的受保护对象类型。
Spring Security内置了三个基于投票的AccessDecisionManager实现类，它们分别是AffirmativeBased、ConsensusBased和UnanimousBased。
AffirmativeBased的逻辑是这样的：
（1）只要有AccessDecisionVoter的投票为ACCESS_GRANTED则同意用户进行访问；
（2）如果全部弃权也表示通过；
（3）如果没有一个人投赞成票，但是有人投反对票，则将抛出AccessDeniedException。
ConsensusBased的逻辑是这样的：
（1）如果赞成票多于反对票则表示通过。
（2）反过来，如果反对票多于赞成票则将抛出AccessDeniedException。
（3）如果赞成票与反对票相同且不等于0，并且属性allowIfEqualGrantedDeniedDecisions的值为true，则表示通过，否则将抛出异常AccessDeniedException。参数allowIfEqualGrantedDeniedDecisions的值默认为true。
（4）如果所有的AccessDecisionVoter都弃权了，则将视参数allowIfAllAbstainDecisions的值而定，如果该值为true则表示通过，否则将抛出异常AccessDeniedException。参数allowIfAllAbstainDecisions的值默认为false。
UnanimousBased的逻辑与另外两种实现有点不一样，另外两种会一次性把受保护对象的配置属性全部传递给AccessDecisionVoter进行投票，而UnanimousBased会一次只传递一个ConfigAttribute给AccessDecisionVoter进行投票。这也就意味着如果我们的AccessDecisionVoter的逻辑是只要传递进来的ConfigAttribute中有一个能够匹配则投赞成票，但是放到UnanimousBased中其投票结果就不一定是赞成了。UnanimousBased的逻辑具体来说是这样的：
（1）如果受保护对象配置的某一个ConfigAttribute被任意的AccessDecisionVoter反对了，则将抛出AccessDeniedException。
（2）如果没有反对票，但是有赞成票，则表示通过。
（3）如果全部弃权了，则将视参数allowIfAllAbstainDecisions的值而定，true则通过，false则抛出AccessDeniedException。
配置方式
投票器列表 – decisionVoters属性
默认的AccessDecisionManager要求我们配置投票器的一个属性，decisionVoters属性，它们将会在认证决策时用到。
在我们不声明AccessDecisionManager时，decisionVoters属性是自动配置的，配置的是1-多个投票器。
2、两种默认投票器：RoleVoter和AuthenticatedVoter
2.1、RoleVoter
RoleVoter是Spring Security内置的一个AccessDecisionVoter，其会将ConfigAttribute简单的看作是一个角色名称，在投票的时如果拥有该角色即投赞成票。
如果ConfigAttribute是以“ROLE_”开头的，则将使用RoleVoter进行投票。
当用户拥有的权限中有一个或多个能匹配受保护对象配置的以“ROLE_”开头的ConfigAttribute时其将投赞成票；
如果用户拥有的权限中没有一个能匹配受保护对象配置的以“ROLE_”开头的ConfigAttribute，则RoleVoter将投反对票；
如果受保护对象配置的ConfigAttribute中没有以“ROLE_”开头的，则RoleVoter将弃权。
2.2、AuthenticatedVoter
AuthenticatedVoter也是Spring Security内置的一个AccessDecisionVoter实现。其主要用来区分匿名用户、通过Remember-Me认证的用户和完全认证的用户。
完全认证的用户是指由系统提供的登录入口进行成功登录认证的用户。
AuthenticatedVoter可以处理的ConfigAttribute有IS_AUTHENTICATED_FULLY、IS_AUTHENTICATED_REMEMBERED和IS_AUTHENTICATED_ANONYMOUSLY。
如果ConfigAttribute不在这三者范围之内，则AuthenticatedVoter将弃权。
否则将视ConfigAttribute而定，
如果ConfigAttribute为 IS_AUTHENTICATED_ANONYMOUSLY，则不管用户是匿名的还是已经认证的都将投赞成票；
如果ConfigAttribute为 IS_AUTHENTICATED_REMEMBERED，则仅当用户是由Remember-Me自动登录，或者是通过登录入口进行登录认证时才会投赞成票，否则将投反对票；
如果ConfigAttribute为 IS_AUTHENTICATED_FULLY时， 则仅当用户是通过登录入口进行登录的才会投赞成票，否则将投反对票。
AuthenticatedVoter是通过AuthenticationTrustResolver的isAnonymous()方法和isRememberMe()方法来判断SecurityContextHolder持有的Authentication是否为AnonymousAuthenticationToken或RememberMeAuthenticationToken的，
即是否为IS_AUTHENTICATED_ANONYMOUSLY和IS_AUTHENTICATED_REMEMBERED。
2.3、支持自定义投票器：实现AccessDecisionVoter接口并在配置中添加我们的实现
3、使用 Spring 表达式语言配置访问控制
3.1、配置 use-expressions=”true”
添加后将要修改用来进行拦截器规则声明的 access 属性，改为 SpEL 表达式。 SpEL 允许使用特定的访问控制规则表达式语言。
与简单的字符串如 ROLE_USER 不同，配置文件可以指明表达式语言触发方法调用、引用系统属性、计算机值等等。
SpEL 的语法与其他的表达式语言很类似，如在 Tapestry 等框架中用到的 Object Graph Notation Language (OGNL) ，以及用于 JSP 和 JSF 的 Unified Expression Language 。
3.2、使用表达式后的role处理
如果你通过使用 use-expressions 属性启用了 SpEL 表达式访问控制，将会使得自动配置的 RoleVoter 实效，后者能够使用角色的声明，正如在前面的例子所见到的那样：
|
<intercept-url pattern=”/*” access=”ROLE_USER”/> |
这意味着如果你仅仅想通过角色来过滤请求的话，访问控制声明必要要进行修改。幸运的的是，这已经被充分考虑过了，一个 SpEL 绑定的方法 hasRole 能够检查角色。
3.3、使用表达式的一些例子
