軟件開發(fā)APP開發(fā) 軟件開發(fā)公司 APP開發(fā)公司

本文會(huì)通過三部分對權(quán)限設(shè)計(jì)進(jìn)行描述，第一部分是理論部分；第二部分會(huì)通過幾個(gè)故事對RABC模型包括的四個(gè)主要部件模型進(jìn)行說明；第三部分為常見問題的匯總及相應(yīng)的解決辦法。

由于業(yè)務(wù)需要，最近接觸到了關(guān)于權(quán)限設(shè)計(jì)的一些東西，也就有了自己的一些總結(jié)和思考，在此和大家進(jìn)行探討。

一、名詞解釋

在開始介紹相關(guān)理論之前，先解釋下本文會(huì)用到的一些名詞：

1. 用戶：指使用產(chǎn)品的人，有的地方也叫主體；

2. 權(quán)限：是指在特定的情況下的一個(gè)或一組操作，如某司內(nèi)部系統(tǒng)的人員管理中，增加人員；

3. 權(quán)限組：一組權(quán)限的集合；

4. 角色：權(quán)限集合的概念，如信息管理員；

5. 角色組：一組角色的集合，如信息管理員1和信息管理員2集合為管理員；

6. 資源：資源和權(quán)限比較難以區(qū)分，在此舉例子說明，如某司內(nèi)部系統(tǒng)的人員管理頁面；

7. 屬性：屬性和屬性值相對應(yīng)，如信息管理員訪問人員管理，屬性值為：1（是），˙這個(gè)例子中，“訪問人員管理”為屬性，1為屬性值；

8. 主體：通常指用戶，是訪問操作的主動(dòng)發(fā)起者，它是系統(tǒng)中信息流的啟動(dòng)者，可以使信息流在實(shí)體之間流動(dòng)。

9. 客體：通常是指信息的載體或從其他主體或客體接收信息的實(shí)體。

二、常見的權(quán)限控制模型

權(quán)限設(shè)計(jì)，相對于其他的功能設(shè)計(jì)，有更為成熟的可借鑒的模型，各位可根據(jù)產(chǎn)品業(yè)務(wù)的需要進(jìn)行采用，也可對某一個(gè)模型進(jìn)行簡化或者延伸。關(guān)于理論部分的資料整理于維基百科。
1. 自主訪問控制（DAC）

核心為用戶可將自己擁有的權(quán)限分配給其他人。

優(yōu)點(diǎn)：用戶可根據(jù)需要自行分配自己的權(quán)限。

缺點(diǎn)：所有用戶的權(quán)限不能統(tǒng)一管理，用戶和用戶的權(quán)限比較分散，后期調(diào)整只能單個(gè)進(jìn)行調(diào)整，不易維護(hù)

2. 強(qiáng)制訪問控制（MAC）

通過無法回避的訪問限制來阻止直接或間接地非法入侵。如主體和客體都有固定的安全屬性，在每次訪問發(fā)生時(shí)，系統(tǒng)檢測安全屬性以便確定一個(gè)用戶是否有權(quán)訪問該文件。當(dāng)用戶的安全屬性值大于等于客體的安全屬性值時(shí)，客體就可以被訪問。強(qiáng)制訪問控制多應(yīng)用于對安全性要求比較高的系統(tǒng)，如多級安全軍事系統(tǒng)；

3. 基于角色的權(quán)限管理（RBAC）

這個(gè)模型我們見的會(huì)比較多，模型基礎(chǔ)就是用戶和角色，角色和權(quán)限做多對多的對應(yīng)。標(biāo)準(zhǔn)的RBAC模型包括四個(gè)部件模型，分別為基本模型RABC0、角色分級模型RABC1、角色限制模型RABC2、統(tǒng)一模型RABC3。

RABC1（角色分級模型）為引入角色間的繼承關(guān)系，角色繼承分為一般繼承關(guān)系、受限繼承關(guān)系，相較于一般繼承關(guān)系，受限繼承關(guān)系要求角色繼承關(guān)系是一個(gè)樹結(jié)構(gòu)。

