根據上面的需求描述以及對需求的分析，我們得知通常的一個(gè)中小型系統對于權限系統所需實(shí)現的功能以及非功能性的需求，在下面我們將根據需求從技術(shù)角度上分析實(shí)現的策略以及基于目前兩種比較流行的權限設計思想來(lái)討論關(guān)于權限系統的實(shí)現。
1.1. 技術(shù)策略
l 身份認證
在B/S的系統中，為識別用戶(hù)身份，通常使用的技術(shù)策略為將用戶(hù)的身份記錄在Session中，也就是當用戶(hù)登錄時(shí)即獲取用戶(hù)的身份信息，并將其記錄到Session里，當需要進(jìn)行身份認證的時(shí)候通過(guò)從Session中獲取用戶(hù)的身份信息來(lái)實(shí)現用戶(hù)的身份認證。
l 資源權限校驗
資源權限校驗取決于系統的授權模型，這塊將在之后進(jìn)行詳細的闡述。
l 數據權限校驗
數據權限校驗取決于系統的授權模型，這塊將在之后進(jìn)行詳細的闡述。
l 授權模型
授權模型作為權限系統的核心，從本質(zhì)上決定了權限系統的易用性，這個(gè)易用性包括權限的授予和權限的校驗，并同時(shí)也決定了權限的繼承，權限的排斥和包含等方面的實(shí)現。
在經(jīng)歷了這么多年的發(fā)展，授權模型在目前中小型應用系統接受的比較多的主要有RBAC模型和ACL模型，將在之后展開(kāi)專(zhuān)門(mén)的篇幅進(jìn)行講解。
l 權限校驗的體現
權限校驗的體現在中小型系統中體現出來(lái)的通常只是對于系統菜單、按鈕顯示的控制和對于擁有權限的數據的訪(fǎng)問(wèn)上。
它們共同依賴(lài)于資源權限校驗和數據權限校驗，對于系統菜單、按鈕的顯示上的控制在B/S中通常采用的技術(shù)策略為在生成菜單、按鈕的Html時(shí)做權限級的判斷，當操作主體不具備權限時(shí)則不生成該菜單、按鈕的Html，從技術(shù)角度分析為方便使用者，避免使用者調用權限校驗接口，通常的做法為提供菜單、按鈕的標簽，通過(guò)此標簽生成的菜單和按鈕即為經(jīng)過(guò)權限過(guò)濾的。
l 高性能
為提高權限系統在授權以及校驗權限時(shí)的性能，通常的做法為采用緩存技術(shù)以及加強權限系統的管理建設，加強權限系統的管理建設有助于建立一個(gè)最為適合需求的權限結構，同時(shí)做到了簡(jiǎn)化系統權限授予。
l 安全性
安全性方面來(lái)講在B/S系統中通常有兩個(gè)方面需要控制：
n 通過(guò)非法途徑訪(fǎng)問(wèn)系統文件
在Java的Web應用中通常采用的技術(shù)策略為將需要受保護的文件放入WEB-INF文件夾中，大家都知道在WEB-INF下的文件除了在服務(wù)器上能直接訪(fǎng)問(wèn)外，通過(guò)普通的URL是無(wú)法訪(fǎng)問(wèn)到的。
其次的做法為做Filter，即對需要受保護的資源做訪(fǎng)問(wèn)的Filter，如操作者不具備權限則直接報出錯誤。
n 通過(guò)非法途徑訪(fǎng)問(wèn)系統操作
通常采用的技術(shù)策略為對每個(gè)直接暴露對外的需要受權限保護的對象做操作級別的權限控制，簡(jiǎn)單來(lái)說(shuō)在Web系統中通常采用MVC框架來(lái)實(shí)現，通常Command層是直接對外的，為防止用戶(hù)通過(guò)URL或其他方式訪(fǎng)問(wèn)Command，從技術(shù)上我們需要考慮對現有系統的盡量少的侵入性，所以通常采用的做法是在Command之上做Before Interceptor或Proxy，在此Interceptor或Proxy中做權限的校驗，以確認操作者具有相應的權限。
經(jīng)過(guò)上面的描述，我們已經(jīng)基本了解到滿(mǎn)足權限系統需求的技術(shù)實(shí)現策略，從中我們也可以看出權限系統中最為重要的為授權模型，由于權限系統的通用性，在業(yè)界也是推出了不少的授權模型，在這里我們已目前比較通用的兩種授權模型來(lái)具體講解權限系統的完整實(shí)現。
1.2. 基于RBAC的實(shí)現
1.2.1. RBAC介紹
RBAC模型作為目前最為廣泛接受的權限模型，在此也將對其模型進(jìn)行簡(jiǎn)要的介紹，RBAC模型成功的經(jīng)典應用案例當屬Unix系統了。
NIST（The National Institute of Standards and Technology，美國國家標準與技術(shù)研究院）標準RBAC模型由4個(gè)部件模型組成，這4個(gè)部件模型分別是基本模型RBAC0（Core RBAC）、角色分級模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和統一模型RBAC3（Combines RBAC）[1]。RBAC0模型如圖1所示。
圖表 1 RBAC 0模型
l RBAC0定義了能構成一個(gè)RBAC控制系統的最小的元素集合
在RBAC之中,包含用戶(hù)users(USERS)、角色roles(ROLES)、目標objects(OBS)、操作operations(OPS)、許可權permissions(PRMS)五個(gè)基本數據元素，權限被賦予角色,而不是用戶(hù)，當一個(gè)角色被指定給一個(gè)用戶(hù)時(shí)，此用戶(hù)就擁有了該角色所包含的權限。會(huì )話(huà)sessions是用戶(hù)與激活的角色集合之間的映射。RBAC0與傳統訪(fǎng)問(wèn)控制的差別在于增加一層間接性帶來(lái)了靈活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的擴展。
l RBAC1引入角色間的繼承關(guān)系
角色間的繼承關(guān)系可分為一般繼承關(guān)系和受限繼承關(guān)系。一般繼承關(guān)系僅要求角色繼承關(guān)系是一個(gè)絕對偏序關(guān)系，允許角色間的多繼承。而受限繼承關(guān)系則進(jìn)一步要求角色繼承關(guān)系是一個(gè)樹(shù)結構。
l RBAC2模型中添加了責任分離關(guān)系
RBAC2的約束規定了權限被賦予角色時(shí),或角色被賦予用戶(hù)時(shí),以及當用戶(hù)在某一時(shí)刻激活一個(gè)角色時(shí)所應遵循的強制性規則。責任分離包括靜態(tài)責任分離和動(dòng)態(tài)責任分離。約束與用戶(hù)-角色-權限關(guān)系一起決定了RBAC2模型中用戶(hù)的訪(fǎng)問(wèn)許可。
l RBAC3包含了RBAC1和RBAC2
既提供了角色間的繼承關(guān)系，又提供了責任分離關(guān)系。
1.2.2. 實(shí)現方案
通過(guò)上面章節對RBAC的介紹，從RBAC模型中我們可以看出它已經(jīng)實(shí)現了一個(gè)使用起來(lái)很方便的授權模型，并同時(shí)也就權限的繼承，權限的排斥和包含提出了解決的模型。
那么現在的關(guān)鍵是我們需要來(lái)看看基于RBAC到底是怎么實(shí)現權限系統的需求的呢？在這里我們針對在技術(shù)策略中未描述的授權模型和權限校驗部分做實(shí)現方案的講解。
l 授權模型
授權模型遵循RBAC進(jìn)行搭建，即建立如上圖表一的模型。
針對授權模型中的幾個(gè)關(guān)鍵部分我們進(jìn)行描述：
n 授權
按照RBAC的模型，在授權時(shí)分為配置資源以及資源的操作、授予角色對資源的操作權限、分配角色給用戶(hù)這幾個(gè)步驟來(lái)完成。
從這幾個(gè)步驟我們進(jìn)行分析：
u 配置資源以及資源的操作
實(shí)現這步非常的簡(jiǎn)單，直接維護資源以及資源操作兩個(gè)對象的持久即可實(shí)現。
u 授予角色對資源的操作權限
實(shí)現這步同樣非常的簡(jiǎn)單，維護角色與資源的關(guān)聯(lián)模型即可。
u 分配角色給用戶(hù)
實(shí)現這步同樣非常的簡(jiǎn)單，維護角色與用戶(hù)的關(guān)聯(lián)模型即可。
n 權限的繼承
權限的繼承在RBAC的模型中通過(guò)增加角色的自關(guān)聯(lián)來(lái)實(shí)現，即角色可擁有子角色，子角色繼承父角色的權限。
按照此模型可以看出在授權時(shí)維護權限的繼承也是非常的簡(jiǎn)單，維護角色的自關(guān)聯(lián)模型即可。
n 權限的排斥和包含
權限的排斥和包含這塊我沒(méi)有具體看RBAC的規范，通常的做法是通過(guò)在資源的操作權限模型中增加自關(guān)聯(lián)模型以定義哪些資源的操作權限是排斥和包含的，在授權時(shí)可以看到同樣需要維護的只是資源權限的自關(guān)聯(lián)模型。
l 資源權限校驗
根據上面的授權模型，在做資源權限校驗的時(shí)候需要經(jīng)過(guò)以下步驟：
n 判斷用戶(hù)所在的角色是否擁有對資源進(jìn)行操作的權限
獲取用戶(hù)所擁有的角色，遍歷其角色，以各角色建立Session，并通過(guò)類(lèi)似的role.doPrivilege(Resource,Operation)的方式來(lái)判斷該角色是否具備權限，如具備則直接返回，如不具備則直到遍歷結束。
n 遞規用戶(hù)所在角色的父角色判斷是否擁有對資源進(jìn)行操作的權限
當遍歷完用戶(hù)本身的角色得到用戶(hù)不具備對資源進(jìn)行該操作的權限時(shí)，則開(kāi)始遞規其所在角色的父角色來(lái)判斷是否擁有對資源進(jìn)行操作的權限，過(guò)程同上，如確定某角色具備，則返回，如不具備直到遞規結束。
l 數據權限校驗
在RBAC模型中沒(méi)有明確定義數據權限的實(shí)現策略，鑒于此首先要講解下基于RBAC模型的數據授權模型的建立，基于RBAC模型，將數據映射為RBAC中的資源，對數據的操作則映射為資源的操作，同樣的是將此資源以及資源的操作構成的權限授予給角色，將用戶(hù)分配給角色完成數據權限的授權過(guò)程。
但根據數據權限校驗的需求，數據的權限也是需要繼承的，而且數據權限的授予對象需要是多種，這樣的話(huà)就對上面根據RBAC映射形成的數據權限的授權模型造成了沖擊，需要重構上面的授權模型來(lái)滿(mǎn)足需求。
為實(shí)現數據權限的繼承，需要將RBAC模型中的資源重構為允許自關(guān)聯(lián)的模型，為實(shí)現數據權限能夠授予給多種對象，需要將本來(lái)資源操作權限授予給角色的模型演變?yōu)閿祿僮鳈嘞奘谟杞o角色、組織機構或具體人員，根據RBAC模型，同樣的建立一個(gè)中間對象，此對象和數據操作權限所授予的對象做1對多的關(guān)聯(lián)，在經(jīng)過(guò)這樣的重構之后數據權限的授權模型就形成了，也滿(mǎn)足了數據權限的繼承和授予給多種對象的需求。
圖表 2 基于RBAC演變的數據權限模型
上面的圖中少畫(huà)了數據的自關(guān)聯(lián)。
根據上面的數據權限模型，來(lái)看看數據權限的校驗是怎么樣去實(shí)現呢？
在做數據權限校驗的時(shí)候我們需要實(shí)現的為兩種方式，一種是獲取操作主體具有數據操作權限的全部數據，另外一種為分頁(yè)獲取操作主體具有數據操作權限的數據。
就這兩種方式分別來(lái)進(jìn)行闡述：
n 獲取操作主體具有數據操作權限的全部數據
從數據庫中獲取所有數據，遍歷取出的數據從數據權限模型中獲取相應的擁有數據操作權限的權限擁有者，如果該數據未配置數據操作權限的控制，那么就無(wú)需對該數據進(jìn)行權限級的判斷，如配置了，則需判斷當前用戶(hù)是否在該數據操作權限所對應的擁有者中，如用戶(hù)不在，則需遞規獲取該數據的父數據的操作權限的擁有者，到用戶(hù)擁有權限或遞規結束時(shí)終止。
n 分頁(yè)獲取操作主體具有數據操作權限的數據
分頁(yè)的做法和上面差不多，只是在獲取了所有的數據后在內存中做分頁(yè)返回。
1.2.3. 優(yōu)缺點(diǎn)分析
從上面的基于RBAC的實(shí)現方案中可以看出基于RBAC模型的優(yōu)點(diǎn)在于：
l 易用和高效的授權方式
用戶(hù)在進(jìn)行授權時(shí)只需對角色進(jìn)行授權，之后將相應的角色分配給用戶(hù)即可。
l 簡(jiǎn)便和高效的授權模型維護
在技術(shù)角度來(lái)講，進(jìn)行授權模型的維護上因為基本只需要維護關(guān)聯(lián)模型而顯得簡(jiǎn)單而高效。
缺點(diǎn)在于：
l 復雜的權限校驗
在進(jìn)行權限校驗時(shí)需要不斷的遍歷和遞規，造成了性能的影響。
l 對于數據權限的不夠支持
沒(méi)有明確的數據權限模型，可以看到在經(jīng)過(guò)重構的數據權限模型其實(shí)已經(jīng)和RBAC模型有一定的聯(lián)系客服
