第二章. 技術(shù)概覽
2.1. 運(yùn)行時(shí)環(huán)境
Acegi Security可以在JRE1.3中運(yùn)行。這個(gè)發(fā)行版本中支持也Java 5.0,盡管對(duì)應(yīng)的Java類型被分開打包到一個(gè)后綴是“tiger”的包中。因?yàn)?/span>Acegi Security致力于以一種自包含的方式運(yùn)行,因此不需要在JRE中放置任何特殊的配置文件。特別無需配置Java Authentication and Authorization Service (JAAS)策略文件或者將Acegi Security放置到通用的classpath路徑中。
同樣的,如果你使用EJB容器或者Servlet容器,同樣無需放置任何特別的配置文件或者將Acegi Security包含在服務(wù)器的類加載器(classloader)中。
上述的設(shè)計(jì)提供了最大的部署靈活性,你可以直接把目標(biāo)工件(JAR, WAR 或者 EAR))直接從一個(gè)系統(tǒng)copy到另一個(gè)系統(tǒng),它馬上就可以運(yùn)行起來。
2.2. 共享組件
讓我們來看看Acegi Security中最重要的一些共享組件。所謂共享組件是指在框架中處于核心地位,系統(tǒng)脫離了它們之后就不能運(yùn)行。這些Java類型代表了系統(tǒng)中其他部分的構(gòu)建單元,因此理解它們是非常重要的,即使你不需要直接和它們打交道。
最基礎(chǔ)的對(duì)象是SecurityContextHolder。在這里存儲(chǔ)了當(dāng)前應(yīng)用的安全上下文(security context),包括正在使用應(yīng)用程序的principal的詳細(xì)信息。SecurityContextHolder默認(rèn)使用ThreadLocal來存儲(chǔ)這些詳細(xì)信息,這意味著即便安全上下文(security context)沒有被作為一個(gè)參數(shù)顯式傳入,它仍然是可用的。如果在當(dāng)前principal的請(qǐng)求處理后清理線程,那么用這種方式使用ThreadLocal是非常安全的。當(dāng)然, Acegi Security自動(dòng)為你處理這些,所以你無需擔(dān)心。
有些應(yīng)用程序由于使用線程的方式而并不是完全適用ThreadLocal。例如,Swing客戶端可能需要一個(gè)Java Virtual Machine中的所有線程都使用同樣的安全上下文(security context)。在這種情況下你要使用SecurityContextHolder.MODE_GLOBAL模式。另外一些應(yīng)用程序可能需要安全線程產(chǎn)生的線程擁有同樣的安全標(biāo)識(shí)符(security identity)。這可以通過SecurityContextHolder.MODE_INHERITABLETHREADLOCAL來實(shí)現(xiàn)。你可以通過兩種方法來修改默認(rèn)的SecurityContextHolder.MODE_THREADLOCAL。第一種是設(shè)置一個(gè)系統(tǒng)屬性。或者,調(diào)用SecurityContextHolder的一個(gè)靜態(tài)方法。大部分的應(yīng)用程序不需要修改默認(rèn)值,不過如果你需要,那么請(qǐng)查看SecurityContextHolder的JavaDocs獲取更多信息。
我們?cè)?/span>SecurityContextHolder中存儲(chǔ)當(dāng)前和應(yīng)用程序交互的principal的詳細(xì)信息。Acegi Security使用一個(gè)Authentication對(duì)象來代表這個(gè)信息。盡管你通常不需要自行創(chuàng)建一個(gè)Authentication對(duì)象,用戶還是經(jīng)常會(huì)查詢Authentication對(duì)象。
你可以在你的應(yīng)用程序中的任何地方使用下述的代碼塊:
- Object obj = SecurityContextHolder.getContext().getAuthentication().getPrincipal();
- if (obj instanceof UserDetails) {
- String username = ((UserDetails)obj).getUsername();
- } else {
- String username = obj.toString();
- }
上述的代碼展示了一些有趣的聯(lián)系和關(guān)鍵的對(duì)象。首先,你會(huì)注意到在SecurityContextHolder和Authentication之間有一個(gè)媒介對(duì)象。SecurityContextHolder.getContext() 方法實(shí)際上返回一個(gè)SecurityContext。Acegi Security使用若干個(gè)不同的SecurityContext實(shí)現(xiàn),以備我們需要存儲(chǔ)一些和principal無關(guān)的特殊信息。一個(gè)很好的例子就是我們的Jcaptcha集成,它需要知道一個(gè)需求是否是由人發(fā)起的。這樣的判斷和principal是否通過認(rèn)證完全沒有關(guān)系,因此我們將它保存在SecurityContext中。
從上述的代碼片段可以看出的另一個(gè)問題是你可以從一個(gè)Authentication對(duì)象中獲取一個(gè)principal。Principal只是一個(gè)對(duì)象。通常可以把它cast為一個(gè)UserDetails對(duì)象。UserDetails在Acegi Security中是一個(gè)核心接口,它以一種擴(kuò)展以及應(yīng)用相關(guān)的方式來展現(xiàn)一個(gè)principal。可以把UserDetails看作是你的用戶數(shù)據(jù)庫和Acegi Security在SecurityContextHolder所需要的東西之間的一個(gè)適配器(adapter)。作為你自己用戶數(shù)據(jù)庫的一個(gè)展現(xiàn),你可能經(jīng)常要把它cast到你應(yīng)用程序提供的原始對(duì)象,這樣你就可以調(diào)用業(yè)務(wù)相關(guān)的方法(例如 getEmail(), getEmployeeNumber())。
現(xiàn)在你可能已經(jīng)開始疑惑,那我什么時(shí)候提供UserDetails對(duì)象呢?我要如何提供呢?
我想你告訴過我這個(gè)東西是聲明式的,我不需要寫任何Java代碼-那怎么做到呢?對(duì)此的簡短回答就是有一個(gè)叫做UserDetailsService的特殊接口。這個(gè)接口只有一個(gè)方法,接受一個(gè)Sring類型的參數(shù)并返回一個(gè)UserDetails。Acegi Security提供的大多數(shù)認(rèn)證提供器將部分認(rèn)證過程委派給UserDetailsService。UserDetailsService用來構(gòu)建保存在SecurityContextHolder中的Authentication對(duì)象。好消息是我們提供若干個(gè)UserDetailsService的實(shí)現(xiàn),包括一個(gè)使用in-memory map和另一個(gè)使用JDBC的。
大多數(shù)用戶還是傾向于寫自己的實(shí)現(xiàn),這樣的實(shí)現(xiàn)經(jīng)常就是簡單的構(gòu)建于已有的Data Access Object (DAO)上,這些DAO展現(xiàn)了他們的雇員、客戶、或者其他企業(yè)應(yīng)用程序中的用戶。要記得這樣做的好處,不論你的UserDetailsService返回什么,它總是可以從SecurityContextHolder中獲取,象上面的代碼顯示的那樣。
除了principal,Authentication提供的另一個(gè)重要方法就是getAuthorities()。這個(gè)方法返回一個(gè)GrantedAuthority對(duì)象數(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)限,并且期待他們被提供。通常你會(huì)從UserDetailsService中返回GrantedAuthority對(duì)象。
通常GrantedAuthority對(duì)象都是應(yīng)用范圍的權(quán)限。它們都不對(duì)應(yīng)特定的領(lǐng)域?qū)ο蟆R虼耍銘?yīng)該不會(huì)有一個(gè)代表54號(hào)員工對(duì)象的GrantedAuthority,因?yàn)檫@樣會(huì)有數(shù)以千計(jì)的authority,你馬上就會(huì)用光所有內(nèi)存(或者,至少會(huì)讓系統(tǒng)花太長時(shí)間來認(rèn)證一個(gè)用戶)。當(dāng)然,Acegi Security會(huì)高效的處理這種普遍的需求,但是你不會(huì)使用領(lǐng)域?qū)ο蟀踩δ軄韺?shí)現(xiàn)這個(gè)目的。
最后,但不是不重要,你有時(shí)候需要在HTTP 請(qǐng)求之間存儲(chǔ)SecurityContext。另外有些時(shí)候你在每次請(qǐng)求的時(shí)候都會(huì)重新認(rèn)證principal,不過大部分時(shí)候你會(huì)存儲(chǔ)SecurityContext。HttpSessionContextIntegrationFilter在HTTP之間存儲(chǔ)SecurityContext。正如類名字顯示的那樣,它使用HttpSession來進(jìn)行存儲(chǔ)。基于安全原因,你永遠(yuǎn)都不要直接和HttpSession交互。沒有理由這么做,所以記得使用SecurityContextHolder來代替。
讓我們回憶一下,Acegi Security的基本組成構(gòu)件是:
• SecurityContextHolder,提供對(duì)SecurityContext的所有訪問方式。
• 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中獲取必要的信息來構(gòu)建一個(gè)Authentication 對(duì)象。
• UserDetailsService,用傳入的String類型的username(或者認(rèn)證ID,或類似)來創(chuàng)建一個(gè)UserDetails。
現(xiàn)在你已經(jīng)理解了這些重復(fù)使用的組件,讓我們仔細(xì)看看認(rèn)證過程吧。
2.3. 認(rèn)證
正如我們?cè)谑謨?cè)開始部分所說的那樣,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ù)雜和最通用的情形。
想象一個(gè)典型的web應(yīng)用的認(rèn)證過程:
1.你訪問首頁,點(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),表明你必須通過認(rèn)證。這個(gè)回應(yīng)可能是一個(gè)HTTP回應(yīng)代碼,或者重定向到一個(gè)特定的網(wǎng)頁。
4.基于不同的認(rèn)證機(jī)制,你的瀏覽器會(huì)重定向到一個(gè)網(wǎng)頁好讓你填寫表單,或者瀏覽器會(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.接下來服務(wù)器會(huì)判斷提供的認(rèn)證信息是否有效。如果它們有效,你進(jìn)入到下一步。如果它們無效,那么通常請(qǐng)求你的瀏覽器重試一次(你會(huì)回到上兩步)。
7.你引發(fā)認(rèn)證的那個(gè)請(qǐng)求會(huì)被重試。但愿你認(rèn)證后有足夠的權(quán)限訪問那些被保護(hù)的資源。如果你有足夠的訪問權(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用來檢測(cè)任何拋出的安全異常的過濾器(filter)。這種異常通常是由AbstractSecurityInterceptor拋出的,它是授權(quán)服務(wù)的主要提供者。我們將會(huì)在下一部分討論AbstractSecurityInterceptor,現(xiàn)在我們只需要知道它產(chǎn)生Java異常,并且對(duì)于HTTP或者如何認(rèn)證一個(gè)principal一無所知。反而是ExceptionTranslationFilter提供這樣的服務(wù),它負(fù)責(zé)要么返回403錯(cuò)誤代碼(如果principal通過了認(rèn)證,只是缺少足夠的權(quán)限,象上述第7步那樣),要么加載一個(gè)AuthenticationEntryPoint (如果principal還沒有被認(rèn)證,那么我們要從第3步開始)。
AuthenticationEntryPoint負(fù)責(zé)上述的第3步。如你所想,每個(gè)web應(yīng)用都有一個(gè)默認(rèn)的認(rèn)證策略(象Acegi Security中幾乎所有的東西一樣,它也是可配置的,不過我們現(xiàn)在還是還是從簡單開始)。每個(gè)主流的認(rèn)證系統(tǒng)都有它自己的AuthenticationEntryPoint實(shí)現(xiàn),負(fù)責(zé)執(zhí)行第3步中描述的動(dòng)作。
當(dāng)瀏覽器確定要發(fā)送你的認(rèn)證信息(HTTP 表單或者HTTP header),服務(wù)器上需要有什么東西來“收集”這些認(rèn)證信息。現(xiàn)在我們?cè)谏鲜龅牡?/span>6步。在Acegi Security中對(duì)從用戶代理(通常是瀏覽器)收集認(rèn)證信息有一個(gè)特定的名字,這個(gè)名字是“認(rèn)證機(jī)制(authentication mechanism)”。當(dāng)認(rèn)證信息從客戶代理收集過來以后,一個(gè)“認(rèn)證請(qǐng)求(Authentication request)”對(duì)象被創(chuàng)建,并發(fā)送到AuthenticationProvider。
Acegi Security中認(rèn)證的最后一環(huán)是一個(gè)AuthenticationProvider。非常簡單,它的職責(zé)是取用一個(gè)認(rèn)證請(qǐng)求(Authentication request)對(duì)象,并且判斷它是否有效。這個(gè)provider要么拋出一個(gè)異常,要么返回一個(gè)組裝完畢的Authentication對(duì)象。還記得我們的好朋友UserDetails 和 UserDetailsService吧?如果沒有,回到前一部分重新回憶一下。大部分的AuthenticationProviders都會(huì)要求UserDetailsService提供一個(gè)UserDetails對(duì)象。如前所述,大部分的應(yīng)用程序會(huì)提供自己的UserDetailsService,盡管有些會(huì)使用Acegi Security提供的JDBC或者 in-memory實(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)自己的過濾器(filter)或者MVC控制器(controller)來提供和不是基于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ì)它無能為力。在這種情況之下也是非常容易讓Acegi Security運(yùn)作起來,提供認(rèn)證能力。你所需要做的是寫一個(gè)過濾器(或等價(jià)物)從某處讀取第三方用戶信息,構(gòu)建一個(gè)Acegi Security式的Authentication對(duì)象,把它放到SecurityContextHolder中。這非常容易做,也是一種廣泛支持的集成方式。
安徽新華電腦學(xué)校專業(yè)職業(yè)規(guī)劃師為你提供更多幫助【在線咨詢】