您好,登錄后才能下訂單哦!
本應用遵循標準的三層結(jié)構(gòu),包括web層、服務層和數(shù)據(jù)訪問層,如下圖所示:
web層封裝了MVC的代碼和功能。在示例代碼中,我們使用了Spring MVC框架,但是我們可以一樣容易的使用Spring Web Flow,Struts甚至是一個對Spring友好的web stack如Apache Wicket。
在一個典型使用Spring Security的web應用中,大量配置和參數(shù)代碼位于web層。所以,如果你沒有web應用開發(fā),尤其是Spring MVC的經(jīng)驗,在我們進入更復雜的話題前,你最好仔細看一下基礎(chǔ)代碼并確保你能理解。再次強調(diào),我們已經(jīng)盡力讓我們的應用簡單,把它構(gòu)建成一個pet store只是為了給它一個合理的名字和輕量級的結(jié)構(gòu)??梢詫⑵渑c復雜的Java EE Pet Clinic示例作為對比,那個示例代碼展現(xiàn)了很多技術(shù)的使用指導。
服務層封裝了應用的業(yè)務邏輯。在示例應用中,我們在數(shù)據(jù)訪問層前做了一個很薄的faade用來描述如何在特殊的點周圍保護應用的服務方法。
在典型的web工程中,這一層將會包括業(yè)務規(guī)則校驗,組裝和分解BO以及交叉的關(guān)注點如審計等。
數(shù)據(jù)訪問層封裝了操作數(shù)據(jù)庫表的代碼。在很多基于Spring的工程中,這將會在這里發(fā)現(xiàn)使用了ORM技術(shù)如hibernate或JPA。它為服務層暴露了基于對象的API。在示例代碼中,我們使用基本的JDBC功能完成到內(nèi)存數(shù)據(jù)庫HSQL的持久化。
在典型的web工程中,將會使用更為復雜的數(shù)據(jù)訪問方式。因為ORM,即數(shù)據(jù)訪問,開發(fā)人員對其很迷惑。所以為了更清晰,這一部分我們盡可能的對其進行了簡化。
為了Spring Security的使用更高效,在開始評估和提高我們應用的安全狀況之前,先了解一些關(guān)鍵的概念和術(shù)語是很重要的。
正如我們在第一章所討論的那樣,認證是鑒別我們應用中的用戶是他們所聲明的那個人。你可能在在線或線下的日常生活中,遇到不同場景的認證:
憑據(jù)為基礎(chǔ)的認證:當你登錄e-mail賬號時,你可能提供你的用戶名和密碼。E-mail的提供商會將你的用戶名與數(shù)據(jù)中的記錄進行匹配,并驗證你提供的密碼與對應的記錄是不是匹配。這些憑證(用戶名和密碼,譯者注)就是e-mail系統(tǒng)用來鑒別你是一個合法用戶的。首先,我們將首先使用這種類型的認證來保護我們JBCP Pet在線商店的敏感區(qū)域。技術(shù)上來說,e-mail系統(tǒng)能夠檢查憑證信息不一定非要使用數(shù)據(jù)庫而是各種方式,如一個企業(yè)級的目錄服務器如Microsoft Active Directory。一些這種類型的集成方式將在本書的第二部分講解。
兩要素認證:當你想從自動柜員機取錢的時候,你在被允許取錢和做其他業(yè)務前,你必須先插卡并輸入你的密碼。這種方式的認證與用戶名和密碼的認證方式很類似,與之不同的是用戶名信息被編碼到卡的磁條上了。聯(lián)合使用物理磁卡和用戶輸入密碼能是銀行確認你可能有使用這個賬號的權(quán)限。聯(lián)合使用密碼和物理設(shè)備(你的ATM卡)是一種普遍存在的兩要素認證形式。專業(yè)來看,在安全領(lǐng)域,這種類型的設(shè)備在安全性要求高的系統(tǒng)中很常見,尤其是處理財務或個人識別信息時。硬件設(shè)備如RSA的SecurId聯(lián)合使用了基于時間的硬件和服務端的認證軟件,使得這樣的環(huán)境極難被破壞。
硬件認證:早上當你啟動汽車時,你插入鑰匙并打火。盡管和其他的兩個例子很類似,但是你的鑰匙和打火裝置的匹配是一種硬件認證的方式。
其實會有很多種的認證方式來解決硬件和軟件的安全問題,它們各自也有其優(yōu)缺點。我們將會在本書的后面章節(jié)中介紹它們中的一些,因為它們適用于Spring Security。事實上,本書的后半部分基本上都是原來介紹很多通用的認證方式用Spring Security的實現(xiàn)。
Spring Security擴展了java標準概念中的已認證安全實體(對應單詞principal)(java.security.Principal),它被用來唯一標識一個認證過的實體。盡管一個典型的安全實體通常一對一的指向了系統(tǒng)中的一個用戶,但它也可能對應系統(tǒng)的各種客戶端,如web service的客戶端、自動運行的feed聚合器(automated batch feed)等等。在大多數(shù)場景下,在你使用Spring Security的過程中,一個安全實體(Principal)只是簡單地代表一個用戶(user),所以我當我們說一個安全實體的時候,你可以將其等同于說用戶。
授權(quán)通常涉及到兩個不同的方面,他們共同描述對安全系統(tǒng)的可訪問性。
第一個是已經(jīng)認證的安全實體與一個或多個權(quán)限(authorities)的匹配關(guān)系(通常稱為角色)。例如,一
個非正式的用戶訪問你的網(wǎng)站將被視為只有訪問的權(quán)限而一個網(wǎng)站的管理員將會被分配管理的權(quán)限。
第二個是分配權(quán)限檢查給系統(tǒng)中要進行安全保護的資源。通常這將會在系統(tǒng)的開發(fā)過程中進行,有可能會
通過代碼進行明確的聲明也可能通過參數(shù)進行設(shè)置。例如,在我們應用中管理寵物商店詳細目錄的界面只能對
具有管理權(quán)限的用戶開放。
【要進行安全保護的資源可以是系統(tǒng)的任何內(nèi)容,它們會根據(jù)用戶的權(quán)限進行有選擇的可訪問控制。web
應用中的受保護資源可以是單個的頁面、網(wǎng)站的一個完整部分或者一部分界面。相反的,受保護的業(yè)務資源可
能會是業(yè)務對象的一個方法調(diào)用或者單個的業(yè)務對象?!?/span>
你可能想象的出對一個安全實體的權(quán)限檢查過程,查找它的用戶賬號并確定它是不是真的為一個管理員。如
果權(quán)限檢查確定這個試圖訪問受保護區(qū)區(qū)域的安全實體實際上是管理員,那么這個請求將會成功,否則,這個
安全實體的請求將會因為它缺少足夠的權(quán)限而被拒絕。
我們更近距離的看一個特定的受保護資源——產(chǎn)品目錄的編輯界面。目錄的編輯界面需要管理員才能訪問
(畢竟,我們不希望普通的用戶能夠調(diào)整我們的目錄層次),因此當一個安全實體訪問它的時候會要求特定等
級的權(quán)限。
當我們思考一個網(wǎng)站的管理員試圖訪問受保護的資源時,權(quán)限控制決定是如何做出的時候,我們猜想對受保
護資源的權(quán)限的檢查過程可以用集合理論很簡明的進行表述。我們將會使用維恩圖來展現(xiàn)對管理用戶的這個決
策過程:
對這個頁面來說,在用戶權(quán)限(普通用戶和管理員)和需要權(quán)限(管理員)之間有一個交集,所以在交集中的用戶將能夠進行訪問。
可以與沒有授權(quán)的訪問者進行對比:
權(quán)限集合沒有交集,沒有公共的元素。所以,用戶將會被拒絕訪問這個界面。至此,我們已經(jīng)介紹了對資源授權(quán)的簡單原理。
實際上,會有真正的代碼來決定用戶是允許還是被拒絕訪問受保護的資源。下面的圖片在整體上描述了這個過程,正如Spring Security所使用的那樣:
我們可以看到,有一個名為訪問決策管理器(access decision manager)的組件來負責決定一個安全實體是不是有適當?shù)脑L問權(quán)限,判斷基于安全實體具備的權(quán)限與被請求資源所要求資源的匹配情況。
安全訪問控制器對訪問是否被允許的判斷過程可能會很簡單,就像查看安全實體所擁有的權(quán)限集合與被訪問資源所要求的資源集合是不是有交集。
以上文章來自網(wǎng)絡(luò)關(guān)于Spring Security3翻譯。
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。