這篇文章的定位,，不是宣傳某個(gè)框架,，僅僅之是梳理一下有關(guān)權(quán)限方面的一些想法和最近項(xiàng)目中的一些探索過程。 我們主要想解決一下問題,。

1. 什么是權(quán)限,，程序員理解的權(quán)限和客戶所理解的權(quán)限是不是一致的。

2. 權(quán)限的劃分原則,，權(quán)限到底是根據(jù)什么原則進(jìn)行組合的,。

3. 角色是用戶與權(quán)限之間的必要的關(guān)系嗎？角色到底承接了什么作用,。

4. 如何進(jìn)行合理的表設(shè)計(jì),。

5. 安全框架。

1.什么是權(quán)限

在很多與開發(fā)者也好,，與客戶也好,，溝通的過程中我們很多次提到了權(quán)限，但是權(quán)限具體的含義每個(gè)人理解的含義都不明確，這樣很容易造成雙方信息不對(duì)稱,，有的人就只是把權(quán)限理解成某個(gè)頁(yè)面的是否可訪問,，但是有的人卻理解成其他的東西。所以我們要徹底的定義一下權(quán)限是什么,。

權(quán)限到底是名詞屬性還是動(dòng)詞屬性,，還是名詞、動(dòng)詞屬性均包含,，這對(duì)于權(quán)限的含義很重要,。如果是名詞屬性的話，那么它應(yīng)該是有具體的指代物,；如果是動(dòng)詞,，則應(yīng)該具有行為表示。

• 權(quán)限的名詞屬性：api接口,、頁(yè)面,、功能點(diǎn)。

• 權(quán)限的動(dòng)詞屬性：可操作,、不可操作,。

那么我們現(xiàn)在來(lái)看，其實(shí)權(quán)限是名詞,、動(dòng)詞屬性,，它一定是表達(dá)了兩層含義。即控制的對(duì)象,、操作。

1. 例如：權(quán)限A表示頁(yè)面A的可訪問,。

2. 例如：權(quán)限B表示頁(yè)面B可訪問且頁(yè)面內(nèi)的功能b不可使用

3. 例如：權(quán)限C表示接口C不可調(diào)用,。

4. 例如：權(quán)限D(zhuǎn)表示頁(yè)面D可訪問，且接口D可訪問,。

那么進(jìn)一步的說(shuō)明,，權(quán)限可以表示單個(gè)控制的對(duì)象的操作集合，也可以表示多個(gè)控制的對(duì)象的操作集合,。而這兩者的取舍則是有設(shè)計(jì)人員決定的,。

一句話總結(jié)權(quán)限的含義：what（若干元素）進(jìn)行how（若干操作）

2.權(quán)限的劃分原則

我們了解了權(quán)限的具體含義之后，接下來(lái)就是用的問題,，我們?cè)撊绾稳ナ褂脵?quán)限,，如何將系統(tǒng)中的操作元素進(jìn)行一個(gè)組合，這個(gè)我借鑒網(wǎng)上的一篇文章來(lái)解釋,。劃分原則可以按照“最小特權(quán)原則”和“數(shù)據(jù)抽象原則”,。

• 最小特權(quán)原則

1. 我先舉一個(gè)反例，我把系統(tǒng)中所有的元素和操作都組合成一個(gè)權(quán)限。一個(gè)用戶擁有這個(gè)權(quán)限就相當(dāng)擁有了系統(tǒng)所有的功能,，實(shí)際上這肯定是不行的,，用戶在一套系統(tǒng)中一定有他不允許操作的內(nèi)容，哪怕是超級(jí)管理員也可能會(huì)有不能操作的元素,，那么最大化權(quán)限則是行不通,，因?yàn)椴环铣＠怼?/p>

2. 據(jù)此，我們就把權(quán)限再進(jìn)行一個(gè)拆分,，按照業(yè)務(wù)模塊進(jìn)行拆分,，但是這實(shí)際上也是不行的。就比如系統(tǒng)中的財(cái)務(wù)模塊,，假定模塊中含有報(bào)銷頁(yè)面和申報(bào)頁(yè)面,，如果按照模塊進(jìn)行拆分，那么肯定有用戶同時(shí)包含了兩個(gè)互斥功能,。

