Spring Security（三十）：9.5 Access-Control (Authorization) in Spring Security

The main interface responsible for making access-control decisions in Spring Security is the AccessDecisionManager. It has a decide method which takes an Authentication object representing the principal requesting access, a "secure object" (see below) and a list of security metadata attributes which apply for the object (such as a list of roles which are required for access to be granted).

負責在Spring Security中進行訪問控制決策的主界面是AccessDecisionManager。它有一個decision方法，它接受一個表示請求訪問的主體的Authentication對象，一個「安全對象」（見下文）和一個適用於該對象的安全元數據屬性列表（例如訪問所需的角色列表）被授予）。

9.5.1 Security and AOP Advice

If you’re familiar with AOP, you’d be aware there are different types of advice available: before, after, throws and around. An around advice is very useful, because an advisor can elect whether or not to proceed with a method invocation, whether or not to modify the response, and whether or not to throw an exception. Spring Security provides an around advice for method invocations as well as web requests. We achieve an around advice for method invocations using Spring’s standard AOP support and we achieve an around advice for web requests using a standard Filter.

若是您熟悉AOP，您會發現有不一樣類型的建議可用：以前，以後，投擲和周圍。 around建議很是有用，由於顧問能夠選擇是否繼續進行方法調用，是否修改響應，以及是否拋出異常。 Spring Security爲方法調用和Web請求提供了周圍的建議。咱們使用Spring的標準AOP支持實現方法調用的周圍建議，並使用標準Filter實現Web請求的周圍建議。

 

For those not familiar with AOP, the key point to understand is that Spring Security can help you protect method invocations as well as web requests. Most people are interested in securing method invocations on their services layer. This is because the services layer is where most business logic resides in current-generation Java EE applications. If you just need to secure method invocations in the services layer, Spring’s standard AOP will be adequate. If you need to secure domain objects directly, you will likely find that AspectJ is worth considering.

對於那些不熟悉AOP的人來講，要理解的關鍵是Spring Security能夠幫助您保護方法調用以及Web請求。大多數人都對在服務層上保護方法調用感興趣。這是由於服務層是大多數業務邏輯駐留在當前一代Java EE應用程序中的地方。若是您只須要在服務層中保護方法調用，那麼Spring的標準AOP就足夠了。若是您須要直接保護域對象，您可能會發現AspectJ值得考慮。

 

You can elect to perform method authorization using AspectJ or Spring AOP, or you can elect to perform web request authorization using filters. You can use zero, one, two or three of these approaches together. The mainstream usage pattern is to perform some web request authorization, coupled with some Spring AOP method invocation authorization on the services layer.

您能夠選擇使用AspectJ或Spring AOP執行方法受權，也能夠選擇使用過濾器執行Web請求受權。您能夠將這些方法中的零個，一個，兩個或三個一塊兒使用。主流使用模式是執行一些Web請求受權，再加上服務層上的一些Spring AOP方法調用受權。

9.5.2 Secure Objects and the AbstractSecurityInterceptor

So what is a "secure object" anyway? Spring Security uses the term to refer to any object that can have security (such as an authorization decision) applied to it. The most common examples are method invocations and web requests.

那麼什麼是「安全對象」呢？ Spring Security使用該術語來引用能夠對其應用安全性（例如受權決策）的任何對象。最多見的示例是方法調用和Web請求。

 

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的子類。重要的是，在調用AbstractSecurityInterceptor時，若是主體已通過身份驗證，則SecurityContextHolder將包含有效的身份驗證。

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

AbstractSecurityInterceptor爲處理安全對象請求提供了一致的工做流，一般：

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），並具備徹底透明性。