使用基於方法的安全性保護 Java 類實例
這期共分三部分的系列文章介紹了如何使用 Acegi 安全系統保護 Java 企業 應用程序。系列文章的 第 1 部分 簡單介紹了 Acegi 並解釋如何使用其內置的 安全過濾器實現一個簡單的、基於 URL 的安全系統。第 2 部分 介紹了如何編 寫訪問控制策略並將其保存到一個 LDAP 目錄服務器，以及如何配置 Acegi 來 與目錄服務器進行交互，從而實現訪問控制策略。第 3 部分（也是本系列的最 後一篇文章）將演示如何在企業應用程序中使用 Acegi 保護對 Java 類實例的 訪問。
首先我將介紹何時需要對 Java 類訪問進行保護，包括文中引用的兩個典型 企業應用程序場景。之後，我將解釋 Spring 的反轉控制（IOC）框架如何創建 可從 JSP 或 servlet 訪問的 Java 類實例。我還將介紹有關 bean 代理 的重 要概念，Spring 正是使用它過濾對 Java 類的訪問。最後，我將介紹如何對 Acegi 的方法安全性攔截器進行配置以控制對 Java 類的訪問。我將對 第 2 部 分 中的示例程序進行增強，為實現安全的 Java 對象提供支持，從而結束本系 列的最後一篇文章。
由於本文的討論構建在本系列前兩部分的內容之上，因此會經常引用到 第 1 部分 和 第 2 部分 中的討論和示例。因此，在繼續閱讀本文之前，在其他浏覽 器窗口中打開前兩期文章將有助於理解本文內容。
保護 Java 類的用例
您可能還記得，我曾在本系列的開頭部分簡單介紹了 企業應用程序安全性。 在那次討論中我曾提到過一種場景，其中 URL 安全性並不能完全滿足這種場景 的安全需求：
假設有這樣一個 PDF 文檔，其中包含了某制造業公司生產的特定產品的數據 。文檔的一部分包含了設計數據，將由公司設計部分進行編輯和更新。文檔另一 部分包含生產經理將使用到的生產數據。對於此類場景，需要實現更加細粒度的 安全性，對文檔的不同部分應用不同的訪問權限。
在繼續閱讀之前，請考慮更多的應用程序場景，除了實現 URL 安全性以外， 這些場景還要求您對單獨的類訪問進行保護。
業務自動化
業務自動化應用程序中的工作流由多個流程組成。例如，病理學實驗室中執 行血液測試的工作流由若干個步驟組成，其中每個步驟可看作一個業務流程：
工作人員從病人處采集血液樣本並為其分配一個 ID。
實驗室技術人員對樣本進行必要的測試並准備測試結果。
由具備相應資格的病理學專家根據測試結果編寫測試報告。
很明顯，每個流程分別由單獨的授權用戶執行。未授權的用戶則無權執行流 程。例如，實驗室研究人員只負責准備試驗結果，而無權編寫測試報告。
幾乎所有的業務自動化應用程序都普遍使用授權的業務流程。通常，每個業 務流程被實現為一個 Java 類，並且需要使用合適的訪問控制策略對所有類實施 保護。
企業對企業（Business-to-business）集成
Business-to-business (B2B) 集成指一種常見的場景，其中的兩個企業實體 需要彼此公開各自的特定功能。例如，賓館可能向旅游公司公開其房間預訂功能 ，而後者使用該功能為游客預訂空閒的房間。作為合作伙伴的旅游公司可能具有 一個特定的訂房率。在這個場景中，賓館的訂房系統必須先對旅游公司進行身份 驗證，然後才能允許他們訪問所選擇的類，以便按照特定的訂房率進行房間預訂 。
使用 Spring 創建 Java 對象
現在您已經了解了對 Java 類示例的訪問進行保護的重要性。在介紹能夠實 現更高級安全性的 Acegi 新功能之前，我將引導您回顧 Spring 框架的幾個關 鍵特性，您需要了解這些內容才能繼續後文的示例。
首先對一些 Java 類進行配置並執行實例化。第 1 部分 曾介紹過，Java 類 在 Spring 的 XML 配置文件中進行配置。在 Spring 配置文件中配置 Java 類 的過程與 Acegi 過濾器的配置過程完全相同，因此這裡不多做介紹。相反，我 們將查看清單 1，它展示了名為 publicCatalog 的 bean 的配置：
清單 1. Acegi XML 配置文件
<beans>
<bean id="publicCatalog"
class="com.catalog.PublicCatalog" />
<!--Other bean tags -->
<beans>
了解 Spring 的 IOC 框架如何從 XML 配置文件讀取 Java 類信息以及如何 進行實例化，這一點非常重要。您可能還記得，我在系列文章的 第 1 部分 中 使用一個 web.xml 文件配置 <listener> 標記，它指向名為 ContextLoaderListener 的類。ContextLoaderListener 裝載 Spring 的 IOC 框架並創建 Java 對象。您可以參考 第 1 部分的清單 8 查看全部內容。圖 1 也對此進行了描述：
圖 1. 裝載 Spring 的 IOC 框架並創建 Java 對象
現在我們將詳細討論這些步驟：
當初始化 Acegi 應用程序時，servlet 容器（本例中為 Apache Tomcat）創 建了一個 servlet 上下文，其中保存了有關應用程序資源的信息，例如 JSP 頁 面和類。
servlet 容器通知 ContextLoaderListener 類應用程序正在啟動。
ContextLoaderListener 類創建一個 Web 應用程序上下文以保存應用程序中 特定於 Spring 的資源信息。借助 Spring 的 IOC 框架，您可以裝載自己的自 定義應用程序上下文。要創建應用程序上下文，將使用名為 ContextLoader 的 上下文裝載器類裝載應用程序上下文。
如果應用程序不需要定義自己的應用程序上下文，則可以使用名為 XMLWebApplicationContext 的類，它是 Spring 框架的一部分並提供可處理 Spring XML 配置文件的功能。Acegi 應用程序使用的是 Spring 的 XML 配置文 件，因此本文僅討論由 XMLWebApplicationContext 類表示的應用程序上下文。 在本例中，上下文裝載器對 XMLWebApplicationContext 類進行實例化，後者表 示您的 Acegi 應用程序的應用程序上下文。上下文裝載器還在 Web 應用程序上 下文中設置 servlet 上下文（於步驟 1 中創建）的引用。
XMLWebApplicationContext 類對 XML 配置文件進行解析，獲得關於 Java 類的信息並將信息裝載到其他內部對象中。
XMLWebApplicationContext 類對 XML 配置文件中指定的所有 Java 類進行 實例化。XMLWebApplicationContext 類檢查 XML 配置文件中經過配置的 Java bean 是否依賴其他的 Java 對象。如果是的話，XMLWebApplicationContext 類 將首先對其他 bean 所依賴的 bean 進行實例化。通過這種方式， XMLWebApplicationContext 類創建了 XML 配置文件中定義的所有 bean 的實例 。（注意，步驟 6 假定 XML 配置文件中所有 bean 都不要進行保護，稍後一節 將介紹步驟 5 和步驟 6 之間執行的額外步驟，從而保護對此處創建的 Java bean 的訪問）。
XMLWebApplicationContext 類將所有 bean 保存在一個數組中。
您現在已了解到如何從 XML 配置文件中裝載 bean 定義並創建 Java 類的實 例。接下來，我將向您介紹 Spring bean 代理並解釋它對於保護 Java 類實例 的重要性。
使用 bean 代理
上一節討論了 Spring 的 IOC 框架對 Java 對象進行實例化。要保護對 Java 對象的訪問，Spring 的 IOC 框架使用了 bean 代理 的概念。本節首先介 紹如何配置 bean 代理，然後演示 Spring 的 IOC 框架如何創建代理對象。
為 Java 對象配置代理
如果希望創建 bean 代理，Spring IOC 框架要求您對代理創建器 bean 的實 例進行配置。Spring 的 IOC 框架使用代理創建器創建代理對象。清單 2 為代 理創建器 bean 的配置文件，用於保護名為 privateCatalog 的 Java 對象：
清單 2. 代理 bean 配置
<bean id="proxyCreator"
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCr eator">
<property name="beanNames">
<list>
<value>privateCatalog</value>
<!--Names of other beans to be proxied -->
</list>
</property>
<property name="interceptorNames">
<list>
<value>privateCatalogSecurityInterceptor</value>
</list>
</property>
</bean>
如清單 2 所示，<bean> 標記具有一個 class 屬性，其值為 org.springframework.aop.framework.autoproxy. BeanNameAutoProxyCreator 。BeanNameAutoProxyCreator 類是 Spring IOC 框架的一部分，可以自動創建 bean 代理。Spring 框架提供了 BeanPostProcessor 接口，它提供了一種可擴 展機制，允許應用程序編寫自己的邏輯來創建 bean 代理。Spring 的 BeanNameAutoProxyCreator 類實現了 BeanPostProcessor 接口並提供所有必需 的代理創建邏輯來保護 Java 類。因此，本文中您無需實現 BeanPostProcessor 接口。
在創建 bean 代理時，BeanNameAutoProxyCreator 類為所有由 beanNames 屬性定義的 bean 創建代理（參見 清單 2 中 <bean> 標記的第一個 <property> 子元素）。beanNames 屬性在 <list> 標記中包含一 個 bean 名稱列表。在 清單 2 中，我只對希望為之創建代理的 privateCatalog bean進行了配置。
現在查看 清單 2 中 <bean> 標記的第二個 <property> 子元 素。它指定了名為 interceptorNames 的代理，它將一個或多個攔截器的名稱封 裝起來。我將在後文詳細討論攔截器概念。現在，只需了解攔截器可以攔截用戶 並在用戶訪問 bean 之前實現訪問控制策略。
現在，您已了解了如何對希望進行保護的 bean 配置代理。接下來，您將了 解 Spring 的 IOC 框架如何在內部為應用程序的 bean 創建代理對象。
Spring IOC 發揮效用
在 “使用 Spring 創建 Java 對象” 的步驟 5 和步驟 6 中，您了解了 XMLWebApplicationContext 類如何從 XML 配置文件中讀取 bean 定義並隨後創 建 bean 實例。在創建 bean 實例之前，XMLWebApplicationContext 類將檢查 XML 配置文件是否包含任何代理創建器 bean（即實現 BeanPostProcessor 接口 的 bean）配置。如果存在該 bean，它將要求代理創建器為您希望進行保護的 bean 創建 bean 代理。
現在考慮代理創建器如何在內部創建代理對象：
代理創建器（即 BeanNameAutoProxyCreator 類）裝載 清單 2 中配置的 beanNames 屬性文件中指定的所有 bean 名稱。
代理創建器使用 bean 名稱裝載各自的 Java 類，這些類使用了每個 bean 定義的 class 屬性。
代理創建器創建 清單 2 所示的 interceptorNames 屬性中指定的攔截器的 實例。
最後，代理創建器創建一個 Cglib2AopProxy 類的實例，將所有 bean 名稱 （步驟 2）和攔截器（步驟 3）傳遞到 Cglib2AopProxy 類。Cglib2AopProxy 類是 Spring 框架的一部分並用於生成動態代理對象。在本例中， Cglib2AopProxy 類將創建安全 bean 訪問控制所需的代理對象。
Cglib2AopProxy 類實現了兩個名為 AOPProxy 和 MethodInterceptor 的接 口。AOPProxy 接口由 Spring 框架提供，表示您希望進行代理的實際 bean，因 此它與您的 bean 公開相同的方法。MethodInterceptor 接口也源於 AOP 框架 ，它包含的方法可以在用戶試圖訪問您已執行代理的 bean 時接受控制權。這意 味著 MethodInterceptor 接口處理來自用戶的請求以訪問執行過代理的 bean。 由於 Cglib2AopProxy 類同時實現了 AOPProxy 和 MethodInterceptor 接口， 因此它提供了完整的功能，既可以提供經過代理的 bean，也可以處理用戶請求 以訪問代理 bean。
執行完前面的步驟後，您現在具有了所需的代理對象。因此 XMLWebApplicationContext 類將安全 bean 的代理（而不是實際的 bean）保存 在 “使用 Spring 創建 Java 對象” 的步驟 7 中的同一個數組中。
訪問執行過代理的 Java 對象
在前面的幾節中，您了解了 Spring 如何創建公有 bean 和私有 bean。出於 本文的目的，您可將公有 bean 視為使用代理保護的不安全的私有 bean。現在 我們來看一下客戶機應用程序為訪問公有 bean 和私有 bean 而必須遵循的一系 列步驟。
清單 3 展示了 publicCatalog 和 privateCatalog 兩個 bean 的 XML 配置 。publicCatalog bean 意味著公共訪問，因此不需要使用 bean 代理。 privateCatalog bean 意味著只能由指定用戶訪問，因此必須加以保護。我在清 單 3 中包含了 privateCatalog bean 的 bean 代理配置：
清單 3. publicCatalog 和 privateCatalog bean 的 XML 配置
<beans>
<bean id="publicCatalog" class="sample.PublicCatalog"/>
<bean id="privateCatalog" class="sample.PrivateCatalog"/>
<!-- proxy configuration for privateCatalog bean -->
<bean id="proxyCreator"
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCr eator">
<property name="beanNames">
<list>
<value>privateCatalog</value>
<!--Names of other beans to be proxied -->
</list>
</property>
<property name="interceptorNames">
<list>
<value>privateCatalogSecurityInterceptor</value>
</list>
</property>
</bean>
<beans>
應用程序可以使用清單 4 中的代碼訪問清單 3 中配置的 publicCatalog 和 privateCatalog Java bean。注意，清單 4 中顯示的 Java 代碼可位於 JSP 頁 面或位於服務器端 Java 應用程序的 bean 中。
清單 4. 訪問安全和不安全 Java bean 的客戶機應用程序代碼
//Step 1: Fetching an instance of the application context
XMLWebApplicationContext applicationCtx =
WebApplicationContextUtils.getWebApplicationContext(
this.getServletConfig().getServletContext());
//Step 2: Fetching an insecure bean from the application context
PublicCatalog publicCatalog =
(PublicCatalog) applicationCtx.getBean ("publicCatalog");
//Step 3: Calling a method of the insecure bean
String publicData = publicCatalog.getData();
//Step 4: Fetching a secure bean from the application context
PrivateCatalog privateCatalog =
(PrivateCatalog) applicationCtx.getBean ("privateCatalog");
//Step 5: Calling a method of the secure bean
String privateData = privateCatalog.getData();
下面將進一步討論清單 4 中的步驟：
步驟 1：取回一個應用程序上下文實例
當應用程序希望訪問 XML 配置文 件中配置的 Java bean 時，它必須取回您在 “使用 Spring 創建 Java 對象” 的步驟 4 中見到的 XMLWebApplicationContext 對象。 XMLWebApplicationContext 對象包含對 XML 配置文件配置的所有 Java beans 的引用。
步驟 2：從應用程序上下文中取回不安全的 bean
您現在具有一個對 XMLWebApplicationContext 對象的引用。XMLWebApplicationContext 類公開了 一個 getBean() 方法，它包含 bean 的名稱並在數組中查找 “使用 Spring 創 建 Java 對象” 步驟 7 中准備的 bean。在本例中，該 bean 為 publicCatalog（未執行過代理），因此 XMLWebApplicationContext 將返回實 際的 bean。
步驟 3：調用不安全 bean 的方法
現在您可以調用步驟 2 中獲得的 publicCatalog bean 的任何方法。例如，清單 4 顯示的 getData() 方法調用 的執行沒有應用任何訪問控制並向應用程序返回類別數據。
步驟 4：從應用程序上下文取回安全 bean
安全 bean 與不安全 bean 的 取回方式類似，惟一區別是：當您通過調用 getBean() 方法嘗試取回安全 bean 時，您將獲得安全對象的代理而不是實際的對象。該代理就是我在 “Spring IOC 發揮效用” 步驟 4 中解釋的由 Spring 框架創建的同一個對象。
步驟 5：調用安全 bean 的方法
當調用安全 bean 的方法時，您在 步驟 4 中獲得的代理對象將一個方法調用請求分配給攔截器。攔截器將檢查試圖訪問 方法的用戶是否具有相應的訪問權，從而處理方法調用請求。
您現在應該對 Spring 框架如何創建 Java 對象以及客戶機應用程序如何與 之交互有了清晰的了解。了解了這些內容後，就更加容易理解並利用 Acegi 的 方法安全性攔截器，下一節將具體介紹該主題。
配置 Acegi 的方法安全性攔截器
只要應用程序試圖訪問由 Acegi 安全系統保護的 bean 方法，請求將被自動 傳遞到 Acegi 的方法安全性攔截器。方法安全性攔截器的作用就是控制對安全 Java bean 的方法的訪問。攔截器使用 Acegi 的身份驗證和授權框架確認用戶 是否具有權利調用安全 Java bean 的方法，然後相應地作出響應。
清單 5 展示 Acegi 的方法安全性攔截器的示例配置：
清單 5. Acegi 的方法安全性攔截器的示例配置
<bean id="privateCatalogSecurityInterceptor"
class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityIn terceptor">
<property name="authenticationManager">
<ref bean="authenticationManager"/>
</property>
<property name="accessDecisionManager">
<ref bean="accessDecisionManager"/>
</property>
<property name="objectDefinitionSource">
<value>
sample.PrivateCatalog.getData=ROLE_HEAD_OF_ENGINEERING
<!-- Roles required by other beans -->
</value>
</property>
</bean>
清單 5 所示的攔截器配置包含三個需要進行配置的屬性，可以保護對 Java bean 的訪問：authenticationManager、accessDecisionManager 和 objectDefinitionSource。
回憶一下，您在本系列第 1 部分的 配置身份驗證處理過濾器 中曾對 authenticationManager 屬性進行了配置。authenticationManager 屬性的作用 是對用戶進行身份驗證。
您在本系列的第二篇文章中了解了 accessDecisionManager 屬性。這個訪問 決策管理器負責制定授權決策。在允許對一個安全 bean 進行訪問之前，方法安 全攔截器使用 authenticationManager 和 accessDecisionManager 屬性對用戶 進行身份驗證和授權。
現在查看 清單 5 中配置的 objectDefinitionSource 屬性。它類似於第 1 部分中出現的 objectDefinitionSource 屬性。以前的 objectDefinitionSource 包含類似於 /protected/* 和 /** 這樣的 URL，清單 5 中的 objectDefinitionSource 屬性指定類和方法名；例如， sample.PrivateCatalog 是之前執行過代理的類的名稱，而 getData 是您希望 對其控制用戶訪問的方法的名字。
當用戶訪問 PrivateCatalog bean 的 getData() 方法時，控制權將自動傳 遞給攔截器。攔截器使用 Acegi 框架檢查用戶的業務角色是否為 ROLE_HEAD_OF_ENGINEERING（特定於本文的示例）。如果是的話，攔截器將允許 對 getData() 方法進行訪問。如果攔截器發現用戶角色不是 ROLE_HEAD_OF_ENGINEERING，則拒絕訪問。
下一節將查看一個示例 Acegi 應用程序，它將實現您目前所了解的所有概念 。
示例 Acegi 應用程序
本文的 下載源代碼 包含了一個名為 AcegiMethodSecurity 的示例應用程序 ，可按照以下方法進行配置和部署：
使用用戶信息填充 LDAP 服務器。下載的示例應用程序 包含一個 LDIF 文件 ，其中含有預備裝載到 LDAP 服務器的用戶信息。關於如何將 LDIF 文件導入到 LDAP 服務器，請參考第 2 部分的 “填充服務器” 一節。注意，該應用程序涉 及與第 2 部分相同的用戶（alice、bob 和 specialUser）。
將本文下載源代碼中的 acegiMethodSecurity.war 文件復制到 Tomcat 安裝 目錄中的 webapps 目錄。
將 Acegi 的 jar 文件復制到示例應用程序的 WEB-INF/lib 文件夾。（有關 內容請參考第 1 部分的 “部署和運行應用程序” 一節。 ）
下載 cglib-full-2.0.2.jar 文件並將其復制到示例應用程序的 WEB- INF/lib 文件夾。
啟動 Tomcat 並嘗試運行示例應用程序。
運行示例應用程序
通過從浏覽器訪問 http://localhost:8080/acegiMethodSecurity URL 可調 用示例應用程序。AcegiMethodSecurity 顯示的索引頁面包含兩個鏈接 （Catalog 和 Login），如圖 2 所示：
圖 2. 示例應用程序的主頁面
當單擊應用程序的 Catalog 鏈接時，它將要求您進行登錄。如果以 alice 或 specialUser 的身份進行登錄，示例應用程序將提供完整的 類別，包括公有 數據和私有數據。這是因為在 清單 5 中，您對方法安全性攔截器進行了配置， 允許用戶使用 ROLE_HEAD_OF_ENGINEERING 訪問私有類別，而 alice 和 specialUser 都具有該訪問權。另一方面，如果您以 bob 的身份登錄，示例應 用程序將僅顯示公有數據。
為通過身份驗證的用戶分配額外角色
本節將演示經過增強的示例應用程序。增強後的示例應用程序將展示 Acegi 如何使您能夠在運行時向通過身份驗證的用戶臨時分配額外角色。
當安全 bean（例如 清單 3 的 privateCatalog bean）要訪問一個原創資源 時，您可能需要使用額外的角色。例如，您可能考慮到您的安全 bean 需要通過 Java 的 Remote Method Invocation (RMI) 框架或一個 Web 服務訪問某個遠程 應用程序。訪問安全 bean 的用戶不會占用遠程應用程序要求訪問用戶所具備的 業務角色。
在本例中，Acegi 首先檢查用戶是否經過授權來訪問安全 bean。之後， Acegi 允許用戶訪問安全 bean。當安全 bean 試圖訪問遠程服務時，它需要使 用額外的業務角色。如果訪問安全 bean 的用戶不具備額外角色，安全 bean 就 不能成功訪問遠程服務。
run-as-replacement 機制
Acegi 框架提供了一種名為 run-as-replacement 的簡單機制，允許您僅在 方法調用期間為通過身份驗證的用戶配置一個或多個額外角色。您可以使用 run-as-replacement 機制為訪問遠程應用程序的安全 bean 配置額外角色。這 意味著只要安全 bean 需要訪問遠程應用程序，Acegi 將為用戶裝載額外角色， 從而允許安全 bean 訪問遠程應用程序。
清單 6 對 清單 5 中的方法安全性攔截器的配置進行了增強。增強後的配置 使用了 run-as-replacement 機制。
清單 6. Acegi 方法安全性攔截器的增強配置
<bean id="privateCatalogSecurityInterceptor"
class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityIn terceptor">
<property name="authenticationManager">
<ref bean="authenticationManager"/>
</property>
<property name="accessDecisionManager">
<ref bean="accessDecisionManager"/>
</property>
<property name="runAsManager">
<bean id="runAsManager"
class="org.acegisecurity.runas.RunAsManagerImpl">
<property name="key">
<value>myKeyPass</value>
</property>
</bean>
</property>
<property name="objectDefinitionSource">
<value>
sample.PrivateCatalog.getData=ROLE_HEAD_OF_ENGINEERING,RUN_AS_MANAGER
</value>
</property>
</bean>
清單 6 使用粗體顯示了兩處增強（與 清單 5 相比）。第一處增強為 runAsManager 屬性。runAsManager 屬性的作用是向通過身份驗證的用戶動態添 加角色。出於這個目的，runAsManager 屬性包含了 RunAsManagerImpl bean 的 定義。RunAsManagerImpl bean 只有在滿足下面的條件時才可變為活躍狀態：在 objectDefinitionSource 方法的角色定義中找到以 RUN_AS_ 為前綴的角色。例 如，PrivateCatalog.getData() 方法的角色定義（清單 6 中以粗體顯示的第二 處增強）具有一個 RUN_AS_MANAGER 角色。
RunAsManagerImpl bean 包含一個名為 key 的屬性，它封裝的加密鍵用於確 保只將額外的角色作為 run-as-replacement 程序的一部分生成。
當用戶調用 getData() 方法時，RunAsManagerImpl bean 變為活躍狀態並創 建名為 RUN_AS_MANAGER 的額外角色，從而啟用 getData() 方法訪問遠程應用 程序。
增強的方法安全性
本文的 下載源代碼 包含一個名為 EnhancedAcegiMethodSecurity 的示例應 用程序，它可以演示 run-as-replacement 機制和程序。該應用程序將顯示一個 具有 Catalog 鏈接的索引頁面。如果單擊 Catalog 鏈接，將要求進行登錄。
登錄後，EnhancedAcegiMethodSecurity 應用程序將為您提供登錄用戶及其 角色的完整信息。例如，如果以 alice 或 specialUser 身份登錄，將向您顯示 用戶的所有業務角色，包括額外創建的臨時的 RUN_AS_MANAGER 角色。
結束語
在這份共分三部分的系列文章中，我介紹了如何使用 Acegi 安全系統增強基 於 URL 的安全性和基於方法的安全性。您了解了如何設計訪問控制策略並將它 們托管在目錄服務器中，如何對 Acegi 進行配置以與目錄服務器進行通信，以 及如何根據托管在服務器的訪問控制策略制定身份驗證和授權決策。
本系列的最後一篇文章主要介紹使用基於方法的安全性保護 Java 類實例。 文章還解釋了 Acegi 和 Spring 如何在內部創建和代理 Java 對象以及 bean 代理如何實現訪問控制。
本文配套源碼
