軟件開發APP開發 軟件開發公司 APP開發公司

本文會通(tōng)過三部分(fēn)對(duì)權限設計進行描述，第一部分(fēn)是理(lǐ)論部分(fēn)；第二部分(fēn)會通(tōng)過幾個(gè)故事對(duì)RABC模型包括的(de)四個(gè)主要部件模型進行說明(míng)；第三部分(fēn)爲常見問題的(de)彙總及相應的(de)解決辦法。

由于業務需要，最近接觸到了(le)關于權限設計的(de)一些東西，也(yě)就有了(le)自己的(de)一些總結和(hé)思考，在此和(hé)大(dà)家進行探討(tǎo)。

一、名詞解釋

在開始介紹相關理(lǐ)論之前，先解釋下(xià)本文會用(yòng)到的(de)一些名詞：

1. 用(yòng)戶：指使用(yòng)産品的(de)人(rén)，有的(de)地方也(yě)叫主體；

2. 權限：是指在特定的(de)情況下(xià)的(de)一個(gè)或一組操作，如某司内部系統的(de)人(rén)員(yuán)管理(lǐ)中，增加人(rén)員(yuán)；

3. 權限組：一組權限的(de)集合；

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

5. 角色組：一組角色的(de)集合，如信息管理(lǐ)員(yuán)1和(hé)信息管理(lǐ)員(yuán)2集合爲管理(lǐ)員(yuán)；

6. 資源：資源和(hé)權限比較難以區(qū)分(fēn)，在此舉例子說明(míng)，如某司内部系統的(de)人(rén)員(yuán)管理(lǐ)頁面；

7. 屬性：屬性和(hé)屬性值相對(duì)應，如信息管理(lǐ)員(yuán)訪問人(rén)員(yuán)管理(lǐ)，屬性值爲：1（是），˙這(zhè)個(gè)例子中，“訪問人(rén)員(yuán)管理(lǐ)”爲屬性，1爲屬性值；

8. 主體：通(tōng)常指用(yòng)戶，是訪問操作的(de)主動發起者，它是系統中信息流的(de)啓動者，可(kě)以使信息流在實體之間流動。

9. 客體：通(tōng)常是指信息的(de)載體或從其他(tā)主體或客體接收信息的(de)實體。

二、常見的(de)權限控制模型

權限設計，相對(duì)于其他(tā)的(de)功能設計，有更爲成熟的(de)可(kě)借鑒的(de)模型，各位可(kě)根據産品業務的(de)需要進行采用(yòng)，也(yě)可(kě)對(duì)某一個(gè)模型進行簡化(huà)或者延伸。關于理(lǐ)論部分(fēn)的(de)資料整理(lǐ)于維基百科。
1. 自主訪問控制（DAC）

核心爲用(yòng)戶可(kě)将自己擁有的(de)權限分(fēn)配給其他(tā)人(rén)。

優點：用(yòng)戶可(kě)根據需要自行分(fēn)配自己的(de)權限。

缺點：所有用(yòng)戶的(de)權限不能統一管理(lǐ)，用(yòng)戶和(hé)用(yòng)戶的(de)權限比較分(fēn)散，後期調整隻能單個(gè)進行調整，不易維護

2. 強制訪問控制（MAC）

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

3. 基于角色的(de)權限管理(lǐ)（RBAC）

這(zhè)個(gè)模型我們見的(de)會比較多(duō)，模型基礎就是用(yòng)戶和(hé)角色，角色和(hé)權限做(zuò)多(duō)對(duì)多(duō)的(de)對(duì)應。标準的(de)RBAC模型包括四個(gè)部件模型，分(fēn)别爲基本模型RABC0、角色分(fēn)級模型RABC1、角色限制模型RABC2、統一模型RABC3。

RABC1（角色分(fēn)級模型）爲引入角色間的(de)繼承關系，角色繼承分(fēn)爲一般繼承關系、受限繼承關系，相較于一般繼承關系，受限繼承關系要求角色繼承關系是一個(gè)樹結構。

