跟我學習Spring Security--在線寵物商店開發（一）

    本應用遵循標準的三層結構，包括web層、服務層和數據訪問層，如下圖所示：

web層封裝了MVC的代碼和功能。在示例代碼中，我們使用了Spring MVC框架，但是我們可以一樣容易的使用Spring Web Flow，Struts甚至是一個對Spring友好的web stack如Apache Wicket。

在一個典型使用Spring Security的web應用中，大量配置和參數代碼位于web層。所以，如果你沒有web應用開發，尤其是Spring MVC的經驗，在我們進入更復雜的話題前，你最好仔細看一下基礎代碼并確保你能理解。再次強調，我們已經盡力讓我們的應用簡單，把它構建成一個pet store只是為了給它一個合理的名字和輕量級的結構。可以將其與復雜的Java EE Pet Clinic示例作為對比，那個示例代碼展現了很多技術的使用指導。

服務層封裝了應用的業務邏輯。在示例應用中，我們在數據訪問層前做了一個很薄的faade用來描述如何在特殊的點周圍保護應用的服務方法。

在典型的web工程中，這一層將會包括業務規則校驗，組裝和分解BO以及交叉的關注點如審計等。

數據訪問層封裝了操作數據庫表的代碼。在很多基于Spring的工程中，這將會在這里發現使用了ORM技術如hibernate或JPA。它為服務層暴露了基于對象的API。在示例代碼中，我們使用基本的JDBC功能完成到內存數據庫HSQL的持久化。

在典型的web工程中，將會使用更為復雜的數據訪問方式。因為ORM，即數據訪問，開發人員對其很迷惑。所以為了更清晰，這一部分我們盡可能的對其進行了簡化。

  為了Spring Security的使用更高效，在開始評估和提高我們應用的安全狀況之前，先了解一些關鍵的概念和術語是很重要的。

認證

         正如我們在第一章所討論的那樣，認證是鑒別我們應用中的用戶是他們所聲明的那個人。你可能在在線或線下的日常生活中，遇到不同場景的認證：

• 憑據為基礎的認證：當你登錄e-mail賬號時，你可能提供你的用戶名和密碼。E-mail的提供商會將你的用戶名與數據中的記錄進行匹配，并驗證你提供的密碼與對應的記錄是不是匹配。這些憑證（用戶名和密碼，譯者注）就是e-mail系統用來鑒別你是一個合法用戶的。首先，我們將首先使用這種類型的認證來保護我們JBCP Pet在線商店的敏感區域。技術上來說，e-mail系統能夠檢查憑證信息不一定非要使用數據庫而是各種方式，如一個企業級的目錄服務器如Microsoft Active Directory。一些這種類型的集成方式將在本書的第二部分講解。

• 兩要素認證：當你想從自動柜員機取錢的時候，你在被允許取錢和做其他業務前，你必須先插卡并輸入你的密碼。這種方式的認證與用戶名和密碼的認證方式很類似，與之不同的是用戶名信息被編碼到卡的磁條上了。聯合使用物理磁卡和用戶輸入密碼能是銀行確認你可能有使用這個賬號的權限。聯合使用密碼和物理設備（你的ATM卡）是一種普遍存在的兩要素認證形式。專業來看，在安全領域，這種類型的設備在安全性要求高的系統中很常見，尤其是處理財務或個人識別信息時。硬件設備如RSA的SecurId聯合使用了基于時間的硬件和服務端的認證軟件，使得這樣的環境極難被破壞。

• 硬件認證：早上當你啟動汽車時，你插入鑰匙并打火。盡管和其他的兩個例子很類似，但是你的鑰匙和打火裝置的匹配是一種硬件認證的方式。

其實會有很多種的認證方式來解決硬件和軟件的安全問題，它們各自也有其優缺點。我們將會在本書的后面章節中介紹它們中的一些，因為它們適用于Spring Security。事實上，本書的后半部分基本上都是原來介紹很多通用的認證方式用Spring Security的實現。

Spring Security擴展了java標準概念中的已認證安全實體（對應單詞principal）（java.security.Principal），它被用來唯一標識一個認證過的實體。盡管一個典型的安全實體通常一對一的指向了系統中的一個用戶，但它也可能對應系統的各種客戶端，如web service的客戶端、自動運行的feed聚合器（automated batch feed）等等。在大多數場景下，在你使用Spring Security的過程中，一個安全實體（Principal）只是簡單地代表一個用戶（user），所以我當我們說一個安全實體的時候，你可以將其等同于說用戶。

授權

         授權通常涉及到兩個不同的方面，他們共同描述對安全系統的可訪問性。

         第一個是已經認證的安全實體與一個或多個權限（authorities）的匹配關系（通常稱為角色）。例如，一

個非正式的用戶訪問你的網站將被視為只有訪問的權限而一個網站的管理員將會被分配管理的權限。

        第二個是分配權限檢查給系統中要進行安全保護的資源。通常這將會在系統的開發過程中進行，有可能會

通過代碼進行明確的聲明也可能通過參數進行設置。例如，在我們應用中管理寵物商店詳細目錄的界面只能對

具有管理權限的用戶開放。

       【要進行安全保護的資源可以是系統的任何內容，它們會根據用戶的權限進行有選擇的可訪問控制。web

應用中的受保護資源可以是單個的頁面、網站的一個完整部分或者一部分界面。相反的，受保護的業務資源可

能會是業務對象的一個方法調用或者單個的業務對象。】

        你可能想象的出對一個安全實體的權限檢查過程，查找它的用戶賬號并確定它是不是真的為一個管理員。如

果權限檢查確定這個試圖訪問受保護區區域的安全實體實際上是管理員，那么這個請求將會成功，否則，這個

安全實體的請求將會因為它缺少足夠的權限而被拒絕。

       我們更近距離的看一個特定的受保護資源——產品目錄的編輯界面。目錄的編輯界面需要管理員才能訪問

（畢竟，我們不希望普通的用戶能夠調整我們的目錄層次），因此當一個安全實體訪問它的時候會要求特定等

級的權限。

        當我們思考一個網站的管理員試圖訪問受保護的資源時，權限控制決定是如何做出的時候，我們猜想對受保

護資源的權限的檢查過程可以用集合理論很簡明的進行表述。我們將會使用維恩圖來展現對管理用戶的這個決

策過程：

對這個頁面來說，在用戶權限（普通用戶和管理員）和需要權限（管理員）之間有一個交集，所以在交集中的用戶將能夠進行訪問。

可以與沒有授權的訪問者進行對比：

權限集合沒有交集，沒有公共的元素。所以，用戶將會被拒絕訪問這個界面。至此，我們已經介紹了對資源授權的簡單原理。

       實際上，會有真正的代碼來決定用戶是允許還是被拒絕訪問受保護的資源。下面的圖片在整體上描述了這個過程，正如Spring Security所使用的那樣：

              我們可以看到，有一個名為訪問決策管理器（access decision manager）的組件來負責決定一個安全實體是不是有適當的訪問權限，判斷基于安全實體具備的權限與被請求資源所要求資源的匹配情況。

安全訪問控制器對訪問是否被允許的判斷過程可能會很簡單，就像查看安全實體所擁有的權限集合與被訪問資源所要求的資源集合是不是有交集。

以上文章來自網絡關于Spring Security3翻譯。