第二章. 技術(shù)概覽

2.1. 運行時環(huán)境

Acegi Security可以在JRE1.3中運行。這個發(fā)行版本中支持也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)）直接從一個系統(tǒng)copy到另一個系統(tǒng)，它馬上就可以運行起來。

 

2.2. 共享組件

讓我們來看看Acegi Security中最重要的一些共享組件。所謂共享組件是指在框架中處于核心地位，系統(tǒng)脫離了它們之后就不能運行。這些Java類型代表了系統(tǒng)中其他部分的構(gòu)建單元，因此理解它們是非常重要的，即使你不需要直接和它們打交道。

 

最基礎的對象是SecurityContextHolder。在這里存儲了當前應用的安全上下文（security context），包括正在使用應用程序的principal的詳細信息。SecurityContextHolder默認使用ThreadLocal來存儲這些詳細信息，這意味著即便安全上下文（security context）沒有被作為一個參數(shù)顯式傳入，它仍然是可用的。如果在當前principal的請求處理后清理線程,那么用這種方式使用ThreadLocal是非常安全的。當然， Acegi Security自動為你處理這些，所以你無需擔心。

 

有些應用程序由于使用線程的方式而并不是完全適用ThreadLocal。例如，Swing客戶端可能需要一個Java Virtual Machine中的所有線程都使用同樣的安全上下文（security context）。在這種情況下你要使用SecurityContextHolder.MODE_GLOBAL模式。另外一些應用程序可能需要安全線程產(chǎn)生的線程擁有同樣的安全標識符（security identity）。這可以通過SecurityContextHolder.MODE_INHERITABLETHREADLOCAL來實現(xiàn)。你可以通過兩種方法來修改默認的SecurityContextHolder.MODE_THREADLOCAL。第一種是設置一個系統(tǒng)屬性。或者，調(diào)用SecurityContextHolder的一個靜態(tài)方法。大部分的應用程序不需要修改默認值，不過如果你需要，那么請查看SecurityContextHolder的JavaDocs獲取更多信息。

 

我們在SecurityContextHolder中存儲當前和應用程序交互的principal的詳細信息。Acegi Security使用一個Authentication對象來代表這個信息。盡管你通常不需要自行創(chuàng)建一個Authentication對象，用戶還是經(jīng)常會查詢Authentication對象。

 

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

 

上述的代碼展示了一些有趣的聯(lián)系和關鍵的對象。首先，你會注意到在SecurityContextHolder和Authentication之間有一個媒介對象。SecurityContextHolder.getContext() 方法實際上返回一個SecurityContext。Acegi Security使用若干個不同的SecurityContext實現(xiàn)，以備我們需要存儲一些和principal無關的特殊信息。一個很好的例子就是我們的Jcaptcha集成，它需要知道一個需求是否是由人發(fā)起的。這樣的判斷和principal是否通過認證完全沒有關系，因此我們將它保存在SecurityContext中。

 

從上述的代碼片段可以看出的另一個問題是你可以從一個Authentication對象中獲取一個principal。Principal只是一個對象。通常可以把它cast為一個UserDetails對象。UserDetails在Acegi Security中是一個核心接口，它以一種擴展以及應用相關的方式來展現(xiàn)一個principal。可以把UserDetails看作是你的用戶數(shù)據(jù)庫和Acegi Security在SecurityContextHolder所需要的東西之間的一個適配器（adapter）。作為你自己用戶數(shù)據(jù)庫的一個展現(xiàn)，你可能經(jīng)常要把它cast到你應用程序提供的原始對象，這樣你就可以調(diào)用業(yè)務相關的方法(例如 getEmail(), getEmployeeNumber())。

 

現(xiàn)在你可能已經(jīng)開始疑惑，那我什么時候提供UserDetails對象呢？我要如何提供呢？

我想你告訴過我這個東西是聲明式的，我不需要寫任何Java代碼－那怎么做到呢？對此的簡短回答就是有一個叫做UserDetailsService的特殊接口。這個接口只有一個方法，接受一個Sring類型的參數(shù)并返回一個UserDetails。Acegi Security提供的大多數(shù)認證提供器將部分認證過程委派給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è)應用程序中的用戶。要記得這樣做的好處，不論你的UserDetailsService返回什么，它總是可以從SecurityContextHolder中獲取，象上面的代碼顯示的那樣。

 

