2007 年 10 月 18 日
本文是 Acegi Security Systerm 介紹的最后一部分（共三部分），Bilal Siddiqui 將向您介紹如何保護對 Java 類實例的訪問，從而結束本系列文章。通過本文了解為何需要對 Java™ 類的訪問進行保護，Spring 如何創建和保護對 Java 類實例的訪問以及如何對 Acegi 進行配置以實現 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.BeanNameAutoProxyCreator">
<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（參見 參考資料小節 中有關 AOP 的討論文章的鏈接）。
執行完前面的步驟后，您現在具有了所需的代理對象。因此 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.BeanNameAutoProxyCreator">
<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.MethodSecurityInterceptor">
<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.MethodSecurityInterceptor">
<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 代理如何實現訪問控制。文章包含了兩個示例應用程序，您可以使用它們進一步研究本系列中學到的概念，更多有關使用 Acegi 保護 Java 應用程序的內容，請參見 參考資料 小節。
來自:http://www-128.ibm.com/developerworks/cn/java/j-acegi3/?