RABC2（角色限制模型）引入了角色間的約束關(guān)系，主要約束規(guī)則包括：角色間的互斥關(guān)系，在處理用戶和這些角色之間的關(guān)系時(shí)，包括靜態(tài)分離和動(dòng)態(tài)分離，靜態(tài)分離指互斥的角色不能同時(shí)賦予同一個(gè)用戶；動(dòng)態(tài)分離指用戶不能同時(shí)操作兩個(gè)互斥的角色進(jìn)行登錄。

RABC3（統(tǒng)一模型）同時(shí)包含了1和2的特性。

優(yōu)點(diǎn)：在產(chǎn)品和數(shù)據(jù)設(shè)計(jì)層面，有更好的擴(kuò)展性，可控制到任意的粒度。

4. 基于屬性的訪問控制（ABAC）

這個(gè)模型我研究了半天，才稍微明白一些。這里只能淺顯的描述一下模型理論：

主體訪問客體時(shí)，自己是帶有屬性的，例如自己的角色、職位等；客體本身也是有屬性的，如角色、區(qū)域，主體在訪問客體時(shí)，通過第三方屬性策略，判斷主體的具體權(quán)限。

小結(jié)：以上描述了在本系列中會(huì)用到的關(guān)鍵性詞匯，接著描述了常見的一些權(quán)限控制的基本模型，通過對權(quán)限設(shè)計(jì)基礎(chǔ)理論的理解，掌握用戶、權(quán)限、角色的理論精髓，根據(jù)產(chǎn)品業(yè)務(wù)的需要是可以延伸出來很多不同的權(quán)限控制模型的。

三、背景

主角為某公司內(nèi)部信息平臺(tái)。在該平臺(tái)內(nèi)可對公司人員和客戶進(jìn)行管理，包括增刪改查。

涉及到的用戶包括小明、小紅、鐵蛋、鋼蛋、Lucy、Lily、用戶1、用戶2…用戶6，用戶7，各用戶對應(yīng)的崗位和權(quán)限如表1.1.1。

表1.1.1 用戶權(quán)限表

四、RBAC四個(gè)部件

了解了故事背景后，開始正文，在接下來的內(nèi)容中，會(huì)通過四個(gè)故事，對RBAC的四個(gè)部件模型的使用進(jìn)行說明。首先是基礎(chǔ)模型RABC0。

1. 基本模型：RBAC0

故事1：目前公司規(guī)模只有十幾個(gè)人，一天老板把我叫過去說，涉及到數(shù)據(jù)的私密性，希望可以對每個(gè)職員的權(quán)限進(jìn)行控制。

這種情境下，我們可以用最基本的RABC0模型來進(jìn)行設(shè)計(jì)，主要分為以下三步：

第一步，抽取角色，確定用戶和角色的關(guān)系；

這里的角色主要是指在組織內(nèi)承擔(dān)特定的業(yè)務(wù)活動(dòng)，并和別的業(yè)務(wù)角色進(jìn)行交互的業(yè)務(wù)角色。業(yè)務(wù)角色的抽取主要有兩種方式，一種是直接和崗位對應(yīng)，另外一種是根據(jù)流程的本質(zhì)和需要定義角色；由于故事及故事背景均不涉及到具體的流程，所以這里根據(jù)用戶的權(quán)限共同性，進(jìn)行角色的定義和抽取，見表2.1。

第二步，確定各角色的用例圖，見圖2.1.1；

第三步，根據(jù)業(yè)務(wù)復(fù)雜度、用戶特點(diǎn)進(jìn)行原型草圖設(shè)計(jì)，見圖2.1.2；

表2.1.1 用戶、角色的對應(yīng)關(guān)系

圖2.1.1 角色用例圖

圖2.1.2 增加角色和用戶的原型

使用此模型時(shí)，我們需要注意的問題有：

1. 用戶和角色為多對一的關(guān)系，如果需要用到多對多的關(guān)系，將涉及到角色關(guān)系的處理，此種情況會(huì)在故事3中進(jìn)行說明；

2. 權(quán)限一定是動(dòng)態(tài)可配置的，不是靜態(tài)的，這點(diǎn)一定要在著手開發(fā)前進(jìn)行說明，一般情況，權(quán)限的數(shù)據(jù)結(jié)構(gòu)為樹形，合理的數(shù)據(jù)結(jié)構(gòu)，便于前端根據(jù)實(shí)際需求進(jìn)行解析；

