《Spring Security3》第二章第三部分翻译（中）
请求是怎样被授权的？
在Spring Security的默认过滤器链中，最后一个servelt过滤器是FilterSecurityInterceptor，它的作用是判断一个特定的请求是被允许还是被拒绝。在FilterSecurityInterceptor被触发的时候，安全实体已经经过了认证，所以系统知道他们是合法的用户。（其实也有可能是匿名的用户，译者注）。请记住的一点是，Authentication提供了一个方法（(List<GrantedAuthority>
getAuthorities()），将会返回当前安全实体的一系列权限列表。授权的过程将使用这个方法提供的信息来决定一个特定的请求是否会被允许。
需要记住的是授权是一个二进制的决策——一个用户要么有要么没有访问一个受保护资源的权限。在授权中，没有模棱两可的情景。
在Spring Security中，良好的面向对象设计随处可见，在授权决策管理中也不例外。回忆一下我们在本章前面的讨论，一个名为访问控制决策器（access decision manager）的组件负责作出授权决策。
在Spring Security中，o.s.s.access.AccessDecisionManager接口定义了两个简单而合理的方法，它们能够用于请求的决策判断流程：
<!---->l <!---->supports：这个逻辑操作实际上包含两个方法，它们允许AccessDecisionManager的实现类判断是否支持当前的请求。
<!---->l <!---->decide：基于请求的上下文和安全配置，允许AccessDecisionManager去核实访问是否被允许以及请求是否能够被接受。decide方法实际上没有返回值，通过抛出异常来表明对请求访问的拒绝。
与AuthenticationException及其子类在认证过程中的使用很类似，特定类型的异常能够表明应用在授权决策中的不同处理结果。o.s.s.access.AccessDeniedException是在授权领域里最常见的异常，因此值得过滤器链进行特殊的处理。我们将在第六章中详细介绍它的高级配置。
AccessDecisionManager是能够通过标准的Springbean绑定和引用实现完全的自定义配置。AccessDecisionManager的默认实现提供了一个基于AccessDecisionVoter接口和投票集合的授权机制。
投票器（voter）是在授权过程中的一个重要角色，它的作用是评估以下的内容：
<!---->l <!---->要访问受保护资源的请求所对应上下文（如URL请求的IP地址）；
<!---->l <!---->用户的凭证信息（如果存在的话）；
<!---->l <!---->要试图访问的受保护资源；
<!---->l <!---->系统的配置以及要访问资源本身的配置参数。
AccessDecisionManager还会负责传递要请求资源的访问声明信息（在代码中为ConfigAttribute接口的实现类）给投票器。在web URL的请求中，投票器将会得到资源的访问声明信息。如果看一下我们配置文件中非常基础的拦截声明，我们能够看到ROLE_USER被设置为访问配置并用于用户试图访问的资源：
<intercept-url pattern="/*"access="ROLE_USER"/>
页:
[1]