《Spring Security3》第二章第一部分翻譯

本文爲轉載學習

原文連接：http://lengyun3566.iteye.com/blog/1078173

第二章  Spring Security起步

    在本章中，咱們將要學習Spring Security背後的核心理念，包括重要的術語和產品架構。咱們將會關注配置Spring Security的一些方式以及對應用的做用。

    最重要的是爲了解決工做中的問題，咱們要開始使得JBCP Pets的在線商店系統變得安全。咱們將會經過分析和理解認證如何保護在線商店的適當區域來解決在第一章：一個不安全應用的剖析中審計人員發現的第一個問題，即缺乏URL保護和統一的認證形成的權限擴散。

在本章的內容中，咱們將會涉及：

瞭解應用中安全的重要概念；

使用Spring Security的快速配置功能，爲JBCP Pets在線商店實現基本層次的安全；

理解Spring Security的全貌；

探討認證和受權的標準配置和選項；

在Spring Security訪問控制中使用Spring的表達式語言（Spring Expression Language）

安全的核心概念

         因爲安全審計結果的啓示做用，你研究了Spring Security並肯定它可以提供一個堅實的基礎，以此能夠構建一個安全的系統來解決在安全審計JBCP Pet在線商店中發現的問題，而那個系統是基於Spring Web MVC開發的。

         爲了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）的組件來負責決定一個安全實體是否是有適當的訪問權限，判斷基於安全實體具有的權限與被請求資源所要求資源的匹配狀況。

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

讓咱們在JBCP Pets應用中簡單使用Spring Security，並將會更詳細的闡述認證和受權。