3. 視圖和數(shù)據(jù)是綁定的，所以前端對數(shù)據(jù)的解析主要看視圖、交互的設(shè)計(jì)；

2. 角色分級模型：RBAC1

故事2：一天老板又把我叫到辦公室，語重心長的說，這個(gè)小王呀，管理平臺(tái)設(shè)置權(quán)限的同事反饋，一個(gè)個(gè)的角色設(shè)置好麻煩啊，能不能上級直接擁有下級的權(quán)限啊，比如人事主管直接擁有下屬所有員工擁有的權(quán)限？

這種場景下，可以使用角色分級模型。在理論篇中，我們提到過，分級模型引入了角色間繼承關(guān)系，分為一般繼承和受限繼承。

一般繼承關(guān)系只要求角色繼承關(guān)系為絕對偏序關(guān)系，允許角色間的多繼承。這里絕對偏序關(guān)系是指角色間繼承關(guān)系為非閉環(huán)。而受限繼承進(jìn)一步要求角色繼承關(guān)系為樹結(jié)構(gòu)。

基于RBAC1進(jìn)行權(quán)限的設(shè)計(jì)，相比RBAC0，需要設(shè)計(jì)角色間層級關(guān)系和角色間繼承關(guān)系。RBAC1兩種繼承關(guān)系的差別主要為繼承關(guān)系的不同，詳見第二步中的角色繼承關(guān)系圖。

第一步，抽取業(yè)務(wù)角色，確定角色和用戶間關(guān)系；

同故事1不同，因?yàn)橐蠼巧g有明顯的層級關(guān)系，所以在沒有其他需求的情況下，此故事背景下根據(jù)業(yè)務(wù)部門和崗位進(jìn)行角色的抽取，見表2.2.1；

第二步，確定角色之間的層級關(guān)系和繼承關(guān)系；

我們使用樹形和非閉環(huán)網(wǎng)圖來表示角色之間的層級關(guān)系，見圖2.2.1、圖2.2.2和圖2.2.3；

第三步，進(jìn)行原型草圖的設(shè)計(jì)；

草圖包括增加角色、增加人員和角色管理。見圖2.2.4；

表2.2.1 角色用戶對應(yīng)關(guān)系

圖 2.2.1 角色層級關(guān)系

圖2.2.2 一般繼承關(guān)系

圖2.2.3 受限繼承關(guān)系

圖2.2.4 添加角色和人員

圖2.2.5 角色管理

說明：

1. 本故事中沒有對各個(gè)角色的用例進(jìn)行描述，但是通過表2.2.1，大家可以自行腦補(bǔ)。

2. 一般繼承關(guān)系和受限繼承關(guān)系的區(qū)別主要在角色間的關(guān)系；見圖2.2.2中的紅色線條；

3. 上級角色可以繼承多個(gè)下級角色的權(quán)限，上級角色的權(quán)限為所有繼承角色的權(quán)限的疊加；

4. 角色間的繼承關(guān)系可能會(huì)和現(xiàn)實(shí)中的有所差異，現(xiàn)實(shí)中不會(huì)出現(xiàn)運(yùn)營角色繼承人力角色的權(quán)限情況；

5. 可能會(huì)遇到的問題：由于低級角色的權(quán)限全部被高級角色繼承，就會(huì)導(dǎo)致沒有自己角色的私有權(quán)限；處理方式會(huì)在第三篇常見問題匯總進(jìn)行說明。

3. 角色限制模型：RABC2
故事3：中午吃飯，同事跟我說，由于公司現(xiàn)在組織結(jié)構(gòu)問題，他們組很多人有多個(gè)角色，但是由于現(xiàn)在我們只能設(shè)置一個(gè)角色，所以他們在工作中需要切換多個(gè)賬號(hào)，很不方便。

這種場景下，可以使用角色限制模型。在理論篇中我們講過，角色限制模型跟基本模型相比，用戶和角色為多對多的關(guān)系，如果采用責(zé)任分離模型，則需要定義角色和角色間的互斥關(guān)系，也就是約束規(guī)則。

在本故事中，我們采用動(dòng)態(tài)分離的方式處理互斥的角色的賦予，不能同時(shí)。除需要定義角色間的互斥關(guān)系外，完成整個(gè)權(quán)限的設(shè)置同RBAC1的步驟類似，包括以下2步。