RABC2（角色限制模型）引入了(le)角色間的(de)約束關系，主要約束規則包括：角色間的(de)互斥關系，在處理(lǐ)用(yòng)戶和(hé)這(zhè)些角色之間的(de)關系時(shí)，包括靜态分(fēn)離和(hé)動态分(fēn)離，靜态分(fēn)離指互斥的(de)角色不能同時(shí)賦予同一個(gè)用(yòng)戶；動态分(fēn)離指用(yòng)戶不能同時(shí)操作兩個(gè)互斥的(de)角色進行登錄。

RABC3（統一模型）同時(shí)包含了(le)1和(hé)2的(de)特性。

優點：在産品和(hé)數據設計層面，有更好的(de)擴展性，可(kě)控制到任意的(de)粒度。

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

這(zhè)個(gè)模型我研究了(le)半天，才稍微明(míng)白一些。這(zhè)裏隻能淺顯的(de)描述一下(xià)模型理(lǐ)論：

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

小結：以上描述了(le)在本系列中會用(yòng)到的(de)關鍵性詞彙，接著(zhe)描述了(le)常見的(de)一些權限控制的(de)基本模型，通(tōng)過對(duì)權限設計基礎理(lǐ)論的(de)理(lǐ)解，掌握用(yòng)戶、權限、角色的(de)理(lǐ)論精髓，根據産品業務的(de)需要是可(kě)以延伸出來(lái)很多(duō)不同的(de)權限控制模型的(de)。

三、背景

主角爲某公司内部信息平台。在該平台内可(kě)對(duì)公司人(rén)員(yuán)和(hé)客戶進行管理(lǐ)，包括增删改查。

涉及到的(de)用(yòng)戶包括小明(míng)、小紅、鐵蛋、鋼蛋、Lucy、Lily、用(yòng)戶1、用(yòng)戶2…用(yòng)戶6，用(yòng)戶7，各用(yòng)戶對(duì)應的(de)崗位和(hé)權限如表1.1.1。

表1.1.1 用(yòng)戶權限表

四、RBAC四個(gè)部件

了(le)解了(le)故事背景後，開始正文，在接下(xià)來(lái)的(de)内容中，會通(tōng)過四個(gè)故事，對(duì)RBAC的(de)四個(gè)部件模型的(de)使用(yòng)進行說明(míng)。首先是基礎模型RABC0。

1. 基本模型：RBAC0

故事1：目前公司規模隻有十幾個(gè)人(rén)，一天老闆把我叫過去說，涉及到數據的(de)私密性，希望可(kě)以對(duì)每個(gè)職員(yuán)的(de)權限進行控制。

這(zhè)種情境下(xià)，我們可(kě)以用(yòng)最基本的(de)RABC0模型來(lái)進行設計，主要分(fēn)爲以下(xià)三步：

第一步，抽取角色，确定用(yòng)戶和(hé)角色的(de)關系；

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

第二步，确定各角色的(de)用(yòng)例圖，見圖2.1.1；

第三步，根據業務複雜(zá)度、用(yòng)戶特點進行原型草(cǎo)圖設計，見圖2.1.2；

表2.1.1 用(yòng)戶、角色的(de)對(duì)應關系

圖2.1.1 角色用(yòng)例圖

圖2.1.2 增加角色和(hé)用(yòng)戶的(de)原型

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

1. 用(yòng)戶和(hé)角色爲多(duō)對(duì)一的(de)關系，如果需要用(yòng)到多(duō)對(duì)多(duō)的(de)關系，将涉及到角色關系的(de)處理(lǐ)，此種情況會在故事3中進行說明(míng)；

2. 權限一定是動态可(kě)配置的(de)，不是靜态的(de)，這(zhè)點一定要在著(zhe)手開發前進行說明(míng)，一般情況，權限的(de)數據結構爲樹形，合理(lǐ)的(de)數據結構，便于前端根據實際需求進行解析；

3. 視圖和(hé)數據是綁定的(de)，所以前端對(duì)數據的(de)解析主要看視圖、交互的(de)設計；

2. 角色分(fēn)級模型：RBAC1

