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