除了principal，Authentication提供的另一個重要方法就是getAuthorities（）。這個方法返回一個GrantedAuthority對象數(shù)組。GrantedAuthority，毫無疑問，就是授予principal的權(quán)限。這些權(quán)限通常是“角色”，例如ROLE_ADMINISTRATOR 或者ROLE_HR_SUPERVISOR。這些角色稍后配置到web授權(quán)，方法授權(quán)和領域?qū)ο笫跈?quán)。Acegi Security的其他部分能夠處理這些權(quán)限，并且期待他們被提供。通常你會從UserDetailsService中返回GrantedAuthority對象。

 

通常GrantedAuthority對象都是應用范圍的權(quán)限。它們都不對應特定的領域?qū)ο蟆Ｒ虼耍�你應該不會有一個代表54號員工對象的GrantedAuthority，因為這樣會有數(shù)以千計的authority，你馬上就會用光所有內(nèi)存（或者，至少會讓系統(tǒng)花太長時間來認證一個用戶）。當然，Acegi Security會高效的處理這種普遍的需求，但是你不會使用領域?qū)ο蟀踩�功能來實現(xiàn)這個目的。

 

最后，但不是不重要，你有時候需要在HTTP 請求之間存儲SecurityContext。另外有些時候你在每次請求的時候都會重新認證principal，不過大部分時候你會存儲SecurityContext。HttpSessionContextIntegrationFilter在HTTP之間存儲SecurityContext。正如類名字顯示的那樣，它使用HttpSession來進行存儲。基于安全原因，你永遠都不要直接和HttpSession交互。沒有理由這么做，所以記得使用SecurityContextHolder來代替。

 

讓我們回憶一下，Acegi Security的基本組成構(gòu)件是：

• SecurityContextHolder,提供對SecurityContext的所有訪問方式。

• SecurityContext, 存儲Authentication以及可能的請求相關的安全信息。

• HttpSessionContextIntegrationFilter, 在web請求之間把SecurityContext存儲在HttpSession中。

• Authentication, 以Acegi Security的方式表現(xiàn)principal。

• GrantedAuthority, 表示賦予一個principal的應用范圍的權(quán)限。

• UserDetails, 為從你的應用程序DAO中獲取必要的信息來構(gòu)建一個Authentication 對象。

• UserDetailsService,用傳入的String類型的username（或者認證ID，或類似）來創(chuàng)建一個UserDetails。

 

現(xiàn)在你已經(jīng)理解了這些重復使用的組件，讓我們仔細看看認證過程吧。

 

2.3. 認證

正如我們在手冊開始部分所說的那樣，Acegi Security適用于很多認證環(huán)境。雖然我們建議大家使用Acegi Security自身的認證功能而不是和容器管理認證（Container Managed Authentication）集成，但是我們?nèi)匀恢С诌@種和你私有的認證系統(tǒng)集成的認證。讓我們先從Acegi Security完全自行管理管理web安全的角度來探究一下認證，這也是最復雜和最通用的情形。

 

想象一個典型的web應用的認證過程：

 

1．你訪問首頁，點擊一個鏈接。

2．一個請求被發(fā)送到服務器，服務器判斷你是否請求一個被保護的資源。

3．因為你當前未被認證，服務器發(fā)回一個回應，表明你必須通過認證。這個回應可能是一個HTTP回應代碼，或者重定向到一個特定的網(wǎng)頁。

4．基于不同的認證機制，你的瀏覽器會重定向到一個網(wǎng)頁好讓你填寫表單，或者瀏覽器會用某種方式獲取你的身份認證（例如一個BASIC認證對話框，一個cookie，一個X509證書等等。）。

5．瀏覽器會發(fā)回給服務器一個回應。可能是一個包含了你填寫的表單內(nèi)容的HTTP POST，或者一個包含你認證詳細信息的HTTP header。

6．接下來服務器會判斷提供的認證信息是否有效。如果它們有效，你進入到下一步。如果它們無效，那么通常請求你的瀏覽器重試一次（你會回到上兩步）。