故事2：一天老闆又把我叫到辦公室，語重心長(cháng)的(de)說，這(zhè)個(gè)小王呀，管理(lǐ)平台設置權限的(de)同事反饋，一個(gè)個(gè)的(de)角色設置好麻煩啊，能不能上級直接擁有下(xià)級的(de)權限啊，比如人(rén)事主管直接擁有下(xià)屬所有員(yuán)工擁有的(de)權限？

這(zhè)種場(chǎng)景下(xià)，可(kě)以使用(yòng)角色分(fēn)級模型。在理(lǐ)論篇中，我們提到過，分(fēn)級模型引入了(le)角色間繼承關系，分(fēn)爲一般繼承和(hé)受限繼承。

一般繼承關系隻要求角色繼承關系爲絕對(duì)偏序關系，允許角色間的(de)多(duō)繼承。這(zhè)裏絕對(duì)偏序關系是指角色間繼承關系爲非閉環。而受限繼承進一步要求角色繼承關系爲樹結構。

基于RBAC1進行權限的(de)設計，相比RBAC0，需要設計角色間層級關系和(hé)角色間繼承關系。RBAC1兩種繼承關系的(de)差别主要爲繼承關系的(de)不同，詳見第二步中的(de)角色繼承關系圖。

第一步，抽取業務角色，确定角色和(hé)用(yòng)戶間關系；

同故事1不同，因爲要求角色間有明(míng)顯的(de)層級關系，所以在沒有其他(tā)需求的(de)情況下(xià)，此故事背景下(xià)根據業務部門和(hé)崗位進行角色的(de)抽取，見表2.2.1；

第二步，确定角色之間的(de)層級關系和(hé)繼承關系；

我們使用(yòng)樹形和(hé)非閉環網圖來(lái)表示角色之間的(de)層級關系，見圖2.2.1、圖2.2.2和(hé)圖2.2.3；

第三步，進行原型草(cǎo)圖的(de)設計；

草(cǎo)圖包括增加角色、增加人(rén)員(yuán)和(hé)角色管理(lǐ)。見圖2.2.4；

表2.2.1 角色用(yòng)戶對(duì)應關系

圖 2.2.1 角色層級關系

圖2.2.2 一般繼承關系

圖2.2.3 受限繼承關系

圖2.2.4 添加角色和(hé)人(rén)員(yuán)

圖2.2.5 角色管理(lǐ)

說明(míng)：

1. 本故事中沒有對(duì)各個(gè)角色的(de)用(yòng)例進行描述，但是通(tōng)過表2.2.1，大(dà)家可(kě)以自行腦(nǎo)補。

2. 一般繼承關系和(hé)受限繼承關系的(de)區(qū)别主要在角色間的(de)關系；見圖2.2.2中的(de)紅色線條；

3. 上級角色可(kě)以繼承多(duō)個(gè)下(xià)級角色的(de)權限，上級角色的(de)權限爲所有繼承角色的(de)權限的(de)疊加；

4. 角色間的(de)繼承關系可(kě)能會和(hé)現實中的(de)有所差異，現實中不會出現運營角色繼承人(rén)力角色的(de)權限情況；

5. 可(kě)能會遇到的(de)問題：由于低級角色的(de)權限全部被高(gāo)級角色繼承，就會導緻沒有自己角色的(de)私有權限；處理(lǐ)方式會在第三篇常見問題彙總進行說明(míng)。

3. 角色限制模型：RABC2
故事3：中午吃(chī)飯，同事跟我說，由于公司現在組織結構問題，他(tā)們組很多(duō)人(rén)有多(duō)個(gè)角色，但是由于現在我們隻能設置一個(gè)角色，所以他(tā)們在工作中需要切換多(duō)個(gè)賬号，很不方便。

這(zhè)種場(chǎng)景下(xià)，可(kě)以使用(yòng)角色限制模型。在理(lǐ)論篇中我們講過，角色限制模型跟基本模型相比，用(yòng)戶和(hé)角色爲多(duō)對(duì)多(duō)的(de)關系，如果采用(yòng)責任分(fēn)離模型，則需要定義角色和(hé)角色間的(de)互斥關系，也(yě)就是約束規則。

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

