序言
譯者：leondu
，作者保留版權，轉載請注明出處。
Acegi Security為基于J2EE的企業應用軟件提供全面的安全解決方案。正如你在本手冊中看到的那樣，我們嘗試為您提供有用的，高可配置的安全系統。
安全是一個永無止境的目標，獲取一個全面的，系統級的實現方式是至關重要的。在安全界，我們鼓勵你采用"分層安全"，這樣每個層都確保自身盡可能的安全，另 外的層提供另外的安全。每個層自身越"緊密"，你的系統就越魯棒和安全。在底層，你要處理傳輸入安全和系統認證，減少"中間人攻擊"（man-in-the-middle attacks）。接下來你要使用防火墻，結合VPN或者IP安全來確保只有認證過的系統能夠嘗試連接。在企業環境中，你可能部署DMZ（demilitarized zone，隔離區）來把面向公眾的服務器和后端的數據和應用服務器分隔開。在以非授權用戶運行進程和文件系統安全最大化上，你的操作系統也將扮演一個關鍵的角色。接下來你要防止針對系統的拒絕服務和暴力攻擊。入侵檢測系統在檢測和應對攻擊方面尤其有用，這些系統可以實時屏蔽惡意TCP/IP地址。在更高層上，你的Java虛擬機需要進行配置，將授予不同Java類型的權限最小化，然后，你的應用程序要對添加針對自身特定問題域的安全配置。Acegi Security使后者－應用程序安全變得容易。
當然，你要正確對待上述提到的每個安全層，以及包含于每個層的管理因素。這樣的管理因素具體包括：安全公告監測，補丁，人工診斷，審計，變更管理，工程管理系統，數據備份，災難恢復，性能評測，負載監測，集中日志，應急反應程序等等。
Acegi Security專注于在企業應用安全層為您提供幫助，你將會發現和各式各樣的需求和商業問題領域一樣多。銀行系統的需求和電子商務應用的需求不同。電子商務應用和售賣軍用自動工具的公司的需求不同。這些客戶化的需求使得應用安全顯得有趣，富有挑戰性而且物有所值。
本手冊為Acegi Security 1.0.0的發布而大規模重新組織。請先閱讀Part I 架構概覽。手冊的其余部分按照傳統的手冊方式編排，需要一定的基礎才能閱讀。
我們希望您會覺得手冊有用，并且歡迎您提供反饋意見和建議。
最后，歡迎加入Acegi Security社區。
Part I. 架構概覽
象其他的軟件一樣，Acegi Security也有在整個框架中都會使用的特定核心接口，類，和概念抽象。在手冊的這一部分，在檢視這些規劃和執行Acegi Security集成所必須的核心要素之前，我們先介紹Acegi Security。
第一章. 簡介
1.1. Acegi Security是什么?
Acegi Security為基于J2EE的企業軟件應用提供全面的安全服務。特別是使用領先的J2EE解決方案－Srping框架開發的項目。如果您不是使用Spring開發企業應用，我們溫馨提醒您仔細研究一下。熟悉Spring，尤其是依賴注射原理，會極大的幫助你快速掌握Acegi Security。
人們使用Acegi Security有很多種原因，不過通常吸引他們到這個項目的原因是他們在J2EE的 Servlet Specification 或者 EJB Specification中找不到迫切需要的典型企業應用場景。提到這些規范，特別要提出的是他們不是在WAR或者EAR級別可移植的。這樣，如果你切換服務器環境，一般來說你要在目標環境中花費很多工夫來重新配置你的應用安全。使用Acegi Security解決了這些問題，并且為你提供了很多其他有用的，完全可定制的安全特性。
如你所知，安全包含兩個主要操作。第一個被稱為"認證"，是為用戶建立一個它所聲明的principal。Principal通常代表用戶，設備，或者其他能在你的應用中執行操作的其他系統。"授權"指判定一個principal能否在你的系統中執行某個操作。在到達授權判斷之前，principal的的身份認證已經由認證過程執行過了。這些概念是通用的，不是Acegi Security特有的。
在認證層面，Acegi Security廣泛支持各種認證模塊。這些認證模塊絕大多數是第三方提供，或者相關的標準組織開發的，例如Internet Engineering Task Force。作為補充，Acegi Security自己也提供了一些認證功能。
Acegi Security當前支持如下的認證技術。
• HTTP BASIC authentication headers (an IEFT RFC-based standard)
• HTTP Digest authentication headers (an IEFT RFC-based standard)
• HTTP X.509 client certificate exchange (an IEFT RFC-based standard)
• LDAP (a very common approach to cross-platform authentication needs, especially in large environments)
• Form-based authentication (for simple user interface needs)
• Computer Associates Siteminder
• JA-SIG Central Authentication Service (otherwise known as CAS, which is a popular open source single sign on system)
• Transparent authentication context propagation for Remote Method Invocation (RMI) and HttpInvoker (a Spring remoting protocol)
• Automatic "remember-me" authentication (so you can tick a box to avoid re-authentication for a predetermined period of time)
• Anonymous authentication (allowing every call to automatically assume a particular security identity)
• Run-as authentication (which is useful if one call should proceed with a different security identity)
• Java Authentication and Authorization Service (JAAS)
• Container integration with JBoss, Jetty, Resin and Tomcat (so you can still use Container Manager Authentication if desired)
• 你自己的認證系統 (如下所示)
很多獨立軟件供應商(ISVs)選擇Acegi Security是因為它具有豐富的認證模塊。這樣無論他們的終端客戶需要什么，他們都可以快速集成到他們的系統中，不用花很多工夫或者讓終端客戶改變環境。如果Acegi Security System for Spring的7個認證模塊還沒有滿足你的需求的話，Acegi Security是一個開放的系統，很容易寫你自己的認證機制。許多Acegi Security的企業用戶需要和"遺留"系統集成，這些遺留系統不遵循任何安全標準，Acegi Security能夠和這樣的系統"合作愉快"。
有時候基本的認證是不夠的。有時候你需要根據principal和應用交互的方式來應用不同的安全措施。例如，你可能為了防止密碼被竊取，或者防止終端用戶受到"中間人"攻擊，需要保證到達的是請求通過HTTPS的。或者，你要確保是一個真正的人而不是某種機器人或者自動進程在發送請求。這對于保護密碼恢復不受暴力破解攻擊，或者防止他人很容易的復制你應用的關鍵內容。為了幫助你實現這些目標，Acegi Security完全支持自動"通道安全"("channel security")，以及集成Jcaptcha來檢測是否是真正人類用戶。
Acegi Security不僅提供了認證功能，而且提供了完備的授權功能。在授權方面主要有三個領域，授權web請求，授權方法調用，授權存取單個領域對象實例。為了幫助你理解這些區別，對照考慮一下Servlet 規范中的web模式安全的授權功能，EJB容器管理安全以及文件系統安全。Acegi Security提供了所有這些重要領域的完備功能，我們將在本手冊的后面介紹。
1.2. 歷史
Acegi Security始于2003年晚期，當時在Spring Developers郵件列表中有人提問是否有人考慮提供一個基于Spring的安全實現。當時，Srping的社區是相對比較小的（尤其是和今天相比！），實際上Spring本身也是2003年早期才作為一個SourceForge項目出現的。對此問題的回應是它確實是一個值得研究的領域，雖然限于時間無法進行深入。
有鑒于此，這個簡單的安全實現雖然構建了但是并沒有發布。幾周以后，Spring社區的其他成員詢問了安全框架，代碼就被提供給了他們。
隨后又有人請求，到了2004年一月，大約有20人左右在使用這些代碼。另外一些人加入到這些先行的用戶中來，并建議建立一個SourceForge項目，這個項目在2004年3月建立起來。
在早期，該項目自身并不具備任何認證模塊。認證過程依賴容器管理安全（Container Managed Security）而Acegi Security注重授權。在一開始這樣是合適的，但是隨著越來越多的用戶要求額外的容器支持，基于容器的認證的限制就顯示出來了。另外一個相關的問題是添加新的JAR文件到容器的classpath，通常會讓最終用戶感到困惑并且配置錯誤。
隨后，Acegi Security加入了認證服務。大約一年后，Acegi Security成為了一個Spring Framework官方子項目。在2年半多的在多個軟件項目中的活躍使用以及數以百計的改進和社區貢獻，1.0.0最終版在2006年5月發布。
今天，Acegi Security成為一個強大而活躍的社區。在支持論壇上有數以千計的帖子。14個開發人員專職開發，一個活躍的社區也定期共享補丁并支持他們的同儕。
1.3. 發行版本號
理解Acegi Security的版本號是非常好處的，它可以幫助你判定升級的到新的版本是否需要花費很大精力。我們的正式發行版本使用Apache Portable Runtime Project版本指引，可以在下述網站查看http://apr.apache.org/versioning.html。為了您查看方便，我們引用該頁的說明部分如下：
"版本號由三個部分的整數組成：主版本號（MAJOR）、副版本號（MINOR）、補丁版本號（PATCH）。主要的含義是主版本號（MAJOR）是不兼容的，API大規模升級。副版本號（MINOR）在源文件和可執行版和老版本保持兼容，補丁版本號（PATCH）則意味著向前和向后的完全兼容"。
第二章. 技術概覽
2.1. 運行時環境
Acegi Security可以在JRE1.3中運行。這個發行版本中支持也Java 5.0，盡管對應的Java類型被分開打包到一個后綴是"tiger"的包中。因為Acegi Security致力于以一種自包含的方式運行，因此不需要在JRE中放置任何特殊的配置文件。特別無需配置Java Authentication and Authorization Service (JAAS)策略文件或者將Acegi Security放置到通用的classpath路徑中。
同樣的，如果你使用EJB容器或者Servlet容器，同樣無需放置任何特別的配置文件或者將Acegi Security包含在服務器的類加載器（classloader）中。
上述的設計提供了最大的部署靈活性，你可以直接把目標工件（JAR, WAR 或者 EAR)）直接從一個系統copy到另一個系統，它馬上就可以運行起來。
2.2. 共享組件
讓我們來看看Acegi Security中最重要的一些共享組件。所謂共享組件是指在框架中處于核心地位，系統脫離了它們之后就不能運行。這些Java類型代表了系統中其他部分的構建單元，因此理解它們是非常重要的，即使你不需要直接和它們打交道。
最基礎的對象是SecurityContextHolder。在這里存儲了當前應用的安全上下文（security context），包括正在使用應用程序的principal的詳細信息。SecurityContextHolder默認使用ThreadLocal來存儲這些詳細信息，這意味著即便安全上下文（security context）沒有被作為一個參數顯式傳入，它仍然是可用的。如果在當前principal的請求處理后清理線程,那么用這種方式使用ThreadLocal是非常安全的。當然， Acegi Security自動為你處理這些，所以你無需擔心。
有些應用程序由于使用線程的方式而并不是完全適用ThreadLocal。例如，Swing客戶端可能需要一個Java Virtual Machine中的所有線程都使用同樣的安全上下文（security context）。在這種情況下你要使用SecurityContextHolder.MODE_GLOBAL模式。另外一些應用程序可能需要安全線程產生的線程擁有同樣的安全標識符（security identity）。這可以通過SecurityContextHolder.MODE_INHERITABLETHREADLOCAL來實現。你可以通過兩種方法來修改默認的SecurityContextHolder.MODE_THREADLOCAL。第一種是設置一個系統屬性。或者，調用SecurityContextHolder的一個靜態方法。大部分的應用程序不需要修改默認值，不過如果你需要，那么請查看SecurityContextHolder的JavaDocs獲取更多信息。
我們在SecurityContextHolder中存儲當前和應用程序交互的principal的詳細信息。Acegi Security使用一個Authentication對象來代表這個信息。盡管你通常不需要自行創建一個Authentication對象，用戶還是經常會查詢Authentication對象。
你可以在你的應用程序中的任何地方使用下述的代碼塊：
Object obj =SecurityContextHolder.getContext().getAuthentication().getPrincipal();if (obj instanceof UserDetails) {String username =((UserDetails)obj).getUsername();} else {String username =obj.toString();}
上述的代碼展示了一些有趣的聯系和關鍵的對象。首先，你會注意到在SecurityContextHolder和Authentication之間有一個媒介對象。SecurityContextHolder.getContext() 方法實際上返回一個SecurityContext。Acegi Security使用若干個不同的SecurityContext實現，以備我們需要存儲一些和principal無關的特殊信息。一個很好的例子就是我們的Jcaptcha集成，它需要知道一個需求是否是由人發起的。這樣的判斷和principal是否通過認證完全沒有關系，因此我們將它保存在SecurityContext中。
從上述的代碼片段可以看出的另一個問題是你可以從一個Authentication對象中獲取一個principal。Principal只是一個對象。通常可以把它cast為一個UserDetails對象。UserDetails在Acegi Security中是一個核心接口，它以一種擴展以及應用相關的方式來展現一個principal。可以把UserDetails看作是你的用戶數據庫和Acegi Security在SecurityContextHolder所需要的東西之間的一個適配器（adapter）。作為你自己用戶數據庫的一個展現，你可能經常要把它cast到你應用程序提供的原始對象，這樣你就可以調用業務相關的方法(例如 getEmail(), getEmployeeNumber())。
現在你可能已經開始疑惑，那我什么時候提供UserDetails對象呢？我要如何提供呢？
我想你告訴過我這個東西是聲明式的，我不需要寫任何Java代碼－那怎么做到呢？對此的簡短回答就是有一個叫做UserDetailsService的特殊接口。這個接口只有一個方法，接受一個Sring類型的參數并返回一個UserDetails。Acegi Security提供的大多數認證提供器將部分認證過程委派給UserDetailsService。UserDetailsService用來構建保存在SecurityContextHolder中的Authentication對象。好消息是我們提供若干個UserDetailsService的實現，包括一個使用in-memory map和另一個使用JDBC的。
大多數用戶還是傾向于寫自己的實現，這樣的實現經常就是簡單的構建于已有的Data Access Object (DAO)上，這些DAO展現了他們的雇員、客戶、或者其他企業應用程序中的用戶。要記得這樣做的好處，不論你的UserDetailsService返回什么，它總是可以從SecurityContextHolder中獲取，象上面的代碼顯示的那樣。
除了principal，Authentication提供的另一個重要方法就是getAuthorities（）。這個方法返回一個GrantedAuthority對象數組。GrantedAuthority，毫無疑問，就是授予principal的權限。這些權限通常是"角色"，例如ROLE_ADMINISTRATOR 或者ROLE_HR_SUPERVISOR。這些角色稍后配置到web授權，方法授權和領域對象授權。Acegi Security的其他部分能夠處理這些權限，并且期待他們被提供。通常你會從UserDetailsService中返回GrantedAuthority對象。
通常GrantedAuthority對象都是應用范圍的權限。它們都不對應特定的領域對象。因此，你應該不會有一個代表54號員工對象的GrantedAuthority，因為這樣會有數以千計的authority，你馬上就會用光所有內存（或者，至少會讓系統花太長時間來認證一個用戶）。當然，Acegi Security會高效的處理這種普遍的需求，但是你不會使用領域對象安全功能來實現這個目的。
最后，但不是不重要，你有時候需要在HTTP 請求之間存儲SecurityContext。另外有些時候你在每次請求的時候都會重新認證principal，不過大部分時候你會存儲SecurityContext。HttpSessionContextIntegrationFilter在HTTP之間存儲SecurityContext。正如類名字顯示的那樣，它使用HttpSession來進行存儲。基于安全原因，你永遠都不要直接和HttpSession交互。沒有理由這么做，所以記得使用SecurityContextHolder來代替。
讓我們回憶一下，Acegi Security的基本組成構件是：
• SecurityContextHolder,提供對SecurityContext的所有訪問方式。
• SecurityContext, 存儲Authentication以及可能的請求相關的安全信息。
• HttpSessionContextIntegrationFilter, 在web請求之間把SecurityContext存儲在HttpSession中。
• Authentication, 以Acegi Security的方式表現principal。
• GrantedAuthority, 表示賦予一個principal的應用范圍的權限。
• UserDetails, 為從你的應用程序DAO中獲取必要的信息來構建一個Authentication 對象。
• UserDetailsService,用傳入的String類型的username（或者認證ID，或類似）來創建一個UserDetails。
現在你已經理解了這些重復使用的組件，讓我們仔細看看認證過程吧。
2.3. 認證
正如我們在手冊開始部分所說的那樣，Acegi Security適用于很多認證環境。雖然我們建議大家使用Acegi Security自身的認證功能而不是和容器管理認證（Container Managed Authentication）集成，但是我們仍然支持這種和你私有的認證系統集成的認證。讓我們先從Acegi Security完全自行管理管理web安全的角度來探究一下認證，這也是最復雜和最通用的情形。
想象一個典型的web應用的認證過程：
1．你訪問首頁，點擊一個鏈接。
2．一個請求被發送到服務器，服務器判斷你是否請求一個被保護的資源。
3．因為你當前未被認證，服務器發回一個回應，表明你必須通過認證。這個回應可能是一個HTTP回應代碼，或者重定向到一個特定的網頁。
4．基于不同的認證機制，你的瀏覽器會重定向到一個網頁好讓你填寫表單，或者瀏覽器會用某種方式獲取你的身份認證（例如一個BASIC認證對話框，一個cookie，一個X509證書等等。）。
5．瀏覽器會發回給服務器一個回應。可能是一個包含了你填寫的表單內容的HTTP POST，或者一個包含你認證詳細信息的HTTP header。
6．接下來服務器會判斷提供的認證信息是否有效。如果它們有效，你進入到下一步。如果它們無效，那么通常請求你的瀏覽器重試一次（你會回到上兩步）。
7．你引發認證的那個請求會被重試。但愿你認證后有足夠的權限訪問那些被保護的資源。如果你有足夠的訪問權限，請求就會成功。否則，你將會受到一個意味"禁止"的HTTP403錯誤代碼。
在Acegi Security中，對應上述的步驟，有對應的類。主要的參與者（按照被使用的順序）是：ExceptionTranslationFilter， AuthenticationEntryPoint， 認證機制(authentication mechanism)， 以及AuthenticationProvider。
ExceptionTranslationFilter是Acegi Security用來檢測任何拋出的安全異常的過濾器(filter)。這種異常通常是由AbstractSecurityInterceptor拋出的，它是授權服務的主要提供者。我們將會在下一部分討論AbstractSecurityInterceptor，現在我們只需要知道它產生Java異常，并且對于HTTP或者如何認證一個principal一無所知。反而是ExceptionTranslationFilter提供這樣的服務，它負責要么返回403錯誤代碼(如果principal通過了認證，只是缺少足夠的權限，象上述第7步那樣)，要么加載一個AuthenticationEntryPoint (如果principal還沒有被認證，那么我們要從第3步開始)。
AuthenticationEntryPoint負責上述的第3步。如你所想，每個web應用都有一個默認的認證策略（象Acegi Security中幾乎所有的東西一樣，它也是可配置的，不過我們現在還是還是從簡單開始）。每個主流的認證系統都有它自己的AuthenticationEntryPoint實現，負責執行第3步中描述的動作。
當瀏覽器確定要發送你的認證信息（HTTP 表單或者HTTP header），服務器上需要有什么東西來"收集"這些認證信息。現在我們在上述的第6步。在Acegi Security中對從用戶代理（通常是瀏覽器）收集認證信息有一個特定的名字，這個名字是"認證機制（authentication mechanism）"。當認證信息從客戶代理收集過來以后，一個"認證請求（Authenticationrequest）"對象被創建，并發送到AuthenticationProvider。
Acegi Security中認證的最后一環是一個AuthenticationProvider。非常簡單，它的職責是取用一個認證請求（Authentication request）對象，并且判斷它是否有效。這個provider要么拋出一個異常，要么返回一個組裝完畢的Authentication對象。還記得我們的好朋友UserDetails 和 UserDetailsService吧？如果沒有，回到前一部分重新回憶一下。大部分的AuthenticationProviders都會要求UserDetailsService提供一個UserDetails對象。如前所述，大部分的應用程序會提供自己的UserDetailsService，盡管有些會使用Acegi Security提供的JDBC或者 in-memory實現。作為成品的UserDetails 對象，特別是其中的GrantedAuthority[]s，在構建完備的Authentication對象時會被使用。
當認證機制（authentication mechanism）取回組裝完全的Authentication對象后，它將會相信請求是有效的，將Authentication放到SecurityContextHolder中，并且將原始請求取回（上述第7步）。反之，AuthenticationProvider則拒絕請求，認證機制（authentication mechanism）會請求用戶重試（上述第2步）。
在講述典型的認證流程的同時，有個好消息是Acegi Security不關心你是如何把Authentication放到SecurityContextHolder內的。唯一關鍵的是在AbstractSecurityInterceptor授權一個請求之前，在SecurityContextHolder中包含一個代表了principal的Authentication。
你可以（很多用戶確實）實現自己的過濾器（filter）或者MVC控制器（controller）來提供和不是基于Acegi Security的認證系統交互。例如，你可能使用使用容器管理認證（Container Managed Authentication），從ThreadLocal或者JNDI中獲取當前用戶信息，使得它有效。或者，你工作的公司有一個遺留的私有認證系統，而它是公司"標準"，你對它無能為力。在這種情況之下也是非常容易讓Acegi Security運作起來，提供認證能力。你所需要做的是寫一個過濾器（或等價物）從某處讀取第三方用戶信息，構建一個Acegi Security式的Authentication對象，把它放到SecurityContextHolder中。這非常容易做，也是一種廣泛支持的集成方式。
2.4. 安全對象
如果你熟悉AOP，你會知道有很多種advice可用：before, after, throws 和 around。around advice非常有用，因為它能夠選擇是否選擇是否執行一個方法調用，是否修改返回值，以及是否拋出異常。Acegi Security對方法調用和web請求都提供around advice。我們使用AOP聯盟實現對方法調用的around advice，對于web請求的around advice則是使用標準的過濾器（Filter）。
對于那些不熟悉AOP的人來說，關鍵是要理解Acegi Security能夠幫助你保護方法調用以及web請求。大多數人對保護他們服務層的方法調用感興趣。這是因為在當前的J2EE應用中，服務層包含了大多數的業務邏輯（聲明，作者不贊成這種設計，反而支持正確封裝的領域模型以及DTO，assembly, facade 以及 transparent persistence patterns，而不是當前主流的貧血模型，我們將在這里討論）。如果你需要保護service層的方法調用，使用標準的Spring AOP平臺（或者被成為AOP 聯盟（AOP Alliance））就足夠了。如果你需要直接對領域模型進行保護，那么可以考慮使用AspectJ。
你可以選擇對使用AspectJ 或者AOP聯盟（AOP Alliance）對方法進行授權，或者你可以選擇使用過濾器（filter）來對web請求進行授權。你將0個，1個，2個或者3個這些方法一起使用。主流的用法是執行一些web請求授權，以及在服務層使用AOP聯盟（AOP Alliance）對一些方法調用授權。
Acegi Security使用"安全對象"（secure object）這個詞來指任何能夠將安全應用于其上的對象。每個Acegi Security支持的安全對象都有自己的類，它是AbstractSecurityInterceptor的子類。重要的一點是，如果一個principal通過認證，當AbstractSecurityInterceptor執行的時候，SecurityContextHolder中要包含一個有效的Authentication。
AbstractSecurityInterceptor提供一個固定的工作流程來處理安全對象請求。這個工作流程包括查找和當前請求相關聯的"配置屬性（configuration attributes）"。配置屬性（configuration attributes）可以被認為是對被AbstractSecurityInterceptor使用的類有特殊含義的字符串。他們通常針對AbstractSecurityInterceptor使用XML進行配置。反正，AbstractSecurityInterceptor會詢問AccessDecisionManager "這是配置屬性（configuration attributes），這是當前的認證對象（Authentication object），這是當前請求的詳細信息－那么這個特定的principal可以執行這個特定的操作嗎？"。
假如AccessDecisionManager判定允許這個請求，那么AbstractSecurityInterceptor一般來說就繼續執行請求。雖然這樣，用戶在少數情況之下可能需要替換SecurityContext中的Authentication，可以通過AccessDecisionManager調用一個RunAsManager來實現。在某些不常見的情形下這將非常有用，例如服務層的方法需要用另一種標識（身份）來調用遠程系統。這可能有所幫助，因為Acegi Security自動在不同的服務器之間傳播安全標識（假設你正確配置了RMI或者HttpInvoker remoting protocol client）。
隨著安全對象處理和返回－意味著方法調用完畢或者過濾器鏈（filter chain）處理完畢－AbstractSecurityInterceptor有最后的機會來處理調用。這時，AbstractSecurityInterceptor可能會修改返回的對象。我們可能要這樣做，因為授權判斷不能在安全對象調用途中執行。由于高度的可插拔性，如果需要AfterInvocationManager將控制權交給AfterInvocationManager來實際修改對象。這個類甚至可以徹底替換對象，或者拋出異常，或者根本不修改它。
因為是AbstractSecurityInterceptor中心模版類，看起來第一副插圖該獻給它。（譯注：原手冊里的圖畫的太丑陋了，我用jude重新畫了一遍）
圖1 關鍵"安全對象"模型
只有那些希望實現全新的對請求進行截取截取和授權方式的開發者才需要直接使用安全對象。例如，可能構建一個新的安全對象安全調用一個消息系統。任何需要安全并且能夠提供一種截取調用的方式(例如AOP around advice semantics)的東西都可以成為安全對象。雖然如此，大部分的Spring應用都會只是透明應用當前支持的三種安全對象類型（AOP Alliance MethodInvocation, AspectJ JoinPoint 和 web request FilterInterceptor）。
2.5. 結論
恭喜！你已經獲取了Acegi Security足夠的概括性的圖景來開始著手你的項目。我們探究了共享組件，認證過程，以及對"安全對象"的通用授權概念。手冊中的余下部分你可能用到也可能用不到，可以按照任意順序閱讀。
第三章. 協助系統
本章介紹一些Acegi Security使用的附加和協助系統。那些和安全無關，但是包含在Acegi Security項目中的部分，將會在本章中討論
3.1. 本地化
Acegi Security支持對終端客戶可能會看到的異常信息進行本地化。如果你的應用是為英文用戶設計的，那么你什么都不用做，因為Acegi Security的所有消息默認都是英文的。如果你要支持其他區域用戶，那么本節包含了你所需要了解的所有東西。
包括認證失敗或者訪問被拒絕（授權失敗）的所有異常消息都可以被本地化。提供給開發者或者系統部署人員的異常或者日志信息(包括錯誤的屬性、接口不符、構造器錯誤、debug級日志)沒有被本地化，它們硬編碼在Acegi Security的代碼中。
在acegi-security-xx.jar（譯注：xx代表版本號）的org.acegisecurity包中包含了一個messages.properties文件。這個文件會被你的application context引用，因為Acegi Security實現了Spring的MessageSourceAware接口，它期待在application context啟動的時候注入一個message resolver。通常你所需要做的是在你的application context中注冊一個引用這個消息的bean，如下所示：
<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource"><property name="basename"><value>org/acegisecurity/messages</value></property></bean>
messages.properties是按照資源包標準命名的，它代表了Acegi Securtiy支持的默認語言。文件默認是英文的。如果你不注冊一個消息源，Acegi Security仍然可以正常工作，它會用回硬編碼的英文消息。
如果你想定制messages.properties文件，或者支持其他語言，那么你應該copy這個文件，然后重命名，并在上述的bean定義中注冊。因為文件中的key并不多，因此本地化花不了多少工夫。如果你針對消息文件進行了本地化，那么請和社區分享，你可以添加一個JIRA任務，將你正確命名的messages.properties本地化文件作為附件添加。
為了完善關于本地化的討論需要知道Spring的ThreadLocal org.springframework.context.i18n.LocaleContextHolder。你應該為每個用戶設置代表他區域的LocaleContextHolder。Acegi Security會嘗試從這個ThreadLocal中獲取的Locale來從消息源中獲取消息。請參考Spring的文檔以獲取更多使用LocaleContextHolder和能夠幫你自動設置它的輔助類(例如
AcceptHeaderLocaleResolver, CookieLocaleResolver, FixedLocaleResolver, SessionLocaleResolver 等)的詳細信息。
3.2. Filters
正如你在整個手冊中看到的那樣，Acegi Security使用很多filter。你可以使用FilterToBeanProxy或者FilterChainProxy來確定這些是怎樣加入到你的web應用中的，下面我們來看看。
大部分filter使用FilterToBeanProxy來配置。例如下面web.xml中配置所示：
<filter> <filter-name>Acegi HTTP Request Security Filter</filter-name> <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class> <init-param> <param-name>targetClass</param-name> <param-value>org.acegisecurity.ClassThatImplementsFilter</param-value> </init-param></filter>
注意在web.xml中的filter實際上是一個FilterToBeanProxy，而不是真正實現filter邏輯的filter。FilterToBeanProxy所作的是代理Filter的方法到一個從Spring的application context 獲取的bean。這使得這個bean可以享受Spring application context的生命周期支持以及配置靈活性。這個bean必須實現javax.servlet.Filter。
FilterToBeanProxy只需要一個簡單的初始化參數，targetClass或者targetBean。targetClass會定位application context中指定的類的第一個對象，而FilterToBeanProxy按照bean的名字定位對象。象標準的Spring web應用一樣，FilterToBeanProxy使用WebApplicationContextUtils.getWebApplicationContext(ServletContext)來訪問application context，所以你應該在web.xml中配置一個ContextLoaderListener。
在IoC容器而不是servlet容器中部署Filter會有一個生命周期的問題。特別是，哪個容器應該負責調用Filter的"startup" 和 "shutdown"方法？注意到Filter的初始化和析構順序隨servlet容器不同而不同，如果一個Filter依賴于由另一個更早初始化的Filter的配置，這樣就會出現問題。另一方面，Spring IoC具備更加完善的生命周期/IoC接口（例如InitializingBean, DisposableBean, BeanNameAware, ApplicationContextAware以及其他許多）以及一個容易理解的接口契約（interface contract），可預見的方法調用順序，自動裝配支持，以及可以避免實現Spring接口的選項（例如Spring XML中的destroy-method 屬性）。因此，我們推薦盡可能使用Spring生命周期服務而不是servlet容器生命周期服務。FilterToBeanProxy默認不會將init(FilterConfig) 和 destroy()方法委派到被代理的bean。如果你需要這些調用被委派，那么將lifecycle初始化參數設置為servlet-container-managed。
我們強烈推薦你使用FilterChainProxy而不是FilterToBeanProxy。雖然FilterToBeanProxy是一個非常有用的類FilterToBeanProxy，問題是當web.xml中filter變多時，<filter> 和 <filter-mapping>項就會太多而變得臃腫不堪。為了解決這個問題，Acegi Security提供一個FilterChainProxy類。它在FilterToBeanProxy中被裝配（正如上面例子中所示），但目標類（target class）是org.acegisecurity.util.FilterChainProxy。這樣過濾器鏈（filter chain）可以在application context中按照如下代碼配置：
<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy"> <property name="filterInvocationDefinitionSource"> <value> CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /webServices/*=httpSessionContextIntegrationFilterWithASCFalse,basicProcessingFilter,exceptionTranslationFilter, /*=httpSessionContextIntegrationFilterWithASCTrue,authenticationProcessingFilter,exceptionTranslationFilter,filterSecurityInterceptor </value> </property></bean>
你可能注意到FilterSecurityInterceptor定義方式的相似之處。同時支持正則表達式和Ant Paths格式，越對應的URI越早出現。在運行時，FilterChainProxy會定位符合當前的web請求的第一個URI模式。每個對應的配置屬性代表了在application context中定義的一個bean的名字。接著fiter會按照它們被指定的順序，按照FilterChain的標準行為模式被調用(如果一個Filter決定停止處理，它可以不在chain中執行)。
如你所見，FilterChainProxy需要為不同的請求模式重復配置filter的名字（在上面的例子中，, exceptionTranslationFilter 和 filterSecurityInterceptor 是重復的）。這樣的設計是為了讓FilterChainProxy能夠為不同的URI配置不同的filter調用順序，同時也提高了表達力（針對正則表達式、Ant Paths、以及任何FilterInvocationDefinitionSource的特定實現）和清晰度，可以知道是哪個filter應該被調用。
你可能注意到了我們在filter chain定義了兩個HttpSessionContextIntegrationFilter (ASC是allowSessionCreation的縮寫,是HttpSessionContextIntegrationFilter的一個屬性)。因為web服務不會為將來的請求提供一個jsessionid，為這樣的用戶創建HttpSessions是浪費的。如果你有一個需要最大限度的伸縮性的高容量的應用，我們建議你使用上述的方法。對于小的應用，使用單一的HttpSessionContextIntegrationFilter (默認的allowSessionCreation設為true)應該足夠了。
說到生命周期問題，如果對FilterChainProxy自身調用init(FilterConfig) 和 destroy()方法，它會把它代理到底層的filter。這樣FilterChainProxy保證只初始化和析構每個filter一次，不論它在FilterInvocationDefinitionSource中定義了多少次。你可以通過FilterToBeanProxy的lifecycle初始化參數來控制這些方法是否被調用。如上面所討論的那樣，默認所有servlet容器生命周期調用是不被代理到FilterChainProxy的。
在web.xml中定義的filter的順序是非常重要的。不管你實際用到哪個filter，<filter-mapping>的順序應該是如下所示的：
1．ChannelProcessingFilter，因為可能要重定向到另一種協議。
2．ConcurrentSessionFilter 因為不使用任何SecurityContextHolder的功能，但是需要更新SessionRegistry來表示當前的發送請求的principal。
3． HttpSessionContextIntegrationFilter, 這樣當一個web請求開始的時候就可以在SecurityContextHolder中設置一個SecurityContext，當web請求結束的時候任何對SecurityContext的改動都會被copy到HttpSession（以備下一個web請求使用）。
4．Authentication processing mechanisms - AuthenticationProcessingFilter, CasProcessingFilter, BasicProcessingFilter, HttpRequestIntegrationFilter, JbossIntegrationFilter 等 - 修改SecurityContextHolder，使其中包含一個有效的認證請求令牌（token）。
5．SecurityContextHolderAwareRequestFilter, 如果你使用它來在你的servlet容器中安裝一個Acegi Security aware HttpServletRequestWrapper。
6．RememberMeProcessingFilter, 如果早期的認證處理過程沒有更新SecurityContextHolder，并且請求（request）提供了一個cookie啟用remember-me服務，一個合適的被記住的Authentication對象會被放到SecurityContextHolder那里。
7．AnonymousProcessingFilter, 如果早期的認證處理過程沒有更新SecurityContextHolder，, 一個匿名Authentication 對象會被放到SecurityContextHolder那里。
8．ExceptionTranslationFilter, 捕獲所有的Acegi Security 異常，這樣要么返回一個HTTP錯誤響應或者加載一個對應的AuthenticationEntryPoint。
9．FilterSecurityInterceptor, 保護 web URIs
所有上述的filter使用FilterToBeanProxy或FilterChainProxy。建議在一個應用中使用一個單個的FilterToBeanProxy代理到一個單個的FilterChainProxy。，在FilterChainProxy中定義所有的Acegi Security Filters。如果你使用SiteMesh，確保Acegi Security filters 在 SiteMesh filters調用前調用。這樣使SecurityContextHolder在SiteMesh decorator使用前能夠及時被裝配。
第四章. 信道安全
4.1. 概述
Acegi Security不僅能滿足你的認證和授權的請求，而且能夠保證你的未認證的web請求也能擁有某些屬性。這些屬性可能包括使用特定的傳輸類型，在HttpSession設置特定的屬性等等。Web請求的最普遍的需求是使用特定的傳輸協議，例如HTTPS。
在傳輸安全中的一個重要議題就是會話劫持（session hijacking）。Web容器通過一個jsessionid來引用一個HttpSession，這個jsessionid通過cookie 或者URL重寫轉向（URL rewriting）發送到到客戶端。如果jsessionid是通過HTTP發送的，那么就存在被劫持以及在認證過程之后冒充被認證用戶的可能。這是因為大部分的web容器為特定的用戶維護同一個會話標識符，即便是用戶從HTTP 切換到 HTTPS頁面。
如果對于你的特定應用來說，會話劫持（session hijacking）是一個很嚴重的風險，那么唯一的解決方法就是對每一個請求都使用HTTPS。這意味著jsessionid不會使用非安全信道傳輸。你要保證你的web.xml中定義<welcome-file>，把它指向一個HTTPS位置，同時應用程序不把用戶指向一個HTTP位置。Acegi Security提供一個解決方案幫助你實現后者。
4.2. 配置
啟用Acegi Security的信道安全服務，需要在web.xml中增加如下行：
<filter><filter-name>Acegi Channel Processing Filter</filter-name><filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class><init-param><param-name>targetClass</param-name><param-value>org.acegisecurity.securechannel.ChannelProcessingFilter</param-value></init-param></filter><filter-mapping><filter-name>Acegi Channel Processing Filter</filter-name><url-pattern>/*</url-pattern></filter-mapping>
和平時一樣，你同樣需要在application context中配置filter
<bean id="channelProcessingFilter" class="org.acegisecurity.securechannel.ChannelProcessingFilter"><property name="channelDecisionManager"><ref bean="channelDecisionManager"/></property><property name="filterInvocationDefinitionSource"><value>CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON\A/secure/.*\Z=REQUIRES_SECURE_CHANNEL\A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL\A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL\A.*\Z=REQUIRES_INSECURE_CHANNEL</value></property></bean><bean id="channelDecisionManager" class="org.acegisecurity.securechannel.ChannelDecisionManagerImpl"><property name="channelProcessors"><list><ref bean="secureChannelProcessor"/><ref bean="insecureChannelProcessor"/></list></property></bean><bean id="secureChannelProcessor" class="org.acegisecurity.securechannel.SecureChannelProcessor"/><bean id="insecureChannelProcessor" class="org.acegisecurity.securechannel.InsecureChannelProcessor"/>
ChannelProcessingFilter和FilterSecurityInterceptor一樣支持Apache Ant style paths。
ChannelProcessingFilter的工作方式是過濾所有的web請求，并將判斷將適合的配置屬性應用于其上。然后它代理到ChannelDecisionManager。默認的實現類ChannelDecisionManagerImpl應該能夠滿足大多數需求。它就代理到配置好的ChannelProcessor實例列表。ChannelProcessor會檢視請求，如果它不滿意請求（例如請求是發送自不正確的傳輸協議）它將會重定向，拋出異常或者采取其他任何恰當的措施。
Acegi Security 包括ChannelProcessor兩個實體類實現：SecureChannelProcessor 保證配置了REQUIRES_SECURE_CHANNEL 屬性的請求都是從HTTPS發送過來的。而InsecureChannelProcessor 保證配置了REQUIRES_INSECURE_CHANNEL 屬性的請求都是從HTTP發送過來的。如果沒有使用請求的協議，這兩個實現都會轉到ChannelEntryPoint，而兩個ChannelEntryPoint 實現所作的就是簡單的把請求相應按照HTTP 和 HTTPS重定向。
要注意重定向是絕對（例如http://www.company.com:8080/app/page）而不是相對的(例如 /app/page)。在測試中發現Internet Explorer 6 Service Pack 1 有一個bug，因此如果在重定向的時候也改變使用的端口，它就不能正確響應。對應這個bug，在很多Acegi Security bean中都會使用的PortResolverImpl也使用絕對URL。請參閱PortResolverImpl的JavaDoc以獲取更多信息。
你要注意使用為了在登錄過程中保證用戶名和密碼的安全，要使用安全信道。如果你配合基于表單的登錄使用ChannelProcessingFilter，請記得一定要把你的登錄頁面設置為REQUIRES_SECURE_CHANNEL，并且AuthenticationProcessingFilterEntryPoint.forceHttps屬性設置為true。
4.3. 結論
一旦配置好了，使用安全信道是非常簡單的。只要請求頁面，不用管使用什么協議（HTTP 或 HTTPS）或什么端口（80, 8080, 443, 8443等）。顯然你只要確定初始請求(獲取通過在web.xml 中的<welcome-file> 或一個眾所周知的主頁URL)，完成以后filter會執行你application context定義的重定向。
你也可以在ChannelDecisionManagerImpl中增加自己的ChannelProcessor實現。例如，你可能通過"輸入圖片中的內容"檢測到一個個人類用戶，然后在HttpSession中設置一個屬性。
要判斷一個安全檢查應該是或者ChannelProcessor或是 AccessDecisionVoter 記得前者是設計用來處理認證或者未認證的請求，而后者是設計用來處理已認證的請求。因此后者可以訪問已認證的principal被授予的權限。
另外，ChannelProcessor檢測到問題后一般是引發一個HTTP/HTTPS重定向這樣他的請求可以被滿足，而AccessDecisionVoter將則會跑出一個AccessDeniedException異常(取決于支配的 AccessDecisionManager)。
文章來源:http://wiki.springside.org.cn/display/springside/Acegi+Reference+Preface