3. 根據(jù)1和2,，我們需要按照最小化進(jìn)行權(quán)限劃分。但是這個(gè)也是值得商榷的,，因?yàn)椴煌到y(tǒng),，最小的權(quán)限劃分對(duì)于提供的功能來(lái)說(shuō)，劃分的角度也是不同的,。

• 數(shù)據(jù)抽象原則

1. “最小特權(quán)劃分”從某個(gè)程度上來(lái)說(shuō)決定了控制的對(duì)象 ,，而數(shù)據(jù)抽象原則是是決定了操作。

2. 數(shù)據(jù)抽象從字面的意思來(lái)看,，其實(shí)很難理解到底是什么意思,。通常我們口頭上說(shuō)最多的是CRUD增刪查改，這實(shí)際上就是數(shù)據(jù)抽象的一種,，我們可以理解成元素操作許可權(quán)的意思,。

3. 但是CRUD并不是數(shù)據(jù)抽象的全部，增刪查改用于單實(shí)體,，基本是沒問題的,，但是在構(gòu)建關(guān)系上，其實(shí)是不夠用的,，例如任免某個(gè)經(jīng)理管轄某個(gè)部門,，從業(yè)務(wù)表面而言它修改了經(jīng)理的管轄范圍。但是從代碼底層構(gòu)建上來(lái)說(shuō),，它屬于在經(jīng)理和部門間新增了一道關(guān)系,，所以根據(jù)需求我們需要再額外的增加一類許可權(quán)“任免許可”，這一類型的擴(kuò)展則需要根據(jù)系統(tǒng)實(shí)際的業(yè)務(wù)情況進(jìn)行劃分,。

“最小特權(quán)”和“數(shù)據(jù)抽象”分別決定了權(quán)限中控制的對(duì)象和操作,，但是這里面還差了一個(gè)角度,，則是現(xiàn)階段非常普遍的前后端分離的權(quán)限劃分的問題。

• 服務(wù)端的權(quán)限

1. 前后端分離下的服務(wù)端,，本質(zhì)而言只是提供接口的或者rpc服務(wù)等其他資源服務(wù)的服務(wù)提供方,。

2. 服務(wù)端能提供的權(quán)限的鑒權(quán)機(jī)制的對(duì)象：接口服務(wù)（api或者其他形式的服務(wù)）不包含前端的頁(yè)面或頁(yè)面中的功能點(diǎn)。

3. 前端或移動(dòng)端的頁(yè)面元素的控制和鑒權(quán)實(shí)質(zhì)上不由服務(wù)端控制,。

4. 服務(wù)端可以單獨(dú)的控制服務(wù)的權(quán)限,。

5. 服務(wù)端的服務(wù)對(duì)象是前端、移動(dòng)端,、第三方客戶端,，提供的服務(wù)是接口服務(wù)。

在前后端已經(jīng)分離的情況下,，服務(wù)端對(duì)于前端而言只是接口的提供者,，但無(wú)權(quán)干涉前端頁(yè)面的展示，服務(wù)端對(duì)于前端而言,，能提供的是僅鑒權(quán)服務(wù)的接口而已,，但是頁(yè)面的構(gòu)成，頁(yè)面的欄目菜單或頁(yè)面內(nèi)的功能點(diǎn)的構(gòu)成均由前端單獨(dú)完成的,。

• 前端或移動(dòng)端的權(quán)限

1. 前端的鑒權(quán)包含頁(yè)面的可訪問,，和頁(yè)面上的某項(xiàng)功能按鈕是否可以操作。

2. 前端和移動(dòng)端的服務(wù)對(duì)象是用戶,，提供的服務(wù)是可視化的頁(yè)面,。

前后端的服務(wù)對(duì)象的責(zé)任劃分清晰之后，我們就不會(huì)混雜權(quán)限的歸屬的問題,，在過去前后端沒分離的情況下,，頁(yè)面本身就是服務(wù)端的一體，就沒有這方面的問題,。雖然分清楚了各端本質(zhì)提供的服務(wù)的情況,，但是前后端分離的權(quán)限劃分中仍有新的問題。

1. 因?yàn)榉?wù)端和前端的鑒權(quán)對(duì)象不一致,，服務(wù)端只能鑒權(quán)到api接口,，那么是否將api接口和前端的頁(yè)面乃至頁(yè)面功能點(diǎn)進(jìn)行數(shù)據(jù)庫(kù)表與表層面的綁定關(guān)系,。

