【文章內容簡介】 rity會高效的處理這種普遍的需求，但是你不會使用領域對象安全功能 來實現(xiàn)這個目的。 最后，但不是不重要，你有時候需要在 HTTP 請求之間存儲 SecurityContext。另外有些時候你在每次請求的時候都會重新認證 principal，不過大部分時候你會存儲 SecurityContext。 HttpSessionContextIntegrationFilter在 HTTP之間存儲 SecurityContext。正如類名字顯示的那樣，它使用 HttpSession來進行存儲?；诎踩?，你永遠都不要直接和 HttpSession交互。沒有理由這么做，所以記得使用 SecurityContextHolder來代替。 讓我們回憶一下， Acegi Security的基本組成構件是： ? SecurityContextHolder,提供對 SecurityContext 的所有訪問方式。 ? SecurityContext, 存儲 Authentication以及可能的請求相關的安全信息。 ? HttpSessionContextIntegrationFilter, 在 web請求之間把SecurityContext 存儲在 HttpSession中。 ? Authentication, 以 Acegi Security的方式表現(xiàn) principal。 ? GrantedAuthority, 表示賦予一個 principal 的應用范圍的權限。 ? UserDetails, 為從你的應用程序 DAO中獲取必要的信息來構建一個Authentication 對象。 ? UserDetailsService,用傳入的 String類型的 username（或者認證 ID，或類似）來創(chuàng)建一個 UserDetails。 現(xiàn)在你已經理解了這些重復使用的組件，讓我們仔細看看認證過程吧。 . 認證 正如我們在手冊開始部 分所說的那樣， Acegi Security適用于很多認證環(huán)境。雖然我們建議大家使用 Acegi Security自身的認證功能而不是和容器管理認證（ Container Managed Authentication）集成，但是我們仍然支持這種和你私有的認證系統(tǒng)集成的認證。讓我們先從 Acegi Security完全自行管理管理web安全的角度來探究一下認證，這也是最復雜和最通用的情形。 想象一個典型的 web應用的認證過程： 1．你訪問首頁，點擊一個鏈接。 2．一個請求被發(fā)送到服務器，服務器判斷你是否請求一 個被保護的資源。 3．因為你當前未被認證，服務器發(fā)回一個回應，表明你必須通過認證。這個回應可能是一個 HTTP回應代碼，或者重定向到一個特定的網頁。 4．基于不同的認證機制，你的瀏覽器會重定向到一個網頁好讓你填寫表單，或者瀏覽器會用某種方式獲取你的身份認證（例如一個 BASIC認證對話框，一個cookie，一個 X509證書等等。）。 5．瀏覽器會發(fā)回給服務器一個回應?？赡苁且粋€包含了你填寫的表單內容的HTTP POST，或者一個包含你認證詳細信息的 HTTP header。 6．接下來服務器會判斷提供的認證信息是 否有效。如果它們有效，你進入到下一步。如果它們無效，那么通常請求你的瀏覽器重試一次（你會回到上兩步）。 7．你引發(fā)認證的那個請求會被重試。但愿你認證后有足夠的權限訪問那些被保護的資源。如果你有足夠的訪問權限，請求就會成功。否則，你將會受到一個意味 “禁止 ”的 HTTP403錯誤代碼。 在 Acegi Security中，對應上述的步驟，有對應的類。主要的參與者（按照被使用的順序）是： ExceptionTranslationFilter， AuthenticationEntryPoint， 認證機制 (authentication mechanism)， 以及 AuthenticationProvider。 ExceptionTranslationFilter是 Acegi Security用來檢測任何拋出的安全異常的過濾器 (filter)。這種異常通常是由 AbstractSecurityInterceptor拋出的，它是授權服務的主要提供者。我們將會在下一部分討論AbstractSecurityInterceptor，現(xiàn)在我們只需要知道它產生 Java異常，并且對于 HTTP或者如何認證一個 principal 一無所知 。反而是ExceptionTranslationFilter提供這樣的服務，它負責要么返回 403錯誤代碼(如果 principal 通過了認證，只是缺少足夠的權限，象上述第 7步那樣 )，要么加載一個 AuthenticationEntryPoint (如果 principal 還沒有被認證，那么我們要從第 3步開始 )。 AuthenticationEntryPoint負責上述的第 3步。如你所想，每個 web應用都有一個默認的認證策略（象 Acegi Security中幾乎所有的東西一樣，它也是可配置的，不過我們現(xiàn)在還是還 是從簡單開始）。每個主流的認證系統(tǒng)都有它自己的AuthenticationEntryPoint實現(xiàn)，負責執(zhí)行第 3步中描述的動作。 當瀏覽器確定要發(fā)送你的認證信息（ HTTP 表單或者 HTTP header），服務器上需要有什么東西來 “收集 ”這些認證信息?，F(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或者 inmemory實現(xiàn)。作為成品的 UserDetails 對象，特別是其中的GrantedAuthority[]s，在構建完備的 Authentication對象時會被使用。 當認證機制（ authentication mechanism）取回組裝完全的 Authentication對象后，它將會相信請求是有效的，將 Authentication放到SecurityContextHolder中，并且將原始請求取回（上述第 7步）。反之，AuthenticationProvider則拒絕請求，認證機制（ authentication mechanism）會請求用戶重試（上述第 2步）。 在講述典型的認證流程的同時，有個好消息是 Acegi Security不關心你是如何把Authentication放到 SecurityContextHolder內的。唯一關鍵的是在AbstractSecurityInterceptor授權一個請求之前，在SecurityContextHolder中包含一個代表了 principal 的 Authentication。 你可以（很多用戶確實）實現(xiàn)自己的過濾器（ filter）或者 MVC控制器（ controller）來提供和不是基于 Acegi Security的認證系統(tǒng)交互。例如，你可能使用使用容器管理認證（ Container Managed Authentication），從 ThreadLocal 或者 JNDI中獲 取當前用戶信息，使得它有效?；蛘?，你工作的公司有一個遺留的私有認證系統(tǒng)，而它是公司 “標準 ”，你對它無能為力。在這種情況之下也是非常容易讓 Acegi Security運作起來，提供認證能力。你所需要做的是寫一個過濾器（或等價物）從某處讀取第三方用戶信息，構建一個 Acegi Security式的Authentication對象，把它放到 SecurityContextHolder中。這非常容易做，也是一種廣泛支持的集成方式。 acegi參考手冊 ()[譯 ]第二章 技術概覽 [下 ] . 安全對象 如 果你熟悉 AOP，你會知道有很多種 advice可用： before, after, throws 和 around。 around advice 非常有用，因為它能夠選擇是否選擇是否執(zhí)行一個方法調用，是否修改返回值，以及是否拋出異常。 Acegi Security對方法調用和web請求都提供 around advice。我們使用 AOP聯(lián)盟實現(xiàn)對方法調用的around advice，對于 web請求的 around advice 則是使用標準的過濾器（ Filter）。 對于那些不熟悉 AOP的人來說，關鍵是要理解 Acegi Security能夠幫助你保護方法調用以及 web請求。大多數(shù)人對保護他們服務層的方法調用感興趣。這是因為在當前的 J2EE應用中，服務層包含了大多數(shù)的業(yè)務邏輯（聲明，作者不贊成這種設計，反而支持正確封裝的領域模型以及 DTO， assembly, facade 以及 transparent persistence patterns，而不是當前主流的貧血模型，我們將在這里討論）。如果你需要保護 service層的方法調用，使用標準的 Spring AOP平臺（或者被成為 AOP 聯(lián)盟（ AOP Alliance））就足夠了 。如果你需要直接對領域模型進行保護，那么可以考慮使用 AspectJ。 你可以選擇對使用 AspectJ 或者 AOP聯(lián)盟（ AOP Alliance）對方法進行授權，或者你可以選擇使用過濾器（ filter）來對 web請求進行授權。你將 0個， 1個，2個或者 3個這些方法一起使用。主流的用法是執(zhí)行一些 web請求授權，以及在服務層使用 AOP聯(lián)盟（ AOP Alliance）對一些方法調用授權。 Acegi Security使用 “安全對象 ”（ secure object）這個詞來指任何能夠將安全應用于其上的對象。每個 Acegi Security支持的安全對象都有自己的類，它是AbstractSecurityInterceptor的子類。重要的一點是，如果一個 principal通過認證，當 AbstractSecurityInterceptor執(zhí)行的時候，SecurityContextHolder中要包含一個有效的 Authentication。 AbstractSecurityInterceptor提供一個固定的工作流程來處理安全對象請求。這個工作流程包括查找和當前請求相關聯(lián)的 “配置屬性（ configuration attributes） ”。配置屬性（ configuration attributes）可以被認為是對被AbstractSecurityInterceptor使用的類有特殊含義的字符串。他們通常針對AbstractSecurityInterceptor使用 XML進行配置。反正，AbstractSecurityInterceptor會詢問 AccessDecisionManager “這是配置屬性（ configuration attributes），這是當前的認證對象（ Authentication object），這 是當前請求的詳細信息－那么這個特定的 principal 可以執(zhí)行這個特定的操作嗎？ ”。 假如 AccessDecisionManager判定允許這個請求，那么AbstractSecurityInterceptor一般來說就繼續(xù)執(zhí)行請求。雖然這樣，用戶在少數(shù)情況之下可能需要替換 SecurityContext 中的 Authentication，可以通過AccessDecisionManager調用一個 RunAsManager來實現(xiàn)。在某些不常見的情形下這將非常有用，例如服務層的方法需要用另一種標識（身份）來調用遠程系統(tǒng)。這可能有所幫助，因為 Acegi Security自動在不同的服務器之間傳播安全標識（假設你正確配置了 RMI或者 HttpInvoker remoting protocol client）。 隨著安全對象處理和返回－意味著方法調用完畢或者過濾器鏈（ filter chain）處理完畢－ AbstractSecurityInterceptor有最后的機會來處理調用。這時，AbstractSecurityInterceptor可能會修改返回的對象。我們可能要這樣做，因為授權判斷不能在安全對象調用途中執(zhí)行。由 于高度的可