第一步，抽取業(yè)務(wù)角色，確定角色和用戶間關(guān)系；

在本故事中，為了表明角色間的互斥，引入全能型員工用戶9，角色為行政主管、人力主管和運(yùn)營主管。

采用故事2中的方法對角色進(jìn)行抽取，并確定角色間的互斥關(guān)系，見表2.3.1；

第二步，進(jìn)行原型草圖設(shè)計(jì)；

包括增加角色、增加人員和角色管理，以及多角色用戶登錄時(shí)，對角色的處理。見圖2.3.1、圖2.3.2、圖2.3.3；

表2.3.1 角色間關(guān)系

圖2.3.1 增加角色和人員

圖2.3.2 角色管理

圖2.3.3 用戶選擇操作角色

說明：

1. 當(dāng)采用靜態(tài)分離時(shí)，互斥的角色不能同時(shí)被賦予同一個(gè)用戶；

2. 動(dòng)態(tài)分離時(shí)，則用戶登錄后需要選擇使用的角色，同時(shí)要支持根據(jù)需要切換角色；

4. 統(tǒng)一模型：RABC3

統(tǒng)一模型是包括了繼承和分離兩種情況的更為復(fù)雜的模型，即既要定義角色間的的繼承關(guān)系，也要維護(hù)好角色間的責(zé)任分離關(guān)系。

在這里就不做過多的贅述，因?yàn)橹灰S護(hù)好了角色間的約束關(guān)系，其他規(guī)則類的處理方式同RABC1和RABC2。

由于此模型相對來講較為復(fù)雜，對于一般的系統(tǒng)，前三種就可以滿足需求，不建議也沒必要使用此種模型。

總結(jié)：實(shí)戰(zhàn)采用了三個(gè)故事，對基于角色的權(quán)限控制進(jìn)行了描述，包括RBAC0、RBAC1、RBAC2，由于RBAC3為1和2的集合，并且在實(shí)際工作中，使用場景比較少，所以沒有進(jìn)行詳細(xì)說明。萬變不離其宗，只要掌握了基于角色的權(quán)限控制的基礎(chǔ)理論，根據(jù)產(chǎn)品的需求進(jìn)行設(shè)計(jì)即可，也不必強(qiáng)制性的生搬硬套模型，下面會(huì)對一些常見的問題進(jìn)行匯總，包括角色數(shù)據(jù)權(quán)限的處理等。

五、常見的問題匯總
問題1：用戶、角色和權(quán)限的關(guān)系，以及如何處理多角色時(shí)的權(quán)限？

角色和權(quán)限為多對多的關(guān)系是毋庸置疑的。對于用戶和角色的關(guān)系，在實(shí)戰(zhàn)篇中，不同的對應(yīng)關(guān)系并不一樣，但是設(shè)計(jì)時(shí)用戶、角色最好設(shè)計(jì)為多對多的關(guān)系。

當(dāng)用戶和角色為多對多的關(guān)系時(shí)，我們就需要考慮多個(gè)角色時(shí)，權(quán)限如何處理，根據(jù)業(yè)務(wù)需求，需要定義角色和角色、權(quán)限和權(quán)限之間的關(guān)系，定義好關(guān)系后，根據(jù)約束規(guī)則進(jìn)行處理。

問題2：在RBAC1模型中，由于高一級的角色繼承了低一級角色的所有權(quán)限，會(huì)導(dǎo)致低一級的角色沒有自己的私有權(quán)限。

在有繼承關(guān)系的角色權(quán)限模型中，如果高一級的角色繼承了低一級的所有權(quán)限，就會(huì)導(dǎo)致低一級的角色沒有自己的私有權(quán)限，這一點(diǎn)和實(shí)際的業(yè)務(wù)會(huì)存在不符合的情況。針對這一點(diǎn)的解決辦法有：

1）引入私有角色，這種辦法會(huì)導(dǎo)致角色數(shù)量變多，提升了角色管理的復(fù)雜性；

2）引入私有權(quán)限和公有權(quán)限，私有權(quán)限不允許繼承，公有權(quán)限允許繼承。不同的業(yè)務(wù)中對公有和私有的定義會(huì)有所不同，如傳播深度N；公有、私有和特征，權(quán)限是否可被繼承，根據(jù)繼承方式確定，繼承方式包括一般繼承、公有化繼承、私有化繼承和無特征繼承等。

