第二章. 技術概覽

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對象。

 

你可以在你的應用程序中的任何地方使用下述的代碼塊：

 

上述的代碼展示了一些有趣的聯系和關鍵的對象。首先，你會注意到在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）”。當認證信息從客戶代理收集過來以后，一個“認證請求（Authentication request）”對象被創建，并發送到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中。這非常容易做，也是一種廣泛支持的集成方式。