7．你引發(fā)認證的那個請求會被重試。但愿你認證后有足夠的權(quán)限訪問那些被保護的資源。如果你有足夠的訪問權(quán)限，請求就會成功。否則，你將會受到一個意味“禁止”的HTTP403錯誤代碼。

 

在Acegi Security中，對應上述的步驟，有對應的類。主要的參與者（按照被使用的順序）是：ExceptionTranslationFilter， AuthenticationEntryPoint， 認證機制(authentication mechanism)， 以及AuthenticationProvider。

 

ExceptionTranslationFilter是Acegi Security用來檢測任何拋出的安全異常的過濾器(filter)。這種異常通常是由AbstractSecurityInterceptor拋出的，它是授權(quán)服務的主要提供者。我們將會在下一部分討論AbstractSecurityInterceptor，現(xiàn)在我們只需要知道它產(chǎn)生Java異常，并且對于HTTP或者如何認證一個principal一無所知。反而是ExceptionTranslationFilter提供這樣的服務，它負責要么返回403錯誤代碼(如果principal通過了認證，只是缺少足夠的權(quán)限，象上述第7步那樣)，要么加載一個AuthenticationEntryPoint (如果principal還沒有被認證，那么我們要從第3步開始)。

 

AuthenticationEntryPoint負責上述的第3步。如你所想，每個web應用都有一個默認的認證策略（象Acegi Security中幾乎所有的東西一樣，它也是可配置的，不過我們現(xiàn)在還是還是從簡單開始）。每個主流的認證系統(tǒng)都有它自己的AuthenticationEntryPoint實現(xiàn)，負責執(zhí)行第3步中描述的動作。

 

當瀏覽器確定要發(fā)送你的認證信息（HTTP 表單或者HTTP header），服務器上需要有什么東西來“收集”這些認證信息。現(xiàn)在我們在上述的第6步。在Acegi Security中對從用戶代理（通常是瀏覽器）收集認證信息有一個特定的名字，這個名字是“認證機制（authentication mechanism）”。當認證信息從客戶代理收集過來以后，一個“認證請求（Authentication request）”對象被創(chuàng)建，并發(fā)送到AuthenticationProvider。

 

Acegi Security中認證的最后一環(huán)是一個AuthenticationProvider。非常簡單，它的職責是取用一個認證請求（Authentication request）對象，并且判斷它是否有效。這個provider要么拋出一個異常，要么返回一個組裝完畢的Authentication對象。還記得我們的好朋友UserDetails 和 UserDetailsService吧？如果沒有，回到前一部分重新回憶一下。大部分的AuthenticationProviders都會要求UserDetailsService提供一個UserDetails對象。如前所述，大部分的應用程序會提供自己的UserDetailsService，盡管有些會使用Acegi Security提供的JDBC或者 in-memory實現(xiàn)。作為成品的UserDetails 對象，特別是其中的GrantedAuthority[]s，在構(gòu)建完備的Authentication對象時會被使用。

 

當認證機制（authentication mechanism）取回組裝完全的Authentication對象后，它將會相信請求是有效的，將Authentication放到SecurityContextHolder中，并且將原始請求取回（上述第7步）。反之，AuthenticationProvider則拒絕請求，認證機制（authentication mechanism）會請求用戶重試（上述第2步）。

 

在講述典型的認證流程的同時，有個好消息是Acegi Security不關心你是如何把Authentication放到SecurityContextHolder內(nèi)的。唯一關鍵的是在AbstractSecurityInterceptor授權(quán)一個請求之前，在SecurityContextHolder中包含一個代表了principal的Authentication。

 

你可以（很多用戶確實）實現(xiàn)自己的過濾器（filter）或者MVC控制器（controller）來提供和不是基于Acegi Security的認證系統(tǒng)交互。例如，你可能使用使用容器管理認證（Container Managed Authentication），從ThreadLocal 或者JNDI中獲取當前用戶信息，使得它有效。或者，你工作的公司有一個遺留的私有認證系統(tǒng)，而它是公司“標準”，你對它無能為力。在這種情況之下也是非常容易讓Acegi Security運作起來，提供認證能力。你所需要做的是寫一個過濾器（或等價物）從某處讀取第三方用戶信息，構(gòu)建一個Acegi Security式的Authentication對象，把它放到SecurityContextHolder中。這非常容易做，也是一種廣泛支持的集成方式。