安全框架 Shiro 和 Spring Security 如何選擇？

 

安全框架

安全框架，簡單說是對訪問權限進行控制，應用的安全性包括用戶認證（Authentication）和用戶受權（Authorization）兩個部分。

用戶認證指的是驗證某個用戶是否爲系統中的合法主體，也就是說用戶可否訪問該系統。

用戶認證通常要求用戶提供用戶名和密碼，系統經過校驗用戶名和密碼來完成認證過程。

用戶受權指的是驗證某個用戶是否有權限執行某個操做。在一個系統中，不一樣用戶所具備的權限是不一樣的。好比對一個文件來講，有的用戶只能進行讀取，而有的用戶能夠進行修改。

通常來講，系統會爲不一樣的用戶分配不一樣的角色，而每一個角色則對應一系列的權限。  

Shiro

Apache Shiro是一個強大且易用的Java安全框架，可以很是清晰的處理身份驗證、受權、管理會話以及密碼加密。

利用其易於理解的API，能夠快速、輕鬆地得到任何應用程序，從最小的移動應用程序到最大的網絡和企業應用程序。

Shiro 主要分爲兩個部分就是認證和受權，在我的感受來看就是查詢數據庫作相應的判斷而已，Shiro只是一個框架而已，其中的內容須要本身的去構建，先後是本身的，中間是Shiro幫咱們去搭建和配置好的。

Spring Security

Spring Security是一個可以爲基於Spring的企業應用系統提供聲明式的安全訪問控制解決方案的安全框架。

它提供了一組能夠在Spring應用上下文中配置的Bean，充分利用了Spring IoC（控制反轉），DI（ 依賴注入）和AOP（面向切面編程）功能，爲應用系統提供聲明式的安全訪問控制功能，減小了爲企業系統安全控制編寫大量重複代碼的工做。

衆所周知，想要對對Web資源進行保護，最好的辦法莫過於Filter，要想對方法調用進行保護，最好的辦法莫過於AOP。因此Spring Security在咱們進行用戶認證以及授予權限的時候，經過各類各樣的攔截器來控制權限的訪問，從而實現安全。

它全部的架構也是基於認證和受權這兩個核心功能去實現的。

Shiro主要功能

三個核心組件：Subject, SecurityManager 和 Realms。

Subject：即「當前操做用戶」。可是，在Shiro中，Subject這一律念並不只僅指人，也能夠是第三方進程、後臺賬戶（Daemon Account）或其餘相似事物。它僅僅意味着「當前跟軟件交互的東西」。

Subject表明了當前用戶的安全操做，SecurityManager則管理全部用戶的安全操做。

SecurityManager：它是Shiro框架的核心，典型的Facade模式，Shiro經過SecurityManager來管理內部組件實例，並經過它來提供安全管理的各類服務。

Realm：Realm充當了Shiro與應用安全數據間的「橋樑」或者「鏈接器」。也就是說，當對用戶執行認證（登陸）和受權（訪問控制）驗證時，Shiro會從應用配置的Realm中查找用戶及其權限信息。

從這個意義上講，Realm實質上是一個安全相關的DAO：它封裝了數據源的鏈接細節，並在須要時將相關數據提供給Shiro。當配置Shiro時，你必須至少指定一個Realm，用於認證和（或）受權。配置多個Realm是能夠的，可是至少須要一個。

Shiro內置了能夠鏈接大量安全數據源（又名目錄）的Realm，如LDAP、關係數據庫（JDBC）、相似INI的文本配置資源以及屬性文件等。若是缺省的Realm不能知足需求，你還能夠插入表明自定義數據源的本身的Realm實現。

Spring Security主要功能

Spring Security對Web安全性的支持大量地依賴於Servlet過濾器。這些過濾器攔截進入請求，而且在應用程序處理該請求以前進行某些安全處理。

Spring Security提供有若干個過濾器，它們可以攔截Servlet請求，並將這些請求轉給認證和訪問決策管理器處理，從而加強安全性。根據本身的須要，可使用適當的過濾器來保護本身的應用程序。

若是使用過Servlet過濾器且令其正常工做，就必須在Web應用程序的web.xml文件中使用<filter> 和<filter-mapping>元素配置它們。雖然這樣作能起做用，可是它並不適用於使用依賴注入進行的配置。

FilterToBeanProxy是一個特殊的Servlet過濾器，它自己作的工做並很少，而是將本身的工做委託給Spring應用程序上下文 中的一個Bean來完成。被委託的Bean幾乎和其餘的Servlet過濾器同樣，實現javax.servlet.Filter接 口，但它是在Spring配置文件而不是web.xml文件中配置的。

實際上，FilterToBeanProxy代理給的那個Bean能夠是javax.servlet.Filter的任意實現。這能夠是 Spring Security的任何一個過濾器，或者它能夠是本身建立的一個過濾器。可是正如本書已經提到的那樣，Spring Security要求至少配置四個並且可能一打或者更多的過濾器。

Shiro特色

一、易於理解的 Java Security API；

二、簡單的身份認證（登陸），支持多種數據源（LDAP，JDBC，Kerberos，ActiveDirectory 等）；

三、對角色的簡單的籤權（訪問控制），支持細粒度的籤權；

四、支持一級緩存，以提高應用程序的性能；

五、內置的基於 POJO 企業會話管理，適用於 Web 以及非 Web 的環境；

六、異構客戶端會話訪問；

七、很是簡單的加密 API；

八、不跟任何的框架或者容器捆綁，能夠獨立運行。

Spring Security特色

除了不能脫離Spring，shiro的功能它都有。

並且Spring Security對Oauth、OpenID也有支持,Shiro則須要本身手動實現。Spring Security的權限細粒度更高（還未發現高在哪裏）。

注：

OAuth在"客戶端"與"服務提供商"之間，設置了一個受權層（authorization layer）。"客戶端"不能直接登陸"服務提供商"，只能登陸受權層，以此將用戶與客戶端區分開來。"客戶端"登陸受權層所用的令牌（token），與用戶的密碼不一樣。用戶能夠在登陸的時候，指定受權層令牌的權限範圍和有效期。

"客戶端"登陸受權層之後，"服務提供商"根據令牌的權限範圍和有效期，向"客戶端"開放用戶儲存的資料。

OpenID 系統的第一部分是身份驗證，即如何經過 URI 來認證用戶身份。目前的網站都是依靠用戶名和密碼來登陸認證，這就意味着你們在每一個網站都須要註冊用戶名和密碼，即使你使用的是一樣的密碼。

若是使用 OpenID ，你的網站地址（URI）就是你的用戶名，而你的密碼安全的存儲在一個 OpenID 服務網站上（你能夠本身創建一個 OpenID 服務網站，也能夠選擇一個可信任的 OpenID 服務網站來完成註冊）。

與OpenID同屬性的身份識別服務商還有ⅥeID,ClaimID,CardSpace,Rapleaf,Trufina ID Card等，其中ⅥeID通用帳戶的應用最爲普遍。

總結

我的認爲現階段需求，權限的操做粒度能控制在路徑及按鈕上，數據粒度經過sql實現。Shrio簡單夠用。

至於OAuth，OpenID 站點間統一登陸功能，現租戶與各個產品間單點登陸已經經過cookies實現，因此Spring Security的這兩個功能能夠不考慮。

SpringSide網站的權限也是用Shrio作的。