序言
Acegi Security為基于J2EE的企業(yè)應(yīng)用軟件提供全面的安全解決方案。正如你在本手冊中看到的那樣，我們嘗試為您提供有用的，高可配置的安全系統(tǒng)。
安 全是一個永無止境的目標(biāo)，獲取一個全面的，系統(tǒng)級的實現(xiàn)方式是至關(guān)重要的。在安全界，我們鼓勵你采用“分層安全”，這樣每個層都確保自身盡可能的安全，另 外的層提供另外的安全。每個層自身越“緊密”，你的系統(tǒng)就越魯棒和安全。在底層，你要處理傳輸入安全和系統(tǒng)認(rèn)證，減少“中間人攻擊”（man-in- the-middle attacks）。接下來你要使用防火墻，結(jié)合VPN或者IP安全來確保只有認(rèn)證過的系統(tǒng)能夠嘗試連接。在企業(yè)環(huán)境中，你可能部署DMZ （demilitarized zone，隔離區(qū)）來把面向公眾的服務(wù)器和后端的數(shù)據(jù)和應(yīng)用服務(wù)器分隔開。在以非授權(quán)用戶運行進(jìn)程和文件系統(tǒng)安全最大化上，你的操作系統(tǒng)也將扮演一個關(guān)鍵 的角色。接下來你要防止針對系統(tǒng)的拒絕服務(wù)和暴力攻擊。入侵檢測系統(tǒng)在檢測和應(yīng)對攻擊方面尤其有用，這些系統(tǒng)可以實時屏蔽惡意TCP/IP地址。在更高層 上，你的Java虛擬機(jī)需要進(jìn)行配置，將授予不同Java類型的權(quán)限最小化，然后，你的應(yīng)用程序要對添加針對自身特定問題域的安全配置。Acegi Security使后者－應(yīng)用程序安全變得容易。
當(dāng)然，你要正確對待上述提到的每個安全層，以及包含于每個層的管理因素。這樣的管理因素具體包括：安全公告監(jiān)測，補(bǔ)丁，人工診斷，審計，變更管理，工程管理系統(tǒng)，數(shù)據(jù)備份，災(zāi)難恢復(fù)，性能評測，負(fù)載監(jiān)測，集中日志，應(yīng)急反應(yīng)程序等等。
Acegi Security專注于在企業(yè)應(yīng)用安全層為您提供幫助，你將會發(fā)現(xiàn)和各式各樣的需求和商業(yè)問題領(lǐng)域一樣多。銀行系統(tǒng)的需求和電子商務(wù)應(yīng)用的需求不同。電子 商務(wù)應(yīng)用和售賣軍用自動工具的公司的需求不同。這些客戶化的需求使得應(yīng)用安全顯得有趣，富有挑戰(zhàn)性而且物有所值。
本手冊為Acegi Security 1.0.0的發(fā)布而大規(guī)模重新組織。請先閱讀Part I 架構(gòu)概覽。手冊的其余部分按照傳統(tǒng)的手冊方式編排，需要一定的基礎(chǔ)才能閱讀。
我們希望您會覺得手冊有用，并且歡迎您提供反饋意見和建議。
最后，歡迎加入Acegi Security社區(qū)。
acegi參考手冊(v1.0.4)[譯]－第一章 簡介
Part I. 架構(gòu)概覽
象其他的軟件一樣，Acegi Security也有在整個框架中都會使用的特定核心接口，類，和概念抽象。在手冊的這一部分，在檢視這些規(guī)劃和執(zhí)行Acegi Security集成所必須的核心要素之前，我們先介紹Acegi Security。
第一章. 簡介
1.1. Acegi Security是什么?
Acegi Security為基于J2EE的企業(yè)軟件應(yīng)用提供全面的安全服務(wù)。特別是使用領(lǐng)先的J2EE解決方案－Srping框架開發(fā)的項目。如果您不是使用 Spring開發(fā)企業(yè)應(yīng)用，我們溫馨提醒您仔細(xì)研究一下。熟悉Spring，尤其是依賴注射原理，會極大的幫助你快速掌握Acegi Security。
人們使用Acegi Security有很多種原因，不過通常吸引他們到這個項目的原因是他們在J2EE的 Servlet Specification 或者 EJB Specification中找不到迫切需要的典型企業(yè)應(yīng)用場景。提到這些規(guī)范，特別要提出的是他們不是在WAR或者EAR級別可移植的。這樣，如果你切 換服務(wù)器環(huán)境，一般來說你要在目標(biāo)環(huán)境中花費很多工夫來重新配置你的應(yīng)用安全。使用Acegi Security解決了這些問題，并且為你提供了很多其他有用的，完全可定制的安全特性。
如你所知，安全包含兩個主要操作。第一個被稱為“認(rèn) 證”，是為用戶建立一個它所聲明的principal。Principal通常代表用戶，設(shè)備，或者其他能在你的應(yīng)用中執(zhí)行操作的其他系統(tǒng)。“授權(quán)”指判 定一個principal能否在你的系統(tǒng)中執(zhí)行某個操作。在到達(dá)授權(quán)判斷之前，principal的的身份認(rèn)證已經(jīng)由認(rèn)證過程執(zhí)行過了。這些概念是通用 的，不是Acegi Security特有的。
在認(rèn)證層面，Acegi Security廣泛支持各種認(rèn)證模塊。這些認(rèn)證模塊絕大多數(shù)是第三方提供，或者相關(guān)的標(biāo)準(zhǔn)組織開發(fā)的，例如Internet Engineering Task Force。作為補(bǔ)充，Acegi Security自己也提供了一些認(rèn)證功能。Acegi Security當(dāng)前支持如下的認(rèn)證技術(shù)。
&S226; HTTP BASIC authentication headers (an IEFT RFC-based standard)
&S226; HTTP Digest authentication headers (an IEFT RFC-based standard)
&S226; HTTP X.509 client certificate exchange (an IEFT RFC-based standard)
&S226; LDAP (a very common approach to cross-platform authentication needs, especially in large environments)
&S226; Form-based authentication (for simple user interface needs)
&S226; Computer Associates Siteminder
&S226; JA-SIG Central Authentication Service (otherwise known as CAS, which is a popular open source single sign on system)
&S226; Transparent authentication context propagation for Remote Method Invocation (RMI) and HttpInvoker (a Spring remoting protocol)
&S226; Automatic "remember-me" authentication (so you can tick a box to avoid re-authentication for a predetermined period of time)
&S226; Anonymous authentication (allowing every call to automatically assume a particular security identity)
&S226; Run-as authentication (which is useful if one call should proceed with a different security identity)
&S226; Java Authentication and Authorization Service (JAAS)
&S226; Container integration with JBoss, Jetty, Resin and Tomcat (so you can still use Container Manager Authentication if desired)
&S226; 你自己的認(rèn)證系統(tǒng) (如下所示)
很 多獨立軟件供應(yīng)商(ISVs)選擇Acegi Security是因為它具有豐富的認(rèn)證模塊。這樣無論他們的終端客戶需要什么，他們都可以快速集成到他們的系統(tǒng)中，不用花很多工夫或者讓終端客戶改變環(huán) 境。如果Acegi Security System for Spring的7個認(rèn)證模塊還沒有滿足你的需求的話，Acegi Security是一個開放的系統(tǒng)，很容易寫你自己的認(rèn)證機(jī)制。許多Acegi Security的企業(yè)用戶需要和“遺留”系統(tǒng)集成，這些遺留系統(tǒng)不遵循任何安全標(biāo)準(zhǔn)，Acegi Security能夠和這樣的系統(tǒng)“合作愉快”。
有 時候基本的認(rèn)證是不夠的。有時候你需要根據(jù)principal和應(yīng)用交互的方式來應(yīng)用不同的安全措施。例如，你可能為了防止密碼被竊取，或者防止終端用戶 受到“中間人”攻擊，需要保證到達(dá)的是請求通過HTTPS的。或者，你要確保是一個真正的人而不是某種機(jī)器人或者自動進(jìn)程在發(fā)送請求。這對于保護(hù)密碼恢復(fù) 不受暴力破解攻擊，或者防止他人很容易的復(fù)制你應(yīng)用的關(guān)鍵內(nèi)容。為了幫助你實現(xiàn)這些目標(biāo)，Acegi Security完全支持自動“通道安全”("channel security")，以及集成Jcaptcha來檢測是否是真正人類用戶。
Acegi Security不僅提供了認(rèn)證功能，而且提供了完備的授權(quán)功能。在授權(quán)方面主要有三個領(lǐng)域，授權(quán)web請求，授權(quán)方法調(diào)用，授權(quán)存取單個領(lǐng)域?qū)ο髮嵗?為了幫助你理解這些區(qū)別，對照考慮一下Servlet 規(guī)范中的web模式安全的授權(quán)功能，EJB容器管理安全以及文件系統(tǒng)安全。Acegi Security提供了所有這些重要領(lǐng)域的完備功能，我們將在本手冊的后面介紹。
1.2. 歷史
Acegi Security始于2003年晚期，當(dāng)時在Spring Developers郵件列表中有人提問是否有人考慮提供一個基于Spring的安全實現(xiàn)。當(dāng)時，Srping的社區(qū)是相對比較小的（尤其是和今天相 比！），實際上Spring本身也是2003年早期才作為一個SourceForge項目出現(xiàn)的。對此問題的回應(yīng)是它確實是一個值得研究的領(lǐng)域，雖然限于 時間無法進(jìn)行深入。
有鑒于此，這個簡單的安全實現(xiàn)雖然構(gòu)建了但是并沒有發(fā)布。幾周以后，Spring社區(qū)的其他成員詢問了安全框架，代碼就被提供給了他們。
隨后又有人請求，到了2004年一月，大約有20人左右在使用這些代碼。另外一些人加入到這些先行的用戶中來，并建議建立一個SourceForge項目，這個項目在2004年3月建立起來。
在 早期，該項目自身并布具備任何認(rèn)證模塊。認(rèn)證過程依賴容器管理安全（Container Managed Security）而Acegi Security注重授權(quán)。在一開始這樣是合適的，但是隨著越來越多的用戶要求額外的容器支持，基于容器的認(rèn)證的限制就顯示出來了。另外一個相關(guān)的問題是 添加新的JAR文件到容器的classpath，通常會讓最終用戶感到困惑并且配置錯誤。
隨后，Acegi Security加入了認(rèn)證服務(wù)。大約一年后，Acegi Security成為了一個Spring Framework官方子項目。在2年半多的在多個軟件項目中的活躍使用以及數(shù)以百計的改進(jìn)和社區(qū)貢獻(xiàn)，1.0.0最終版在2006年5月發(fā)布。
今天，Acegi Security成為一個強(qiáng)大而活躍的社區(qū)。在支持論壇上有數(shù)以千計的帖子。14位開發(fā)人員專職開發(fā)，一個活躍的社區(qū)也定期共享補(bǔ)丁并支持他們的同儕。
1.3. 發(fā)行版本號
理 解Acegi Security的版本號是非常好處的，它可以幫助你判定升級的到新的版本是否需要花費很大精力。我們的正式發(fā)行版本使用Apache Portable Runtime Project版本指引，可以在下述網(wǎng)站查看http://apr.apache.org/versioning.html。為了您查看方便，我們引用該 頁的說明部分如下：
“版本號由三個部分的整數(shù)組成：主版本號（MAJOR）、副版本號（MINOR）、補(bǔ)丁版本號（PATCH）。主要的含義 是主版本號（MAJOR）是不兼容的，API大規(guī)模升級。副版本號（MINOR）在源文件和可執(zhí)行版和老版本保持兼容，補(bǔ)丁版本號（PATCH）則意味著 向前和向后的完全兼容”。
acegi參考手冊(v1.0.4)[譯]-第二章 技術(shù)概覽[上]
第二章. 技術(shù)概覽
2.1. 運行時環(huán)境
Acegi Security可以在JRE1.3中運行。這個發(fā)行版本中支持也Java 5.0，盡管對應(yīng)的Java類型被分開打包到一個后綴是“tiger”的包中。因為Acegi Security致力于以一種自包含的方式運行，因此不需要在JRE中放置任何特殊的配置文件。特別無需配置Java Authentication and Authorization Service (JAAS)策略文件或者將Acegi Security放置到通用的classpath路徑中。
同樣的，如果你使用EJB容器或者Servlet容器，同樣無需放置任何特別的配置文件或者將Acegi Security包含在服務(wù)器的類加載器（classloader）中。
上述的設(shè)計提供了最大的部署靈活性，你可以直接把目標(biāo)工件（JAR, WAR 或者 EAR)）直接從一個系統(tǒng)copy到另一個系統(tǒng)，它馬上就可以運行起來。
2.2. 共享組件
讓我們來看看Acegi Security中最重要的一些共享組件。所謂共享組件是指在框架中處于核心地位，系統(tǒng)脫離了它們之后就不能運行。這些Java類型代表了系統(tǒng)中其他部分的構(gòu)建單元，因此理解它們是非常重要的，即使你不需要直接和它們打交道。
最 基礎(chǔ)的對象是SecurityContextHolder。在這里存儲了當(dāng)前應(yīng)用的安全上下文（security context），包括正在使用應(yīng)用程序的principal的詳細(xì)信息。SecurityContextHolder默認(rèn)使用ThreadLocal來 存儲這些詳細(xì)信息，這意味著即便安全上下文（security context）沒有被作為一個參數(shù)顯式傳入，它仍然是可用的。如果在當(dāng)前principal的請求處理后清理線程,那么用這種方式使用 ThreadLocal是非常安全的。當(dāng)然， Acegi Security自動為你處理這些，所以你無需擔(dān)心。
有些應(yīng)用程序由于使 用線程的方式而并不是完全適用ThreadLocal。例如，Swing客戶端可能需要一個Java Virtual Machine中的所有線程都使用同樣的安全上下文（security context）。在這種情況下你要使用SecurityContextHolder.MODE_GLOBAL模式。另外一些應(yīng)用程序可能需要安全線程產(chǎn) 生的線程擁有同樣的安全標(biāo)識符（security identity）。這可以通過SecurityContextHolder.MODE_INHERITABLETHREADLOCAL來實現(xiàn)。你可以通 過兩種方法來修改默認(rèn)的SecurityContextHolder.MODE_THREADLOCAL。第一種是設(shè)置一個系統(tǒng)屬性。或者，調(diào)用 SecurityContextHolder的一個靜態(tài)方法。大部分的應(yīng)用程序不需要修改默認(rèn)值，不過如果你需要，那么請查看 SecurityContextHolder的JavaDocs獲取更多信息。
我們在SecurityContextHolder中 存儲當(dāng)前和應(yīng)用程序交互的principal的詳細(xì)信息。Acegi Security使用一個Authentication對象來代表這個信息。盡管你通常不需要自行創(chuàng)建一個Authentication對象，用戶還是經(jīng) 常會查詢Authentication對象。
你可以在你的應(yīng)用程序中的任何地方使用下述的代碼塊：
java 代碼
1. Object obj = SecurityContextHolder.getContext().getAuthentication().getPrincipal();
2. if (obj instanceof UserDetails) {
3. String username = ((UserDetails)obj).getUsername();
4. } else {
5. String username = obj.toString();
6. }
上 述的代碼展示了一些有趣的聯(lián)系和關(guān)鍵的對象。首先，你會注意到在SecurityContextHolder和Authentication之間有一個媒 介對象。SecurityContextHolder.getContext() 方法實際上返回一個SecurityContext。Acegi Security使用若干個不同的SecurityContext實現(xiàn)，以備我們需要存儲一些和principal無關(guān)的特殊信息。一個很好的例子就是我 們的Jcaptcha集成，它需要知道一個需求是否是由人發(fā)起的。這樣的判斷和principal是否通過認(rèn)證完全沒有關(guān)系，因此我們將它保存在 SecurityContext中。
從上述的代碼片段可以看出的另一個問題是你可以從一個Authentication對象中獲取一 個principal。Principal只是一個對象。通常可以把它cast為一個UserDetails對象。UserDetails在Acegi Security中是一個核心接口，它以一種擴(kuò)展以及應(yīng)用相關(guān)的方式來展現(xiàn)一個principal。可以把UserDetails看作是你的用戶數(shù)據(jù)庫和 Acegi Security在SecurityContextHolder所需要的東西之間的一個適配器（adapter）。作為你自己用戶數(shù)據(jù)庫的一個展現(xiàn)，你可 能經(jīng)常要把它cast到你應(yīng)用程序提供的原始對象，這樣你就可以調(diào)用業(yè)務(wù)相關(guān)的方法(例如 getEmail(), getEmployeeNumber())。
現(xiàn)在你可能已經(jīng)開始疑惑，那我什么時候提供UserDetails對象呢？我要如何提供呢？
我 想你告訴過我這個東西是聲明式的，我不需要寫任何Java代碼－那怎么做到呢？對此的簡短回答就是有一個叫做UserDetailsService的特殊 接口。這個接口只有一個方法，接受一個Sring類型的參數(shù)并返回一個UserDetails。Acegi Security提供的大多數(shù)認(rèn)證提供器將部分認(rèn)證過程委派給UserDetailsService。UserDetailsService用來構(gòu)建保存 在SecurityContextHolder中的Authentication對象。好消息是我們提供若干個UserDetailsService的實 現(xiàn)，包括一個使用in-memory map和另一個使用JDBC的。
大多數(shù)用戶還是傾向于寫自己的實現(xiàn)，這樣的實現(xiàn)經(jīng)常就是簡單的構(gòu)建于已 有的Data Access Object (DAO)上，這些DAO展現(xiàn)了他們的雇員、客戶、或者其他企業(yè)應(yīng)用程序中的用戶。要記得這樣做的好處，不論你的UserDetailsService返 回什么，它總是可以從SecurityContextHolder中獲取，象上面的代碼顯示的那樣。
除了principal， Authentication提供的另一個重要方法就是getAuthorities（）。這個方法返回一個GrantedAuthority對象數(shù)組。 GrantedAuthority，毫無疑問，就是授予principal的權(quán)限。這些權(quán)限通常是“角色”，例如ROLE_ADMINISTRATOR 或者ROLE_HR_SUPERVISOR。這些角色稍后配置到web授權(quán)，方法授權(quán)和領(lǐng)域?qū)ο笫跈?quán)。Acegi Security的其他部分能夠處理這些權(quán)限，并且期待他們被提供。通常你會從UserDetailsService中返回 GrantedAuthority對象。
通常GrantedAuthority對象都是應(yīng)用范圍的權(quán)限。它們都不對應(yīng)特定的領(lǐng)域?qū)?象。因此，你應(yīng)該不會有一個代表54號員工對象的GrantedAuthority，因為這樣會有數(shù)以千計的authority，你馬上就會用光所有內(nèi)存 （或者，至少會讓系統(tǒng)花太長時間來認(rèn)證一個用戶）。當(dāng)然，Acegi Security會高效的處理這種普遍的需求，但是你不會使用領(lǐng)域?qū)ο蟀踩δ軄韺崿F(xiàn)這個目的。
最后，但不是不重要，你有時候需要在 HTTP 請求之間存儲SecurityContext。另外有些時候你在每次請求的時候都會重新認(rèn)證principal，不過大部分時候你會存儲 SecurityContext。HttpSessionContextIntegrationFilter在HTTP之間存儲 SecurityContext。正如類名字顯示的那樣，它使用HttpSession來進(jìn)行存儲。基于安全原因，你永遠(yuǎn)都不要直接和 HttpSession交互。沒有理由這么做，所以記得使用SecurityContextHolder來代替。
讓我們回憶一下，Acegi Security的基本組成構(gòu)件是：
&S226; SecurityContextHolder,提供對SecurityContext的所有訪問方式。
&S226; SecurityContext, 存儲Authentication以及可能的請求相關(guān)的安全信息。
&S226; HttpSessionContextIntegrationFilter, 在web請求之間把SecurityContext存儲在HttpSession中。
&S226; Authentication, 以Acegi Security的方式表現(xiàn)principal。
&S226; GrantedAuthority, 表示賦予一個principal的應(yīng)用范圍的權(quán)限。
&S226; UserDetails, 為從你的應(yīng)用程序DAO中獲取必要的信息來構(gòu)建一個Authentication 對象。
&S226; UserDetailsService,用傳入的String類型的username（或者認(rèn)證ID，或類似）來創(chuàng)建一個UserDetails。
現(xiàn)在你已經(jīng)理解了這些重復(fù)使用的組件，讓我們仔細(xì)看看認(rèn)證過程吧。
2.3. 認(rèn)證
正 如我們在手冊開始部分所說的那樣，Acegi Security適用于很多認(rèn)證環(huán)境。雖然我們建議大家使用Acegi Security自身的認(rèn)證功能而不是和容器管理認(rèn)證（Container Managed Authentication）集成，但是我們?nèi)匀恢С诌@種和你私有的認(rèn)證系統(tǒng)集成的認(rèn)證。讓我們先從Acegi Security完全自行管理管理web安全的角度來探究一下認(rèn)證，這也是最復(fù)雜和最通用的情形。
想象一個典型的web應(yīng)用的認(rèn)證過程：
1．你訪問首頁，點擊一個鏈接。
2．一個請求被發(fā)送到服務(wù)器，服務(wù)器判斷你是否請求一個被保護(hù)的資源。
3．因為你當(dāng)前未被認(rèn)證，服務(wù)器發(fā)回一個回應(yīng)，表明你必須通過認(rèn)證。這個回應(yīng)可能是一個HTTP回應(yīng)代碼，或者重定向到一個特定的網(wǎng)頁。
4．基于不同的認(rèn)證機(jī)制，你的瀏覽器會重定向到一個網(wǎng)頁好讓你填寫表單，或者瀏覽器會用某種方式獲取你的身份認(rèn)證（例如一個BASIC認(rèn)證對話框，一個cookie，一個X509證書等等。）。
5．瀏覽器會發(fā)回給服務(wù)器一個回應(yīng)。可能是一個包含了你填寫的表單內(nèi)容的HTTP POST，或者一個包含你認(rèn)證詳細(xì)信息的HTTP header。
6．接下來服務(wù)器會判斷提供的認(rèn)證信息是否有效。如果它們有效，你進(jìn)入到下一步。如果它們無效，那么通常請求你的瀏覽器重試一次（你會回到上兩步）。
7．你引發(fā)認(rèn)證的那個請求會被重試。但愿你認(rèn)證后有足夠的權(quán)限訪問那些被保護(hù)的資源。如果你有足夠的訪問權(quán)限，請求就會成功。否則，你將會受到一個意味“禁止”的HTTP403錯誤代碼。
在Acegi Security中，對應(yīng)上述的步驟，有對應(yīng)的類。主要的參與者（按照被使用的順序）是：ExceptionTranslationFilter， AuthenticationEntryPoint， 認(rèn)證機(jī)制(authentication mechanism)， 以及AuthenticationProvider。
ExceptionTranslationFilter是Acegi Security用來檢測任何拋出的安全異常的過濾器(filter)。這種異常通常是由AbstractSecurityInterceptor拋出 的，它是授權(quán)服務(wù)的主要提供者。我們將會在下一部分討論AbstractSecurityInterceptor，現(xiàn)在我們只需要知道它產(chǎn)生Java異 常，并且對于HTTP或者如何認(rèn)證一個principal一無所知。反而是ExceptionTranslationFilter提供這樣的服務(wù)，它負(fù)責(zé) 要么返回403錯誤代碼(如果principal通過了認(rèn)證，只是缺少足夠的權(quán)限，象上述第7步那樣)，要么加載一個 AuthenticationEntryPoint (如果principal還沒有被認(rèn)證，那么我們要從第3步開始)。
AuthenticationEntryPoint 負(fù)責(zé)上述的第3步。如你所想，每個web應(yīng)用都有一個默認(rèn)的認(rèn)證策略（象Acegi Security中幾乎所有的東西一樣，它也是可配置的，不過我們現(xiàn)在還是還是從簡單開始）。每個主流的認(rèn)證系統(tǒng)都有它自己的 AuthenticationEntryPoint實現(xiàn)，負(fù)責(zé)執(zhí)行第3步中描述的動作。
當(dāng)瀏覽器確定要發(fā)送你的認(rèn)證信息（HTTP 表單或者HTTP header），服務(wù)器上需要有什么東西來“收集”這些認(rèn)證信息。現(xiàn)在我們在上述的第6步。在Acegi Security中對從用戶代理（通常是瀏覽器）收集認(rèn)證信息有一個特定的名字，這個名字是“認(rèn)證機(jī)制（authentication mechanism）”。當(dāng)認(rèn)證信息從客戶代理收集過來以后，一個“認(rèn)證請求（Authentication request）”對象被創(chuàng)建，并發(fā)送到AuthenticationProvider。
Acegi Security中認(rèn)證的最后一環(huán)是一個AuthenticationProvider。非常簡單，它的職責(zé)是取用一個認(rèn)證請求 （Authentication request）對象，并且判斷它是否有效。這個provider要么拋出一個異常，要么返回一個組裝完畢的Authentication對象。還記得我 們的好朋友UserDetails 和 UserDetailsService吧？如果沒有，回到前一部分重新回憶一下。大部分的AuthenticationProviders都會要求 UserDetailsService提供一個UserDetails對象。如前所述，大部分的應(yīng)用程序會提供自己的 UserDetailsService，盡管有些會使用Acegi Security提供的JDBC或者 in-memory實現(xiàn)。作為成品的UserDetails 對象，特別是其中的GrantedAuthority[]s，在構(gòu)建完備的Authentication對象時會被使用。
當(dāng)認(rèn)證機(jī)制 （authentication mechanism）取回組裝完全的Authentication對象后，它將會相信請求是有效的，將Authentication放到 SecurityContextHolder中，并且將原始請求取回（上述第7步）。反之，AuthenticationProvider則拒絕請求，認(rèn) 證機(jī)制（authentication mechanism）會請求用戶重試（上述第2步）。
在講述典型的認(rèn)證流程的同時，有個好消 息是Acegi Security不關(guān)心你是如何把Authentication放到SecurityContextHolder內(nèi)的。唯一關(guān)鍵的是在 AbstractSecurityInterceptor授權(quán)一個請求之前，在SecurityContextHolder中包含一個代表了 principal的Authentication。
你可以（很多用戶確實）實現(xiàn)自己的過濾器（filter）或者M(jìn)VC控制器 （controller）來提供和不是基于Acegi Security的認(rèn)證系統(tǒng)交互。例如，你可能使用使用容器管理認(rèn)證（Container Managed Authentication），從ThreadLocal 或者JNDI中獲取當(dāng)前用戶信息，使得它有效。或者，你工作的公司有一個遺留的私有認(rèn)證系統(tǒng)，而它是公司“標(biāo)準(zhǔn)”，你對它無能為力。在這種情況之下也是非 常容易讓Acegi Security運作起來，提供認(rèn)證能力。你所需要做的是寫一個過濾器（或等價物）從某處讀取第三方用戶信息，構(gòu)建一個Acegi Security式的Authentication對象，把它放到SecurityContextHolder中。這非常容易做，也是一種廣泛支持的集成 方式。
acegi參考手冊(v1.0.4)[譯]-第二章 技術(shù)概覽[下]
2.4. 安全對象
如果你熟悉AOP，你會知 道有很多種advice可用：before, after, throws 和 around。around advice非常有用，因為它能夠選擇是否選擇是否執(zhí)行一個方法調(diào)用，是否修改返回值，以及是否拋出異常。Acegi Security對方法調(diào)用和web請求都提供around advice。我們使用AOP聯(lián)盟實現(xiàn)對方法調(diào)用的around advice，對于web請求的around advice則是使用標(biāo)準(zhǔn)的過濾器（Filter）。
對于那些不熟悉AOP的人來說， 關(guān)鍵是要理解Acegi Security能夠幫助你保護(hù)方法調(diào)用以及web請求。大多數(shù)人對保護(hù)他們服務(wù)層的方法調(diào)用感興趣。這是因為在當(dāng)前的J2EE應(yīng)用中，服務(wù)層包含了大多 數(shù)的業(yè)務(wù)邏輯（聲明，作者不贊成這種設(shè)計，反而支持正確封裝的領(lǐng)域模型以及DTO，assembly, facade 以及 transparent persistence patterns，而不是當(dāng)前主流的貧血模型，我們將在這里討論）。如果你需要保護(hù)service層的方法調(diào)用，使用標(biāo)準(zhǔn)的Spring AOP平臺（或者被成為AOP 聯(lián)盟（AOP Alliance））就足夠了。如果你需要直接對領(lǐng)域模型進(jìn)行保護(hù)，那么可以考慮使用AspectJ。
你 可以選擇對使用AspectJ 或者AOP聯(lián)盟（AOP Alliance）對方法進(jìn)行授權(quán)，或者你可以選擇使用過濾器（filter）來對web請求進(jìn)行授權(quán)。你將0個，1個，2個或者3個這些方法一起使用。 主流的用法是執(zhí)行一些web請求授權(quán)，以及在服務(wù)層使用AOP聯(lián)盟（AOP Alliance）對一些方法調(diào)用授權(quán)。
Acegi Security使用“安全對象”（secure object）這個詞來指任何能夠?qū)踩珣?yīng)用于其上的對象。每個Acegi Security支持的安全對象都有自己的類，它是AbstractSecurityInterceptor的子類。重要的一點是，如果一個 principal通過認(rèn)證，當(dāng)AbstractSecurityInterceptor執(zhí)行的時候，SecurityContextHolder中要包 含一個有效的Authentication。
AbstractSecurityInterceptor提供一個固定的工作流程來處理 安全對象請求。這個工作流程包括查找和當(dāng)前請求相關(guān)聯(lián)的“配置屬性（configuration attributes）”。配置屬性（configuration attributes）可以被認(rèn)為是對被AbstractSecurityInterceptor使用的類有特殊含義的字符串。他們通常針對 AbstractSecurityInterceptor使用XML進(jìn)行配置。反正，AbstractSecurityInterceptor會詢問 AccessDecisionManager “這是配置屬性（configuration attributes），這是當(dāng)前的認(rèn)證對象（Authentication object），這是當(dāng)前請求的詳細(xì)信息－那么這個特定的principal可以執(zhí)行這個特定的操作嗎？”。
假如 AccessDecisionManager判定允許這個請求，那么AbstractSecurityInterceptor一般來說就繼續(xù)執(zhí)行請求。雖 然這樣，用戶在少數(shù)情況之下可能需要替換SecurityContext中的Authentication，可以通過 AccessDecisionManager調(diào)用一個RunAsManager來實現(xiàn)。在某些不常見的情形下這將非常有用，例如服務(wù)層的方法需要用另一種 標(biāo)識（身份）來調(diào)用遠(yuǎn)程系統(tǒng)。這可能有所幫助，因為Acegi Security自動在不同的服務(wù)器之間傳播安全標(biāo)識（假設(shè)你正確配置了RMI或者HttpInvoker remoting protocol client）。
隨著安全對象處理和返回－意味著方法調(diào)用完畢或者過濾器鏈（filter chain）處理完畢－AbstractSecurityInterceptor有最后的機(jī)會來處理調(diào)用。這時， AbstractSecurityInterceptor可能會修改返回的對象。我們可能要這樣做，因為授權(quán)判斷不能在安全對象調(diào)用途中執(zhí)行。由于高度的 可插拔性，如果需要AfterInvocationManager將控制權(quán)交給AfterInvocationManager來實際修改對象。這個類甚至 可以徹底替換對象，或者拋出異常，或者根本不修改它。
因為是AbstractSecurityInterceptor中心模版類，看起來第一副插圖該獻(xiàn)給它。（譯注：原手冊里的圖畫的太丑陋了，我用jude重新畫了一遍）
<!--[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"> <v:stroke joinstyle="miter" /> <v:formulas> <v:f eqn="if lineDrawn pixelLineWidth 0" /> <v:f eqn="sum @0 1 0" /> <v:f eqn="sum 0 0 @1" /> <v:f eqn="prod @2 1 2" /> <v:f eqn="prod @3 21600 pixelWidth" /> <v:f eqn="prod @3 21600 pixelHeight" /> <v:f eqn="sum @0 0 1" /> <v:f eqn="prod @6 1 2" /> <v:f eqn="prod @7 21600 pixelWidth" /> <v:f eqn="sum @8 21600 0" /> <v:f eqn="prod @7 21600 pixelHeight" /> <v:f eqn="sum @10 21600 0" /> </v:formulas> <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect" /> <o:lock v:ext="edit" aspectratio="t" /> </v:shapetype><v:shape id="_x0000_i1025" type="#_x0000_t75" style='width:423pt; height:270.75pt'> <v:imagedata src="file:///C:\WINDOWS\TEMP\msohtml1\01\clip_image001.jpg" o:title="ch2-1" /> </v:shape><![endif]--><!--[if !vml]--><!--[endif]-->
圖1 關(guān)鍵“安全對象”模型
只有那些希望實現(xiàn)全 新的對請求進(jìn)行截取截取和授權(quán)方式的開發(fā)者才需要直接使用安全對象。例如，可能構(gòu)建一個新的安全對象安全調(diào)用一個消息系統(tǒng)。任何需要安全并且能夠提供一種 截取調(diào)用的方式(例如AOP around advice semantics)的東西都可以成為安全對象。雖然如此，大部分的Spring應(yīng)用都會只是透明應(yīng)用當(dāng)前支持的三種安全對象類型（AOP Alliance MethodInvocation, AspectJ JoinPoint 和 web request FilterInterceptor）。
2.5. 結(jié)論
恭喜！你已經(jīng)獲取了Acegi Security足夠的概括性的圖景來開始著手你的項目。我們探究了共享組件，認(rèn)證過程，以及對“安全對象”的通用授權(quán)概念。手冊中的余下部分你可能用到也可能用不到，可以按照任意順序閱讀。
acegi參考手冊(v1.0.4)[譯]-第三章 協(xié)助系統(tǒng)
第三章. 協(xié)助系統(tǒng)
本章介紹一些Acegi Security使用的附加和協(xié)助系統(tǒng)。那些和安全無關(guān)，但是包含在Acegi Security項目中的部分，將會在本章中討論
3.1. 本地化
Acegi Security支持對終端客戶可能會看到的異常信息進(jìn)行本地化。如果你的應(yīng)用是為英文用戶設(shè)計的，那么你什么都不用做，因為Acegi Security的所有消息默認(rèn)都是英文的。如果你要支持其他區(qū)域用戶，那么本節(jié)包含了你所需要了解的所有東西。
包括認(rèn)證失敗或者訪問被拒絕（授權(quán)失敗）的所有異常消息都可以被本地化。提供給開發(fā)者或者系統(tǒng)部署人員的異常或者日志信息(包括錯誤的屬性、接口不符、構(gòu)造器錯誤、debug級日志)沒有被本地化，它們硬編碼在Acegi Security的代碼中。
在acegi -security-xx.jar（譯注：xx代表版本號）的org.acegisecurity包中包含了一個 messages.properties文件。這個文件會被你的application context引用，因為Acegi Security實現(xiàn)了Spring的MessageSourceAware接口，它期待在application context啟動的時候注入一個message resolver。通常你所需要做的是在你的application context中注冊一個引用這個消息的bean，如下所示：
xml 代碼
1. <bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
2. <property name="basename"><value>org/acegisecurity/messages<!--</span-->value><!--</span-->property>
3. <!--</span-->bean>
messages.properties是按照資源包標(biāo)準(zhǔn)命名的，它代表了Acegi Securtiy支持的默認(rèn)語言。文件默認(rèn)是英文的。如果你不注冊一個消息源，Acegi Security仍然可以正常工作，它會用回硬編碼的英文消息。
如 果你想定制messages.properties文件，或者支持其他語言，那么你應(yīng)該copy這個文件，然后重命名，并在上述的bean定義中 注冊。因為文件中的key并不多，因此本地化花不了多少工夫。如果你針對消息文件進(jìn)行了本地化，那么請和社區(qū)分享，你可以添加一個JIRA任務(wù)，將你正確 命名的messages.properties本地化文件作為附件添加。
為了完善關(guān)于本地化的討論需要知道Spring的 ThreadLocal org.springframework.context.i18n.LocaleContextHolder。你應(yīng)該為每個用戶設(shè)置代表他區(qū)域的 LocaleContextHolder。Acegi Security會嘗試從這個ThreadLocal中獲取的Locale來從消息源中獲取消息。請參考Spring的文檔以獲取更多使用 LocaleContextHolder和能夠幫你自動設(shè)置它的輔助類(例如
AcceptHeaderLocaleResolver, CookieLocaleResolver, FixedLocaleResolver, SessionLocaleResolver 等)的詳細(xì)信息。
3.2. Filters
正如你在整個手冊中看到的那樣，Acegi Security使用很多filter。你可以使用FilterToBeanProxy或者FilterChainProxy來確定這些是怎樣加入到你的web應(yīng)用中的，下面我們來看看。
大部分filter使用FilterToBeanProxy來配置。例如下面web.xml中配置所示：
xml 代碼
1. <filter>
2. <filter-name>Acegi HTTP Request Security Filter</filter-name>
3. <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
4. <init-param>
5. <param-name>targetClass</param-name>
6. <param-value>org.acegisecurity.ClassThatImplementsFilter</param-value>
7. </init-param>
8. </filter>
注 意在web.xml中的filter實際上是一個FilterToBeanProxy，而不是真正實現(xiàn)filter邏輯的filter。 FilterToBeanProxy所作的是代理Filter的方法到一個從Spring的application context 獲取的bean。這使得這個bean可以享受Spring application context的生命周期支持以及配置靈活性。這個bean必須實現(xiàn)javax.servlet.Filter。
FilterToBeanProxy 只需要一個簡單的初始化參數(shù)，targetClass或者targetBean。targetClass會定位 application context中指定的類的第一個對象，而FilterToBeanProxy按照bean的名字定位對象。象標(biāo)準(zhǔn)的Spring web應(yīng)用一樣，F(xiàn)ilterToBeanProxy使用 WebApplicationContextUtils.getWebApplicationContext(ServletContext)來訪問 application context，所以你應(yīng)該在web.xml中配置一個ContextLoaderListener。
在IoC 容器而不是servlet容器中部署Filter會有一個生命周期的問題。特別是，哪個容器應(yīng)該負(fù)責(zé)調(diào)用Filter的"startup" 和 "shutdown"方法？注意到Filter的初始化和析構(gòu)順序隨servlet容器不同而不同，如果一個Filter依賴于由另一個更早初始化的 Filter的配置，這樣就會出現(xiàn)問題。另一方面，Spring IoC具備更加完善的生命周期/IoC接口（例如InitializingBean, DisposableBean, BeanNameAware, ApplicationContextAware以及其他許多）以及一個容易理解的接口契約（interface contract），可預(yù)見的方法調(diào)用順序，自動裝配支持，以及可以避免實現(xiàn)Spring接口的選項（例如Spring XML中的destroy-method 屬性）。因此，我們推薦盡可能使用Spring生命周期服務(wù)而不是servlet容器生命周期服務(wù)。FilterToBeanProxy默認(rèn)不會將 init(FilterConfig) 和 destroy()方法委派到被代理的bean。如果你需要這些調(diào)用被委派，那么將lifecycle初始化參數(shù)設(shè)置為servlet- container-managed。
我們強(qiáng)烈推薦你使用FilterChainProxy而不是FilterToBeanProxy。雖然 FilterToBeanProxy是一個非 常有用的類FilterToBeanProxy，問題是當(dāng)web.xml中filter變多時， 和 項就會太多而變得臃腫不堪。為了解決這個問題，Acegi Security提供一個FilterChainProxy類。它在FilterToBeanProxy中被裝配（正如上面例子中所示），但目標(biāo)類 （target class）是org.acegisecurity.util.FilterChainProxy。這樣過濾器鏈（filter chain）可以在application context中按照如下代碼配置：
xml 代碼
1. <bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
2. <property name="filterInvocationDefinitionSource">
3. <value>
4. CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
5. PATTERN_TYPE_APACHE_ANT
6. /webServices/*=httpSessionContextIntegrationFilterWithASCFalse,basicProcessingFilter,exceptionTranslationFilter,
7. /*=httpSessionContextIntegrationFilterWithASCTrue,authenticationProcessingFilter,exceptionTranslationFilter,filterSecurityInterceptor
8. <!--</span-->value>
9. <!--</span-->property>
10. <!--</span-->bean>
你 可能注意到FilterSecurityInterceptor定義方式的相似之處。同時支持正則表達(dá)式和Ant Paths格式，越對應(yīng)的URI越早出現(xiàn)。在運行時，F(xiàn)ilterChainProxy會定位符合當(dāng)前的web請求的第一個URI模式。每個對應(yīng)的配置屬 性代表了在application context中定義的一個bean的名字。接著fiter會按照它們被指定的順序，按照FilterChain的標(biāo)準(zhǔn)行為模式被調(diào)用(如果一個 Filter決定停止處理，它可以不在chain中執(zhí)行)。
如你所見，F(xiàn)ilterChainProxy需要為不同的請求模式重復(fù)配置 filter的名字（在上面的例子中，, exceptionTranslationFilter 和 filterSecurityInterceptor 是重復(fù)的）。這樣的設(shè)計是為了讓FilterChainProxy能夠為不同的URI配置不同的filter調(diào)用順序，同時也提高了表達(dá)力（針對正則表達(dá) 式、Ant Paths、以及任何FilterInvocationDefinitionSource的特定實現(xiàn)）和清晰度，可以知道是哪個filter應(yīng)該被調(diào)用。
你可能注意到了我們在filter chain定義了兩個HttpSessionContextIntegrationFilter (ASC是allowSessionCreation的縮寫,是HttpSessionContextIntegrationFilter的一個屬性)。 因為web服務(wù)不會為將來的請求提供一個jsessionid，為這樣的用戶創(chuàng)建HttpSessions是浪費的。如果你有一個需要最大限度的伸縮性的 高容量的應(yīng)用，我們建議你使用上述的方法。對于小的應(yīng)用，使用單一的HttpSessionContextIntegrationFilter (默認(rèn)的allowSessionCreation設(shè)為true)應(yīng)該足夠了。
說到生命周期問題，如果對FilterChainProxy自 身調(diào)用init(FilterConfig) 和 destroy()方法，它會把它代理到底層的filter。這樣FilterChainProxy保證只初始化和析構(gòu)每個filter一次，不論它在 FilterInvocationDefinitionSource中定義了多少次。你可以通過FilterToBeanProxy的lifecycle 初始化參數(shù)來控制這些方法是否被調(diào)用。如上面所討論的那樣，默認(rèn)所有servlet容器生命周期調(diào)用是不被代理到FilterChainProxy的。
在web.xml中定義的filter的順序是非常重要的。不管你實際用到哪個filter，的順序應(yīng)該是如下所示的：
1．ChannelProcessingFilter，因為可能要重定向到另一種協(xié)議。
2．ConcurrentSessionFilter 因為不使用任何SecurityContextHolder的功能，但是需要更新SessionRegistry來表示當(dāng)前的發(fā)送請求的principal。
3． HttpSessionContextIntegrationFilter, 這樣當(dāng)一個web請求開始的時候就可以在SecurityContextHolder中設(shè)置一個SecurityContext，當(dāng)web請求結(jié)束的時候 任何對SecurityContext的改動都會被copy到HttpSession（以備下一個web請求使用）。
4． Authentication processing mechanisms - AuthenticationProcessingFilter, CasProcessingFilter, BasicProcessingFilter, HttpRequestIntegrationFilter, JbossIntegrationFilter 等 - 修改SecurityContextHolder，使其中包含一個有效的認(rèn)證請求令牌（token）。
5．SecurityContextHolderAwareRequestFilter, 如果你使用它來在你的servlet容器中安裝一個Acegi Security aware HttpServletRequestWrapper。
6． RememberMeProcessingFilter, 如果早期的認(rèn)證處理過程沒有更新SecurityContextHolder，并且請求（request）提供了一個cookie啟用remember- me服務(wù)，一個合適的被記住的Authentication對象會被放到SecurityContextHolder那里。
7．AnonymousProcessingFilter, 如果早期的認(rèn)證處理過程沒有更新SecurityContextHolder，, 一個匿名Authentication 對象會被放到SecurityContextHolder那里。
8．ExceptionTranslationFilter, 捕獲所有的Acegi Security 異常，這樣要么返回一個HTTP錯誤響應(yīng)或者加載一個對應(yīng)的AuthenticationEntryPoint。
9．FilterSecurityInterceptor, 保護(hù) web URIs
所 有上述的filter使用FilterToBeanProxy或FilterChainProxy。建議在一個應(yīng)用中使用一個單個的 FilterToBeanProxy代理到一個單個的FilterChainProxy。，在FilterChainProxy中定義所有的Acegi Security Filters。如果你使用SiteMesh，確保Acegi Security filters 在 SiteMe**ers調(diào)用前調(diào)用。這樣使SecurityContextHolder在SiteMesh decorator使用前能夠
acegi參考手冊(v1.0.4)[譯]-第四章 信道安全
第四章. 信道安全
4.1. 概述
Acegi Security不僅能滿足你的認(rèn)證和授權(quán)的請求，而且能夠保證你的未認(rèn)證的web請求也能擁有某些屬性。這些屬性可能包括使用特定的傳輸類型，在HttpSession設(shè)置特定的屬性等等。Web請求的最普遍的需求是使用特定的傳輸協(xié)議，例如HTTPS。
在 傳輸安全中的一個重要議題就是會話劫持（session hijacking）。Web容器通過一個jsessionid來引用一個HttpSession，這個jsessionid通過cookie 或者URL重寫轉(zhuǎn)向（URL rewriting）發(fā)送到到客戶端。如果jsessionid是通過HTTP發(fā)送的，那么就存在被劫持以及在認(rèn)證過程之后冒充被認(rèn)證用戶的可能。這是因 為大部分的web容器為特定的用戶維護(hù)同一個會話標(biāo)識符，即便是用戶從HTTP 切換到 HTTPS頁面。
如果對于你的特定應(yīng)用來說，會話劫 持（session hijacking）是一個很嚴(yán)重的風(fēng)險，那么唯一的解決方法就是對每一個請求都使用HTTPS。這意味著jsessionid不會使用非安全信道傳輸。 你要保證你的web.xml中定義，把它指向一個HTTPS位置，同時應(yīng)用程序不把用戶指向一個HTTP位置。 Acegi Security提供一個解決方案幫助你實現(xiàn)后者。
4.2. 配置
啟用Acegi Security的信道安全服務(wù)，需要在web.xml中增加如下行：
xml 代碼
1. <filter>
2. <filter-name>Acegi Channel Processing Filter</filter-name>
3. <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
4. <init-param>
5. <param-name>targetClass</param-name>
6. <param-value>org.acegisecurity.securechannel.ChannelProcessingFilter</param-value>
7. </init-param>
8. </filter><filter-mapping>
9. <filter-name>Acegi Channel Processing Filter</filter-name>
10. <url-pattern>/*</url-pattern>
11. </filter-mapping>
和平時一樣，你同樣需要在application context中配置filter
java 代碼
1. "channelProcessingFilter" class="org.acegisecurity.securechannel.ChannelProcessingFilter">
2. "channelDecisionManager">"channelDecisionManager"/>
3. "filterInvocationDefinitionSource">
4.
5. CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
6. \A/secure/.*\Z=REQUIRES_SECURE_CHANNEL
7. \A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
8. \A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
9. \A.*\Z=REQUIRES_INSECURE_CHANNEL
10.
11.
12.
13.
14. "channelDecisionManager" class="org.acegisecurity.securechannel.ChannelDecisionManagerImpl">
15. "channelProcessors">
16.
17. "secureChannelProcessor"/>
18. "insecureChannelProcessor"/>
19.
20.
21.
22.
23. "secureChannelProcessor" class="org.acegisecurity.securechannel.SecureChannelProcessor"/>
24.
25. "insecureChannelProcessor" class="org.acegisecurity.securechannel.InsecureChannelProcessor"/>
ChannelProcessingFilter和FilterSecurityInterceptor一樣支持Apache Ant style paths。
ChannelProcessingFilter 的工作方式是過濾所有的web請求，并將判斷將適合的配置屬性應(yīng)用于其上。然后它代理到 ChannelDecisionManager。默認(rèn)的實現(xiàn)類ChannelDecisionManagerImpl應(yīng)該能夠滿足大多數(shù)需求。它就代理到 配置好的ChannelProcessor實例列表。ChannelProcessor會檢視請求，如果它不滿意請求（例如請求是發(fā)送自不正確的傳輸協(xié) 議）它將會重定向，拋出異常或者采取其他任何恰當(dāng)?shù)拇胧?
Acegi Security 包括ChannelProcessor兩個實體類實現(xiàn)：SecureChannelProcessor 保證配置了REQUIRES_SECURE_CHANNEL 屬性的請求都是從HTTPS發(fā)送過來的。而InsecureChannelProcessor 保證配置了REQUIRES_INSECURE_CHANNEL 屬性的請求都是從HTTP發(fā)送過來的。如果沒有使用請求的協(xié)議，這兩個實現(xiàn)都會轉(zhuǎn)到ChannelEntryPoint，而兩個 ChannelEntryPoint 實現(xiàn)所作的就是簡單的把請求相應(yīng)按照HTTP 和 HTTPS重定向。
要注意重定向是絕對（例如 http://www.company.com:8080/app/page ） 而不是相對的(例如 /app/page)。在測試中發(fā)現(xiàn)Internet Explorer 6 Service Pack 1 有一個bug，因此如果在重定向的時候也改變使用的端口，它就不能正確響應(yīng)。對應(yīng)這個bug，在很多Acegi Security bean中都會使用的PortResolverImpl也使用絕對URL。請參閱PortResolverImpl的JavaDoc以獲取更多信息。
你 要注意使用為了在登錄過程中保證用戶名和密碼的安全，要使用安全信道。如果你配合基于表單的登錄使用 ChannelProcessingFilter，請記得一定要把你的登錄頁面設(shè)置為REQUIRES_SECURE_CHANNEL，并且 AuthenticationProcessingFilterEntryPoint.forceHttps屬性設(shè)置為true。
4.3. 結(jié)論
一 旦配置好了，使用安全信道是非常簡單的。只要請求頁面，不用管使用什么協(xié)議（HTTP 或 HTTPS）或什么端口（80, 8080, 443, 8443等）。顯然你只要確定初始請求(獲取通過在web.xml 中的 或一個眾所周知的主頁URL)，完成以后filter會執(zhí)行你application context定義的重定向。
你也可以在ChannelDecisionManagerImpl中增加自己的ChannelProcessor實現(xiàn)。例如，你可能通過"輸入圖片中的內(nèi)容"檢測到一個個人類用戶，然后在HttpSession中設(shè)置一個屬性。
要判斷一個安全檢查應(yīng)該是或者ChannelProcessor或是 AccessDecisionVoter 記得前者是設(shè)計用來處理認(rèn)證或者未認(rèn)證的請求，而后者是設(shè)計用來處理已認(rèn)證的請求。因此后者可以訪問已認(rèn)證的principal被授予的權(quán)限。
另 外，ChannelProcessor檢測到問題后一般是引發(fā)一個HTTP/HTTPS重定向這樣他的請求可以被滿足，而 AccessDecisionVoter將則會跑出一個AccessDeniedException異常(取決于支配的 AccessDecisionManager)。
acegi參考手冊(v1.0.4)[譯]-第五章 標(biāo)簽庫
5.1. 概述
Acegi Security帶有若干個可以降低JSP編寫難度的JSP標(biāo)簽庫。標(biāo)簽庫的標(biāo)志是authz，它提供了一些各不相同的服務(wù)。
5.2. 配置
所 有的標(biāo)簽庫類都包含在acegi-security-xx.jar文件中，authz.tld在JAR的META-INF目錄。這意味著如果在 JSP1.2以上的wb容器中，你只要把JAR文件放到WEB-INF/lib目錄它就可用了。如果你使用JSP1.1容器，你需要在web.xml文件 中聲明JSP標(biāo)簽庫，并在WEB-INF/lib中包含authz.tld文件。將如下片段加入到web.xml中：
java 代碼
1.
2. http://acegisecurity.org/authz
3. /WEB-INF/authz.tld
4.
第六章. 通用認(rèn)證服務(wù)
6.1. Mechanisms, Providers 和 Entry Points
如果你使用Acegi Security提供的認(rèn)證方法，那么通常你需要配置一個web filter，一個AuthenticationProvider
以及AuthenticationEntryPoint。在本節(jié)我們將要瀏覽一個示例應(yīng)用，它需要支持基于form的認(rèn)證（例如提供給用戶登錄的HTML頁面）以及基礎(chǔ)認(rèn)證（例如web service或者類似的可以訪問受保護(hù)資源）。
在web.xml中，這個應(yīng)用需要一個單獨的Acegi Security filter來使用FilterChainProxy。幾乎所有的Acegi Security應(yīng)用都有一個類似的項，看起來象下面這樣：
xml 代碼
1. <filter>
2. <filter-name>Acegi Filter Chain Proxy</filter-name>
3. <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
4. <init-param>
5. <param-name>targetClass</param-name>
6. <param-value>org.acegisecurity.util.FilterChainProxy</param-value>
7. </init-param>
8. </filter>
9. <filter-mapping>
10. <filter-name>Acegi Filter Chain Proxy</filter-name>
11. <url-pattern>/*</url-pattern>
12. </filter-mapping>
上 述聲明將使每個web請求都要經(jīng)過Acegi Security的FilterChainProxy。正如在本手冊的filter那節(jié)中所說，F(xiàn)ilterChainProxy是一個通用類，它使得 web請求按照URL模式被發(fā)送到不同的filter。那些被委派的filter是由application context管理的，因此它們可以享受依賴注射的好處。我們來看看在你的application context中FilterChainProxy的定義會是什么樣的：
xml 代碼
1. <bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
2. <property name="filterInvocationDefinitionSource">
3. <value>
4. CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
5. PATTERN_TYPE_APACHE_ANT
6. /**=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,basicProcessingFilter,securityContextHolderAwareRequestFilter,</value>
7. </property>
8. </bean>
在內(nèi)部，Acegi Security會使用PropertyEditor來將上述XML片段中的字符串轉(zhuǎn)化為一個 FilterInvocationDefinitionSource對象。在這個階段需要注意的是，一系列的filter會按照定義的順序運行，并且這些 filter實際就是application context中的bean的。所以，在我們的例子中，會在application context出現(xiàn)另外一些bean，它們會被命名為httpSessionContextIntegrationFilter, logoutFilter 等。Filter出現(xiàn)的順序會在手冊中filter那一節(jié)討論，雖然上述的例子中它們是正確的。
在我們的 例子中，我們使用了AuthenticationProcessingFilter和BasicProcessingFilter。它們分別對應(yīng)了基于 form的認(rèn)證和BASIC HTTP header-based認(rèn)證的“認(rèn)證機(jī)制”（我們在手冊的前面部分討論了認(rèn)證機(jī)制扮演的角色）。如果你既不使用form也不使用BASIC認(rèn)證，就不需 要定義這些bean了。取而代之的是你要定義對應(yīng)你所需要的認(rèn)證環(huán)境的filter，例如DigestProcessingFilter 或者CasProcessingFilter。請對照手冊中對應(yīng)的章節(jié)來了解如何配置這些認(rèn)證機(jī)制。
讓我們回憶一下，在 HttpSessionContextIntegrationFilter中保存了每個HTTP session調(diào)用中的SecurityContext。這意味著認(rèn)證機(jī)制只會在principal最初嘗試認(rèn)證的時候被使用一次。在余下的時間內(nèi)，認(rèn)證 機(jī)制只是靜靜的待在那里，將請求發(fā)往filter鏈中的下一個filter。這個基于實際的需求源于這樣的一個事實，很少有認(rèn)證實現(xiàn)在每一個，每一次的調(diào) 用的時候都會進(jìn)行認(rèn)證（BASIC認(rèn)證是一個值得注意的例外），但是如果一個pricipal在最初的認(rèn)證步驟之后帳號被取消了，或者被禁用了，或者被修 改了（例如GrantedAuthority[]中增加或者減少）會怎么樣呢？讓我們來看看現(xiàn)在這些情況是如何處理的。
前面已經(jīng)介紹 了安全對象的主要認(rèn)證provider AbstractSecurityInterceptor。這個類需要能夠訪問一個AuthenticationManager。它同時有個可選配置可以 設(shè)定一個認(rèn)證對象每次安全對象調(diào)用的時候是否需要重新認(rèn)證。如果Authentication.isAuthenticated()返回true，那么它 默認(rèn)在SecurityContextHolder中的認(rèn)證對象是已認(rèn)證的。這樣做對于提高性能是非常好的，但是對于即時的認(rèn)證驗證是不理想的。在這樣的 情況下你可能需要將AbstractSecurityInterceptor.alwaysReauthenticate屬性設(shè)置為true。
你 可能會問自己“這個AuthenticationManager是什么？”我們之前沒有見過它，但是我們曾經(jīng)討論過 AuthenticationProvider的概念。非常簡單，AuthenticationManager負(fù)責(zé)在 AuthenticationProvider鏈之間傳遞請求。它非常象我們之前討論過的filter鏈，雖然有一些不同。Acegi Security只提供了一個AuthenticationManager實現(xiàn)，因此讓我們看看對于我們這章的例子，它是如何配置的：
xml 代碼
1. <bean id="authenticationManager" class="org.acegisecurity.providers.ProviderManager">
2. <property name="providers">
3. <list>
4. <ref local="daoAuthenticationProvider"/>
5. <ref local="anonymousAuthenticationProvider"/>
6. <ref local="rememberMeAuthenticationProvider"/>
7. </list>
8. </property>
9. </bean>
在這個時候，可能值得提到的是你的認(rèn)證機(jī)制（通常是filter）也被注入了一個AuthenticationManager的引用。所以和認(rèn)證機(jī)制都會使用上述的ProviderManager來輪詢一系列的AuthenticationProvider。
在 我們例子中有三個provider。它們按照上述的順序調(diào)用（使用list而不是set來顯示是按照順序調(diào)用的），每個provider都能夠嘗試認(rèn)證， 或者僅僅返回一個null來跳過認(rèn)證。如果所有的實現(xiàn)都返回null，ProviderManager會拋出一個相應(yīng)的異常。如果你想了解更多 chaining providers的信息，請參閱ProviderManager的JavaDoc。
authentication mechanism使用的那些provider有時候是可以互換的，而有時候它們又依賴于特定的authentication mechanism。例如，DaoAuthenticationProvider只需要一個基于字符串的用戶名和密碼。若干個認(rèn)證機(jī)制會產(chǎn)生基于字符串的 用戶名和密碼的集合，包括（但不限于）BASIC 和 form 認(rèn)證。同時，有些認(rèn)證機(jī)制會產(chǎn)生一個只能和特定類型的AuthenticationProvider交互的認(rèn)證請求對象。一個這種一對一映射的例子是JA -SIG CAS，它使用service ticket的概念，只能被Common Authentication Services CasAuthenticationProvider認(rèn)證。一個更加深入的一對一映射的例子是LDAP認(rèn)證機(jī)制，它只能由 LdapAuthenticationProvider處理。這種特定的對應(yīng)關(guān)系在每個類的JavaDoc以及在本手冊的特定認(rèn)證方法章節(jié)中有詳細(xì)說明。 你不用擔(dān)心這些實現(xiàn)的細(xì)節(jié)，因為如果你忘記注冊一個合適的provider，你在嘗試認(rèn)證時只會收到一個 ProviderNotFoundException異常。
當(dāng)你在FilterChainProxy中正確配置了認(rèn)證機(jī)制，并且確保 注冊了對應(yīng)的AuthenticationProvider，你的最后一步是配置一個AuthenticationEntryPoint。回憶一下早先我 們討論過的ExceptionTranslationFilter的角色，當(dāng)一個基于HTTP的請求收到一個HTTP頭或者一個HTTP重定向以開始認(rèn)證 時它被使用。繼續(xù)我們早先的例子：
xml 代碼
1. <bean id="exceptionTranslationFilter" class="org.acegisecurity.ui.ExceptionTranslationFilter">
2. <property name="authenticationEntryPoint"><ref
3. local="authenticationProcessingFilterEntryPoint"/></property>
4. <property name="accessDeniedHandler">
5. <bean class="org.acegisecurity.ui.AccessDeniedHandlerImpl">
6. <property name="errorPage" value="/accessDenied.jsp"/>
7. </bean>
8. </property>
9. </bean>
10. <bean id="authenticationProcessingFilterEntryPoint"
11. class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint">
12. <property name="loginFormUrl"><value>/acegilogin.jsp</value></property>
13. <property name="forceHttps"><value>false</value></property>
14. </bean>
注 意到ExceptionTranslationFilter需要兩個協(xié)作者。第一個AccessDeniedHandlerImpl，使用一個 RequestDispatcher導(dǎo)向顯示特定的訪問拒絕的錯誤頁面。我們使用forwad所以SecurityContextHolder中仍然保留 principal的詳細(xì)信息，這些對于顯示給用戶來說是有用的（在Acegi Security的老版本中，我們依賴rervlet容器來處理403錯誤信息，它缺乏這個有用的上下文信息）。 AccessDeniedHandlerImpl同時將會將HTTP頭設(shè)置為403，它是訪問拒絕的正式錯誤代碼。至于 AuthentionEntryPoint，這里設(shè)置如果一個未受認(rèn)證的principal嘗試執(zhí)行一個受保護(hù)的操作時，我們需要執(zhí)行那些動作。因為在我 們的例子中要使用基于form的認(rèn)證，因此我們設(shè)定AuthenticationProcessinFilterEntryPoint以及登錄頁面的 URL。你的應(yīng)用系統(tǒng)通常只需要一個entry point，并且大多數(shù)的認(rèn)證方法都定義了自己特有的AuthenticationEntryPoint。每個認(rèn)證方式所對應(yīng)的特定entry point的詳細(xì)情況會在本手冊特定的認(rèn)證方法章節(jié)中介紹。
6.2. UserDetails 和 Associated Types
正如在第一部分中提到的，大多數(shù)認(rèn)證provider要用到UserDetails 和UserDetailsService 接口。后面那個接口只包含一個方法：
java 代碼
1. public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException,
2. DataAccessException;
返 回值UserDetails是一個接口，它提供了若干個getter保證返回非null值，例如用戶名，密碼，授予的權(quán)限以及用戶是啟用還是禁用狀態(tài)。大 部分認(rèn)證provider都會使用一個，即使它在認(rèn)證判斷過程中實際并不使用用戶名和密碼。通常這些provider只會使用返回的 UserDetails中的GrantedAuthority[]信息，因為有些系統(tǒng)（例如LDAP 或 X509 或 CAS）已經(jīng)承擔(dān)了實際的身份驗證的責(zé)任。
Acegi Security提供了一個UserDetails的實體類實現(xiàn)－User。Acegi Security用戶需要確定什么時候?qū)崿F(xiàn)UserDetailsService以及返回什么樣的UserDetails實體類。通常，直接使用User 類或者繼承User類就可以了，盡管有一些特殊情況(例如 object relational mappers)，需要用戶從頭寫他們自己的UserDetails實現(xiàn)。這種情況也時有發(fā)生，用戶只要返回他們正常的代表系統(tǒng)用戶的領(lǐng)域?qū)ο缶涂梢粤恕?特別是UserDetails經(jīng)常被用來存儲額外的principal相關(guān)屬性（例如他們的電話號碼以及email地址），這樣它們可以很容易被web視 圖使用。
特定的UserDetailsService實現(xiàn)起來是很簡單的，它應(yīng)該很容易由用戶來選擇持久化策略來獲取認(rèn)證信息。說到這里，Acegi Security確實包含了一些有用的基礎(chǔ)實現(xiàn)，下面讓我們看一下。
6.2.1. In-Memory 認(rèn)證
雖 然用戶可以創(chuàng)建一個定制的UserDetailsService實現(xiàn)來從一個持久化引擎中獲取信息，很多應(yīng)用不需要這種復(fù)雜性。特別是如果你正在進(jìn)行快速 原型開發(fā)或者剛開始集成Acegi Security，當(dāng)你不需要花費時間來進(jìn)行數(shù)據(jù)庫配置或者寫UserDetailsService的實現(xiàn)。這種情況之下，你有一個簡單的選擇，就是配置 InMemoryDaoImpl實現(xiàn)。
xml 代碼
1. <bean id="inMemoryDaoImpl" class="org.acegisecurity.userdetails.memory.InMemoryDaoImpl">
2. <property name="userMap">
3. <value>
4. marissa=koala,ROLE_TELLER,ROLE_SUPERVISOR
5. dianne=emu,ROLE_TELLER
6. scott=wombat,ROLE_TELLER
7. peter=opal,disabled,ROLE_TELLER
8. </value>
9. </property>
10. </bean>
在 上面的例子中，userMap屬性包含了每個用戶的用戶名，密碼，一個授權(quán)列表以及一個可選的啟用/禁用關(guān)鍵詞。使用逗號分隔。用戶名必須在等號的左側(cè)， 密碼必須在等號右側(cè)第一個出現(xiàn)。啟用和禁用關(guān)鍵詞（大小寫敏感）可以出現(xiàn)在第二個或者之后任意位置。剩余的字符串被看作是授予的權(quán)限，這些權(quán)錢被創(chuàng)建為 GrantedAuthorityImpl對象（僅供參考－大多數(shù)的應(yīng)用不需要自定義的GrantedAuthority實現(xiàn)，所以使用默認(rèn)的實現(xiàn)就可以 了）。注意如果一個用戶沒有密碼及或沒有被授予權(quán)限，該用戶不會在in-memory 認(rèn)證庫中創(chuàng)建。
InMemoryDaoImpl 也提供了一個setUserProperties(Properties)方法，可以允許你用另一個Spring的配置好的bean或者一個外部的 properties文件來實例化屬性。你可能要使用Spring的PropertiesFactoryBean，它在加載外部屬性文件的時候非常有用。 這個setter可能對于有大量用戶的應(yīng)用，或者開發(fā)期配置變更有所助益，但是不要指望使用整個數(shù)據(jù)庫來處理認(rèn)證細(xì)節(jié)。
6.2.2. JDBC 認(rèn)證
也 包括了一個從JDBC數(shù)據(jù)源獲取認(rèn)證信息的UserDetailsService。使用Spring內(nèi)部的JDBC，避免了僅僅為了存儲用戶信息而使用復(fù) 雜的對象關(guān)系Common Authentication Services 映射（ORM）。如果你確實使用ORM工具，你可能要寫一個定制的UserDetailsService來重用你已經(jīng)創(chuàng)建的映射文件。回到 JdbcDaoImpl，下面是一個配置的例子：
xml 代碼
1. <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
2. <property name="driverClassName"><value>org.hsqldb.jdbcDriver</value></property>
3. <property name="url"><value>jdbc:hsqldb:hsql://localhost:9001</value></property>
4. <property name="username"><value>sa</value></property>
5. <property name="password"><value></value></property>
6. </bean>
7. <bean id="jdbcDaoImpl" class="org.acegisecurity.userdetails.jdbc.JdbcDaoImpl">
8. <property name="dataSource"><ref bean="dataSource"/></property>
9. </bean>
10.
你 可能要修改上述的DriverManagerDataSource來使用不同的關(guān)系數(shù)據(jù)庫管理系統(tǒng)。你還可以使用從JNDI獲取的全局?jǐn)?shù)據(jù)源，如上的常規(guī) Spring選項。不論是使用什么數(shù)據(jù)庫以及如何獲取數(shù)據(jù)源，必須使用一個按照dbinit.txt中寫明的數(shù)據(jù)庫模式。你可以從Acegi Security網(wǎng)站下載這個文件。
如果你的默認(rèn)數(shù)據(jù)庫模式不能滿足需要，JdbcDaoImpl提供了兩個屬性允許定制SQL語 句。如果需要進(jìn)一步定制，你可以繼承JdbcDaoImpl。請參考JavaDocs獲取詳情，不過請注意這個類并不是為了復(fù)雜的自定義繼承而寫的。如果 你的需求比較復(fù)雜(例如數(shù)據(jù)庫結(jié)構(gòu)比較特殊或者需要返回一個特定的UserDetails實現(xiàn))，那么你最好寫自己的 UserDetailsService實現(xiàn)。Acegi Security提供的基礎(chǔ)實現(xiàn)只是為了典型場景，并沒有提供無限的配置靈活性。
6.3. 并行Concurrent Session 處理
Acegi Security能夠限定次數(shù)防止一個principal多次并行認(rèn)證到同一個應(yīng)用。許多ISV利用這一點來加強(qiáng)授權(quán)管理，網(wǎng)管也喜歡這個特性因為可以防止一個用戶名被重復(fù)使用。例如，你可以限制“Batman”用戶從兩個不同的session登錄系統(tǒng)。
使用并行session支持，你需要在web.xml中增加如下內(nèi)容：
xml 代碼
1. <listener>
2. <listener-class>org.acegisecurity.ui.session.HttpSessionEventPublisher</listener-class>
3. </listener>
而 且，你需要在中FilterChainProxy增加 org.acegisecurity.concurrent.ConcurrentSessionFilter to your FilterChainProxy。ConcurrentSessionFilter需要兩個屬性，sessionRegistry用來指向一個 SessionRegistryImpl實例，expiredUrl指向一個session實效時顯示的頁面。
當(dāng)一個 HttpSession開始或者結(jié)束的時候web.xml HttpSessionEventPublisher發(fā)送一個ApplicationEvent到Spring ApplicationContext。這很關(guān)鍵，因為它確保session終止的時候SessionRegistryImpl會收到通知。
你還要裝配ConcurrentSessionControllerImpl并在ProviderManager中引用：
xml 代碼
1. <bean id="authenticationManager" class="org.acegisecurity.providers.ProviderManager">
2. <property name="providers">
3. <!-- your providers go here -->
4. </property>
5. <property name="sessionController"><ref bean="concurrentSessionController"/></property>
6. </bean>
7. <bean id="concurrentSessionController"
8. class="org.acegisecurity.concurrent.ConcurrentSessionControllerImpl">
9. <property name="maximumSessions"><value>1</value></property>
10. <property name="sessionRegistry"><ref local="sessionRegistry"/></property>
11. </bean>
12. <bean id="sessionRegistry" class="org.acegisecurity.concurrent.SessionRegistryImpl"/>
6.4. 認(rèn)證標(biāo)簽庫
AuthenticationTag只是用來把principal的Authentication.getPrincipal()對象的屬性顯示到web頁面。
下面的JSP片段展示了如何使用AuthenticationTag：
java 代碼
1. "username"/>
這個標(biāo)簽將會顯示pricipal的名字。這里我們假設(shè)Authentication.getPrincipal()是一個UserDetails對象，這在使用典型的DaoAuthenticationProvider時候的一般狀況。
[轉(zhuǎn)載自 dxjsunday]
凡是有該標(biāo)志的文章，都是該blog博主Caoer（草兒）原創(chuàng)，凡是索引、收藏
、轉(zhuǎn)載請注明來處和原文作者。非常感謝。