Each supported secure object type has its own interceptor class, which is a subclass of AbstractSecurityInterceptor. Importantly, by the time the AbstractSecurityInterceptor is called, the SecurityContextHolder will contain a valid Authentication if the principal has been authenticated.

AbstractSecurityInterceptor provides a consistent workflow for handling secure object requests, typically:

1. Look up the "configuration attributes" associated with the present request
   查找与当前请求关联的“配置属性”
2. Submitting the secure object, current Authentication and configuration attributes to the AccessDecisionManager for an authorization decision 
   将安全对象，当前身份验证和配置属性提交给AccessDecisionManager以进行授权决策
3. Optionally change the Authentication under which the invocation takes place 
   （可选）更改进行调用的身份验证
4. Allow the secure object invocation to proceed (assuming access was granted)  
   允许安全对象调用继续（假设已授予访问权限）
5. Call the AfterInvocationManager if configured, once the invocation has returned. If the invocation raised an exception, the AfterInvocationManager will not be invoked. 
   调用返回后，调用AfterInvocationManager（如果已配置）。如果调用引发异常，则不会调用AfterInvocationManager。

What are Configuration Attributes?

A "configuration attribute" can be thought of as a String that has special meaning to the classes used by AbstractSecurityInterceptor. They are represented by the interface ConfigAttribute within the framework. They may be simple role names or have more complex meaning, depending on the how sophisticated the AccessDecisionManager implementation is. The AbstractSecurityInterceptor is configured with a SecurityMetadataSource which it uses to look up the attributes for a secure object. Usually this configuration will be hidden from the user.

“配置属性”可以被认为是对AbstractSecurityInterceptor使用的类具有特殊含义的String。它们由框架内的接口ConfigAttribute表示。它们可能是简单的角色名称，也可能具有更复杂的含义，具体取决于AccessDecisionManager实现的复杂程度。 AbstractSecurityInterceptor配置了SecurityMetadataSource，用于查找安全对象的属性。通常，此配置将对用户隐藏。

 

 Configuration attributes will be entered as annotations on secured methods or as access attributes on secured URLs. For example, when we saw something like <intercept-url pattern='/secure/**' access='ROLE_A,ROLE_B'/> in the namespace introduction, this is saying that the configuration attributes ROLE_A and ROLE_B apply to web requests matching the given pattern. In practice, with the default AccessDecisionManager configuration, this means that anyone who has a GrantedAuthority matching either of these two attributes will be allowed access. Strictly speaking though, they are just attributes and the interpretation is dependent on the AccessDecisionManager implementation. The use of the prefix ROLE_ is a marker to indicate that these attributes are roles and should be consumed by Spring Security’s RoleVoter. This is only relevant when a voter-based AccessDecisionManager is in use. We’ll see how the AccessDecisionManager is implemented in the authorization chapter.

配置属性将作为安全方法的注释输入，或作为安全URL的访问属性输入。例如，当我们在命名空间简介中看到类似<intercept-url pattern ='/ secure / **'access ='ROLE_A，ROLE_B'/>的内容时，这就是说配置属性ROLE_A和ROLE_B适用于Web请求匹配给定的模式。实际上，使用默认的AccessDecisionManager配置，这意味着任何具有与这两个属性中的任何一个匹配的GrantedAuthority的人都将被允许访问。严格来说，它们只是属性，解释依赖于AccessDecisionManager实现。前缀ROLE_的使用是一个标记，表示这些属性是角色，应该由Spring Security的RoleVoter使用。这仅在使用基于选民的AccessDecisionManager时才有意义。我们将在授权章节中看到AccessDecisionManager的实现方式。

RunAsManager

Assuming AccessDecisionManager decides to allow the request, the AbstractSecurityInterceptor will normally just proceed with the request. Having said that, on rare occasions users may want to replace the Authentication inside the SecurityContext with a different Authentication, which is handled by the AccessDecisionManager calling a RunAsManager. This might be useful in reasonably unusual situations, such as if a services layer method needs to call a remote system and present a different identity. Because Spring Security automatically propagates security identity from one server to another (assuming you’re using a properly-configured RMI or HttpInvoker remoting protocol client), this may be useful.

假设AccessDecisionManager决定允许请求，AbstractSecurityInterceptor通常只会继续请求。话虽如此，在极少数情况下，用户可能希望使用不同的身份验证替换SecurityContext中的身份验证，该身份验证由AccessDecisionManager调用RunAsManager来处理。这在合理的异常情况下可能很有用，例如服务层方法需要调用远程系统并呈现不同的身份。因为Spring Security会自动将安全标识从一个服务器传播到另一个服务器（假设您使用的是正确配置的RMI或HttpInvoker远程协议客户端），这可能很有用。

AfterInvocationManager

Following the secure object invocation proceeding and then returning - which may mean a method invocation completing or a filter chain proceeding - the AbstractSecurityInterceptor gets one final chance to handle the invocation. At this stage the AbstractSecurityInterceptor is interested in possibly modifying the return object. We might want this to happen because an authorization decision couldn’t be made "on the way in" to a secure object invocation. Being highly pluggable, AbstractSecurityInterceptor will pass control to an AfterInvocationManager to actually modify the object if needed. This class can even entirely replace the object, or throw an exception, or not change it in any way as it chooses. The after-invocation checks will only be executed if the invocation is successful. If an exception occurs, the additional checks will be skipped.

在安全对象调用继续进行然后返回 - 这可能意味着方法调用完成或过滤器链继续进行 - AbstractSecurityInterceptor获得最后一次机会来处理调用。在此阶段，AbstractSecurityInterceptor可能会修改返回对象。我们可能希望这种情况发生，因为无法在安全对象调用的“途中”进行授权决策。作为高度可插拔的，AbstractSecurityInterceptor会将控制权传递给AfterInvocationManager，以便在需要时实际修改对象。这个类甚至可以完全替换对象，或抛出异常，或者不以任何方式更改它。只有在调用成功时才会执行调用后检查。如果发生异常，将跳过其他检查。

 

AbstractSecurityInterceptor and its related objects are shown in Figure 9.1, “Security interceptors and the "secure object" model”

AbstractSecurityInterceptor及其相关对象如图9.1所示，“安全拦截器和”安全对象“模型”

 

Figure 9.1. Security interceptors and the "secure object" model

图9.1。安全拦截器和“安全对象”模型

 

Extending the Secure Object Model

Only developers contemplating an entirely new way of intercepting and authorizing requests would need to use secure objects directly. For example, it would be possible to build a new secure object to secure calls to a messaging system. Anything that requires security and also provides a way of intercepting a call (like the AOP around advice semantics) is capable of being made into a secure object. Having said that, most Spring applications will simply use the three currently supported secure object types (AOP Alliance MethodInvocation, AspectJ JoinPoint and web request FilterInvocation) with complete transparency.

只有开发人员考虑采用全新的拦截和授权请求方式才需要直接使用安全对象。例如，可以构建新的安全对象以保护对消息传递系统的调用。任何需要安全性并且还提供拦截调用的方法（如围绕建议语义的AOP）都能够成为安全对象。话虽如此，大多数Spring应用程序将只使用三种当前支持的安全对象类型（AOP Alliance MethodInvocation，AspectJ JoinPoint和Web请求FilterInvocation），并具有完全透明性。