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