2. 如果進(jìn)行了進(jìn)行了表與表之間的綁定關(guān)系,，那么整個(gè)權(quán)限系統(tǒng)的維護(hù)量，是否能在能承受范圍之內(nèi),。

3. 如果不進(jìn)行表與表之間的綁定關(guān)系,，前端頁(yè)面在操作功能的時(shí)候，服務(wù)端如何鑒權(quán)頁(yè)面調(diào)用的api接口是否在用戶可操作的權(quán)限之內(nèi),？

其實(shí)上面的問題則需要一個(gè)取舍,，要么增加運(yùn)維成本嚴(yán)格控制前端調(diào)用api接口的關(guān)系,，偏重服務(wù)端的接口服務(wù)鑒權(quán)。要么是給api接口和前端頁(yè)面及功能點(diǎn)再提供一個(gè)通性的邏輯判斷處理,，如：頁(yè)面及調(diào)用的功能點(diǎn)屬于某個(gè)業(yè)務(wù)模塊的操作許可,，而頁(yè)面觸發(fā)的接口也剛好是這個(gè)業(yè)務(wù)模塊的操作許可，那么鑒權(quán)通過,，否則鑒權(quán)失敗,。這種就是屬于側(cè)重前端對(duì)于用戶的控制，弱化了接口級(jí)的控制,。

3.角色與權(quán)限的關(guān)系

通過1,，2的描述，基本確定了權(quán)限的定義和劃分一個(gè)權(quán)限的通用法則,。用戶在系統(tǒng)中最終是通過權(quán)限來(lái)使用各種功能點(diǎn),，是否有必要在用戶和權(quán)限中間再額外的附加一個(gè)關(guān)系。在我們現(xiàn)在的權(quán)限設(shè)計(jì)中,，是增加了這樣一層關(guān)系的,，就是角色。

1. 減少操作層面的重復(fù)性,。角色其實(shí)就是一組權(quán)限的集合,，是權(quán)限集合的更高級(jí)抽象，為了便于運(yùn)維和實(shí)際管理,，通過角色的賦予,，替代了權(quán)限賦予用戶的繁瑣性，在一套系統(tǒng)中,，普遍情況都是權(quán)限的數(shù)量多于角色的數(shù)量,。

2. 權(quán)限是控制對(duì)象和操作集合，它本身不存在任何狀態(tài),，但是在賦予在用戶身上則擁有了狀態(tài),，比如權(quán)限A中允許用戶訪問頁(yè)面A，權(quán)限B允許用戶訪問頁(yè)面B,，權(quán)限D(zhuǎn)運(yùn)行用戶訪問B頁(yè)面,，但是不允許訪問A頁(yè)面。那么這層關(guān)系的維護(hù)在角色層面的話,，會(huì)更加清晰,，也就是說(shuō)本身角色具有權(quán)限集合組裝的策略問題，對(duì)于互斥的權(quán)限有不同的方案處理,。（權(quán)限中沒有某個(gè)操作和權(quán)限中禁止某個(gè)操作,，是兩個(gè)不同的角度，不能混為一談）