第一步，抽取業務角色，确定角色和(hé)用(yòng)戶間關系；

在本故事中，爲了(le)表明(míng)角色間的(de)互斥，引入全能型員(yuán)工用(yòng)戶9，角色爲行政主管、人(rén)力主管和(hé)運營主管。

采用(yòng)故事2中的(de)方法對(duì)角色進行抽取，并确定角色間的(de)互斥關系，見表2.3.1；

第二步，進行原型草(cǎo)圖設計；

包括增加角色、增加人(rén)員(yuán)和(hé)角色管理(lǐ)，以及多(duō)角色用(yòng)戶登錄時(shí)，對(duì)角色的(de)處理(lǐ)。見圖2.3.1、圖2.3.2、圖2.3.3；

表2.3.1 角色間關系

圖2.3.1 增加角色和(hé)人(rén)員(yuán)

圖2.3.2 角色管理(lǐ)

圖2.3.3 用(yòng)戶選擇操作角色

說明(míng)：

1. 當采用(yòng)靜态分(fēn)離時(shí)，互斥的(de)角色不能同時(shí)被賦予同一個(gè)用(yòng)戶；

2. 動态分(fēn)離時(shí)，則用(yòng)戶登錄後需要選擇使用(yòng)的(de)角色，同時(shí)要支持根據需要切換角色；

4. 統一模型：RABC3

統一模型是包括了(le)繼承和(hé)分(fēn)離兩種情況的(de)更爲複雜(zá)的(de)模型，即既要定義角色間的(de)的(de)繼承關系，也(yě)要維護好角色間的(de)責任分(fēn)離關系。

在這(zhè)裏就不做(zuò)過多(duō)的(de)贅述，因爲隻要維護好了(le)角色間的(de)約束關系，其他(tā)規則類的(de)處理(lǐ)方式同RABC1和(hé)RABC2。

由于此模型相對(duì)來(lái)講較爲複雜(zá)，對(duì)于一般的(de)系統，前三種就可(kě)以滿足需求，不建議(yì)也(yě)沒必要使用(yòng)此種模型。

總結：實戰采用(yòng)了(le)三個(gè)故事，對(duì)基于角色的(de)權限控制進行了(le)描述，包括RBAC0、RBAC1、RBAC2，由于RBAC3爲1和(hé)2的(de)集合，并且在實際工作中，使用(yòng)場(chǎng)景比較少，所以沒有進行詳細說明(míng)。萬變不離其宗，隻要掌握了(le)基于角色的(de)權限控制的(de)基礎理(lǐ)論，根據産品的(de)需求進行設計即可(kě)，也(yě)不必強制性的(de)生搬硬套模型，下(xià)面會對(duì)一些常見的(de)問題進行彙總，包括角色數據權限的(de)處理(lǐ)等。

五、常見的(de)問題彙總
問題1：用(yòng)戶、角色和(hé)權限的(de)關系，以及如何處理(lǐ)多(duō)角色時(shí)的(de)權限？

角色和(hé)權限爲多(duō)對(duì)多(duō)的(de)關系是毋庸置疑的(de)。對(duì)于用(yòng)戶和(hé)角色的(de)關系，在實戰篇中，不同的(de)對(duì)應關系并不一樣，但是設計時(shí)用(yòng)戶、角色最好設計爲多(duō)對(duì)多(duō)的(de)關系。

當用(yòng)戶和(hé)角色爲多(duō)對(duì)多(duō)的(de)關系時(shí)，我們就需要考慮多(duō)個(gè)角色時(shí)，權限如何處理(lǐ)，根據業務需求，需要定義角色和(hé)角色、權限和(hé)權限之間的(de)關系，定義好關系後，根據約束規則進行處理(lǐ)。

問題2：在RBAC1模型中，由于高(gāo)一級的(de)角色繼承了(le)低一級角色的(de)所有權限，會導緻低一級的(de)角色沒有自己的(de)私有權限。

在有繼承關系的(de)角色權限模型中，如果高(gāo)一級的(de)角色繼承了(le)低一級的(de)所有權限，就會導緻低一級的(de)角色沒有自己的(de)私有權限，這(zhè)一點和(hé)實際的(de)業務會存在不符合的(de)情況。針對(duì)這(zhè)一點的(de)解決辦法有：

1）引入私有角色，這(zhè)種辦法會導緻角色數量變多(duō)，提升了(le)角色管理(lǐ)的(de)複雜(zá)性；

2）引入私有權限和(hé)公有權限，私有權限不允許繼承，公有權限允許繼承。不同的(de)業務中對(duì)公有和(hé)私有的(de)定義會有所不同，如傳播深度N；公有、私有和(hé)特征，權限是否可(kě)被繼承，根據繼承方式确定，繼承方式包括一般繼承、公有化(huà)繼承、私有化(huà)繼承和(hé)無特征繼承等。

問題3：角色數據權限如何控制？

作爲ToB或者平台類産品，除了(le)功能權限，最爲頭疼的(de)就是數據權限。實際業務中，相同的(de)角色在同一功能下(xià)的(de)數據權限是不同的(de)，比如同爲代理(lǐ)商角色，代理(lǐ)商A作爲華南(nán)區(qū)的(de)代理(lǐ)商，在客戶管理(lǐ)時(shí)，隻能查看華南(nán)區(qū)的(de)；同理(lǐ)代理(lǐ)商B作爲華中區(qū)的(de)代理(lǐ)商，在客戶管理(lǐ)處，則隻能查看華中的(de)。

針對(duì)這(zhè)種情況，需要對(duì)數據權限進行控制。針對(duì)數據權限的(de)控制，可(kě)以在設置角色權限時(shí)進行控制，如果沒有對(duì)數據權限進行控制，則默認爲所有的(de)數據。

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

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

講到交互層，就不得(de)不講用(yòng)戶體驗，權限設計也(yě)是如此。在保證一定擴展性的(de)基礎上考慮用(yòng)戶體驗。

平台類或者内部産品，雖然設計宗旨不同，但是也(yě)得(de)讓我們的(de)用(yòng)戶用(yòng)著(zhe)爽不是。

在做(zuò)功能權限時(shí)，有時(shí)候開發會說，你這(zhè)個(gè)設計方案不存在無限擴展的(de)可(kě)能性啊，我們後期可(kě)能存在重新做(zuò)的(de)風險啊。

如果這(zhè)個(gè)方案指的(de)是業務層面，那可(kě)能是真的(de)存在問題，這(zhè)個(gè)時(shí)候需要和(hé)研發好好溝通(tōng)一番。但如果是指交互方案，那這(zhè)個(gè)時(shí)候我們是可(kě)以堅持自己的(de)，因爲交互方案肯定是結合産品現狀、後期的(de)規劃發展以及用(yòng)戶的(de)使用(yòng)習(xí)慣，在保證用(yòng)戶體驗的(de)基礎上輸出的(de)。

雖然前端對(duì)數據的(de)解讀方式一定程度上依賴于交互方案，但是講到健壯性和(hé)擴展性，改動起來(lái)的(de)難易程度也(yě)是另外一個(gè)維度的(de)度量方式，不是嗎？

問題5：權限設置完成後，相應的(de)菜單和(hé)功能的(de)狀态如何處理(lǐ)。

這(zhè)個(gè)問題主要是指功能權限設置完成後，對(duì)應的(de)菜單和(hé)功能的(de)入口狀态如何處理(lǐ)。一般有兩種處理(lǐ)方式：

第一種：顯示，點擊時(shí)告知用(yòng)戶是否有此權限；

第二種：根據權限設置，沒有權限直接不予顯示。

問題6：是否有必要設置默認賬号和(hé)默認權限。

對(duì)于ToB類或者平台類的(de)産品，正常來(lái)講都會有一個(gè)默認的(de)超級管理(lǐ)員(yuán)的(de)角色以及角色對(duì)應的(de)賬号，否則系統内第一個(gè)角色誰來(lái)添加？

默認權限的(de)設置則根據需要進行設置，如果是不必要進行控制的(de)權限，當然是可(kě)以設置爲默認權限的(de)。