問題3：角色數(shù)據(jù)權(quán)限如何控制？

作為ToB或者平臺(tái)類產(chǎn)品，除了功能權(quán)限，最為頭疼的就是數(shù)據(jù)權(quán)限。實(shí)際業(yè)務(wù)中，相同的角色在同一功能下的數(shù)據(jù)權(quán)限是不同的，比如同為代理商角色，代理商A作為華南區(qū)的代理商，在客戶管理時(shí)，只能查看華南區(qū)的；同理代理商B作為華中區(qū)的代理商，在客戶管理處，則只能查看華中的。

針對這種情況，需要對數(shù)據(jù)權(quán)限進(jìn)行控制。針對數(shù)據(jù)權(quán)限的控制，可以在設(shè)置角色權(quán)限時(shí)進(jìn)行控制，如果沒有對數(shù)據(jù)權(quán)限進(jìn)行控制，則默認(rèn)為所有的數(shù)據(jù)。

除了數(shù)據(jù)和功能權(quán)限，我們還會(huì)遇到字段權(quán)限，比如：代理商C和D都能看到華南區(qū)的客戶情況，但是C看不到客戶聯(lián)系方式，D則能看到聯(lián)系方式。如果有需要對字段權(quán)限進(jìn)行控制，則可以在設(shè)置角色的數(shù)據(jù)權(quán)限或者功能權(quán)限時(shí)，進(jìn)行控制。

問題4：權(quán)限設(shè)計(jì)時(shí)，在交互層面需要考慮的因素都有哪些。

講到交互層，就不得不講用戶體驗(yàn)，權(quán)限設(shè)計(jì)也是如此。在保證一定擴(kuò)展性的基礎(chǔ)上考慮用戶體驗(yàn)。

平臺(tái)類或者內(nèi)部產(chǎn)品，雖然設(shè)計(jì)宗旨不同，但是也得讓我們的用戶用著爽不是。

在做功能權(quán)限時(shí)，有時(shí)候開發(fā)會(huì)說，你這個(gè)設(shè)計(jì)方案不存在無限擴(kuò)展的可能性啊，我們后期可能存在重新做的風(fēng)險(xiǎn)啊。

如果這個(gè)方案指的是業(yè)務(wù)層面，那可能是真的存在問題，這個(gè)時(shí)候需要和研發(fā)好好溝通一番。但如果是指交互方案，那這個(gè)時(shí)候我們是可以堅(jiān)持自己的，因?yàn)榻换シ桨缚隙ㄊ墙Y(jié)合產(chǎn)品現(xiàn)狀、后期的規(guī)劃發(fā)展以及用戶的使用習(xí)慣，在保證用戶體驗(yàn)的基礎(chǔ)上輸出的。

雖然前端對數(shù)據(jù)的解讀方式一定程度上依賴于交互方案，但是講到健壯性和擴(kuò)展性，改動(dòng)起來的難易程度也是另外一個(gè)維度的度量方式，不是嗎？

問題5：權(quán)限設(shè)置完成后，相應(yīng)的菜單和功能的狀態(tài)如何處理。

這個(gè)問題主要是指功能權(quán)限設(shè)置完成后，對應(yīng)的菜單和功能的入口狀態(tài)如何處理。一般有兩種處理方式：

第一種：顯示，點(diǎn)擊時(shí)告知用戶是否有此權(quán)限；

第二種：根據(jù)權(quán)限設(shè)置，沒有權(quán)限直接不予顯示。

問題6：是否有必要設(shè)置默認(rèn)賬號(hào)和默認(rèn)權(quán)限。

對于ToB類或者平臺(tái)類的產(chǎn)品，正常來講都會(huì)有一個(gè)默認(rèn)的超級管理員的角色以及角色對應(yīng)的賬號(hào)，否則系統(tǒng)內(nèi)第一個(gè)角色誰來添加？

默認(rèn)權(quán)限的設(shè)置則根據(jù)需要進(jìn)行設(shè)置，如果是不必要進(jìn)行控制的權(quán)限，當(dāng)然是可以設(shè)置為默認(rèn)權(quán)限的。