3. 因?yàn)闄?quán)限的可能存在互斥性,，在實(shí)際業(yè)務(wù)中也會(huì)引發(fā)角色的互斥性,，舉一個(gè)現(xiàn)實(shí)中的案例來(lái)解釋互斥性：張三是軟件部的負(fù)責(zé)人但因?yàn)楣ぷ鞯奶厥庑砸餐瑯与`屬于業(yè)務(wù)部的普通員工,，我們?cè)O(shè)定負(fù)責(zé)人是可以要求人事部門給本部門進(jìn)行招聘的，在實(shí)際的情況中,，張三能給軟件部招聘新員工,，但是不能給業(yè)務(wù)部招聘員工。我們把這個(gè)案例運(yùn)用在系統(tǒng)中,，張三則是擁有負(fù)責(zé)人和普通員工兩個(gè)角色,，但是招聘的功能如果不加以控制，則會(huì)發(fā)生張三給業(yè)務(wù)部招人的結(jié)果,。于是為了解決角色的這類問題,，引入了職責(zé)劃分的方案。

4. 職責(zé)劃分分為：靜態(tài),、動(dòng)態(tài),。所謂靜態(tài)職責(zé)劃分則是在角色創(chuàng)建之初就已經(jīng)確定了角色的職責(zé)內(nèi)容。動(dòng)態(tài)職責(zé)劃分是系統(tǒng)運(yùn)行過程中對(duì)用戶已有的角色進(jìn)行控制,，例如：某些角色不能共存在用戶身上（互斥）,、角色或角色的分配數(shù)量限定（控制用量）、角色與角色同時(shí)只能激活一個(gè)進(jìn)行使用（時(shí)刻唯一）,。

引入角色的概念后,，實(shí)際上這已經(jīng)是一個(gè)比較完整的RBAC的權(quán)限設(shè)計(jì)的模型了。

4.數(shù)據(jù)表的設(shè)計(jì)思路

根據(jù)3的結(jié)論,，實(shí)質(zhì)上已經(jīng)有了一個(gè)基礎(chǔ)的表設(shè)計(jì)的雛形,。在這里就有一些值得注意的點(diǎn)。

• （1）問：權(quán)限表是否有必要存在,？

• （1）答：這個(gè)要結(jié)合系統(tǒng)的實(shí)際使用場(chǎng)景進(jìn)行考慮,，如果系統(tǒng)中的權(quán)限的對(duì)象很單一，比如只有頁(yè)面,，或者只有api接口的話,，其實(shí)權(quán)限表可有可無(wú)。增加權(quán)限表反而會(huì)導(dǎo)致初始化項(xiàng)目權(quán)限的工作量增加,。但是若系統(tǒng)中的權(quán)限對(duì)象是多個(gè),，那么權(quán)限表的存在就有了更深層次的意義。在權(quán)限對(duì)象是多個(gè)的情況,，權(quán)限表的存在就是為了更好更抽象的組合“最小特權(quán)”及“責(zé)任劃分”的操作對(duì)象,。同時(shí)，一旦系統(tǒng)中的操作對(duì)象增加了,，只需要給權(quán)限表增加一個(gè)對(duì)象表和關(guān)系表就可以了,。這樣易于擴(kuò)展,。

• （2）問：api接口和頁(yè)面實(shí)際上是沒有關(guān)系的,，但是在鑒權(quán)活動(dòng)是有關(guān)系的,，頁(yè)面若和api沒有一點(diǎn)綁定聯(lián)系的話，服務(wù)端接口調(diào)用的時(shí)候則要么攔截掉所有指定的接口（頁(yè)面和api接口沒綁定的話,，則頁(yè)面的接口調(diào)用都不能成功）,，服務(wù)端接口完全不攔截接口，也會(huì)不安全,，但是api接口和頁(yè)面功能在表結(jié)構(gòu)層面的綁定會(huì)產(chǎn)生運(yùn)維的大量工作成本,，如何更好的設(shè)計(jì)。

• （2）答：在權(quán)限如何劃分中已經(jīng)提過了這一點(diǎn),，在表結(jié)構(gòu)中,，我們可以增加一張業(yè)務(wù)模塊表和操作表（也可以在數(shù)據(jù)字典表中增加這兩類數(shù)據(jù)），我們可以在頁(yè)面和功能點(diǎn)鐘 綁定業(yè)務(wù)模塊和操作表關(guān)系,，在api接口的代碼層面去綁定業(yè)務(wù)模塊和操作,，在邏輯上綁定關(guān)系，解耦表結(jié)構(gòu)之間的關(guān)系,，那么可以在一定程度上解決這一點(diǎn),，這樣做只會(huì)出現(xiàn)一種問題，那就是用戶訪問頁(yè)面的時(shí)候可調(diào)用的api接口會(huì)比實(shí)際可調(diào)用的接口數(shù)要多,，但是前端權(quán)限管理會(huì)隱藏功能點(diǎn),，這樣就在可視化的程度上解決了這個(gè)問題。

5.安全框架

由于我們是基于RBAC的權(quán)限設(shè)計(jì),，現(xiàn)行java框架下最常見的就是shiro和Spring Security ,。這兩個(gè)就是仁者見仁智者見智了，我兩者都實(shí)用過,。僅建議使用shiro的話,，可以更好的理解RBAC的設(shè)計(jì)思路，Spring Security 也是個(gè)不錯(cuò)的框架,，但是它涉及到的概念太多,，并不利于初學(xué)者去了解最基本的權(quán)限設(shè)計(jì)。我在這只在學(xué)習(xí)的角度上去比較這兩個(gè)框架,，并沒有再其他領(lǐng)域去做比較,，也不去比較。