spring security原理图及其解释（四）

How requests are authorized?

The final servlet filter in the default Spring Security filter chain, FilterSecurityInterceptor, is the filter responsible for coming up with a decision on whether or not a particular request will be accepted or denied. At this point the FilterSecurityInterceptor filter is invoked, the principal has already been authenticated, so the system knows that they are valid users. Remember that the Authentication interface specifies a method (List<GrantedAuthority> getAuthorities()), which returns a list of authorities for the principal. The authorization process will use the information from this method to determine, for a particular request, whether or not the request should be allowed.

在默认的Spring Security filter链中，最后的servlet filter是FilterSecurityInterceptor，它是负责处理这个特殊的request是否被通过。在这种情况下FilterSecurityInterceptor被触发，而且principal已经被验证，所以系统知道他们是可用的用户。我们知道Authentication接口指定了一个方法（List<GrantedAuthority> getAuthorities()），它返回authorities的数组。授权程序就会用这些信息来决定一个特殊的请求会不会被通过。


Smart object-oriented design is pervasive within the Spring Security framework, and authorization decision management is no exception. Recall from our discussion earlier in the chapter that a component known as the access decision manager is responsible for making authorization determinations.

The implementation of AccessDecisionManager is completely configurable using standard Spring Bean binding and references. The default AccessDecisionManager implementation provides an access granting mechanism based on AccessDecisionVoter and vote aggregation.

A voter is an actor in the authorization sequence whose job is to evaluate any or all of the following:

The context of the request for a secured resource (such as URL requesting
IP address)
The credentials (if any) presented by the user
The secured resource being accessed
The configuration parameters of the system, and the resource itself


As you may have guessed from the design of access decision-related objects and interfaces, this portion of Spring Security has been designed so that it can be applicable to authentication and access control scenarios that aren't exclusively in the web domain. We'll encounter voters and access decision managers when we look at method-level security in Chapter 5, Fine-Grained Access Control.

When we put this all together, the overall flow of the "default authentication check for web requests" is similar to the following diagram:


注意上面是loop voters

Configuration of access decision aggregation

Spring Security does actually allow configuration of the AccessDecisionManager in the security namespace. The access-decision-manager-ref attribute on the <http> element allows you to specify a Spring Bean reference to an implementation of AccessDecisionManager. Spring Security ships with three implementations of this interface, all in the o.s.s.access.vote package:



第一个有一个同意就通过；第二个票数多的通过；第三全得通过才能通过。

Configuring to use a UnanimousBased access decision manager

If we want to modify our application to use the UnanimousBased access decision manager, we'd require two modifications. Let's add the access-decision-manager-ref attribute to the <http> element:

如果我们想用UnanimousBased Manager，我们需要修改两个地方。首先添加access-decision-manager-ref元素：

<http auto-config="true" access-decision-manager-ref="unanimousBased">

This is a standard Spring Bean reference, so this should correspond to the id attribute of a bean. We'll go on and declare the bean (in dogstore-base.xml) now, with the same ID we referenced:

这是一个标准Spring Bean,所以他应该对应一个bean id。现在我们声明这个bean：

<bean class="org.springframework.security.access.vote.UnanimousBased"
id="unanimousBased">
<property name="decisionVoters">
<list>
<ref bean="roleVoter"/>
<ref bean="authenticatedVoter"/>
</list>
</property>
</bean>
<bean class="org.springframework.security.access.vote.RoleVoter"
id="roleVoter"/>
<bean class="org.springframework.security.access.vote.
AuthenticatedVoter" id="authenticatedVoter"/>

You may be wondering what the decisionVoters property is about. This property is auto-configured until we declare our own AccessDecisionManager. The default AccessDecisionManager requires us to declare the list of voters who are consulted to arrive at the authentication decisions. The two voters listed here are the defaults supplied by the security namespace configuration.

你或许会奇怪decisionVoters是干什么的。当我们声明了AccessDecisionManager的时候，这个属性是自动装配的。默认的AccessDecisionManager要求我们声明一个系列的voter，用它们来决定是否验证通过。这里列出的两个voter是spring默认提供的。

Unfortunately, Spring Security doesn't come supplied with a wide variety of voters, but it is trivial to implement the AccessDecisionVoter interface and add our own implementation. We'll see an example of this in Chapter 6.

不幸的是Spring Security没有为我们提供需要不同的voter实现，但是我们可以实现AccessDecisionVoter来添加我们的实现。

The two voter implementations that we reference here do the following: