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

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

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

一、名詞解釋

在開始介紹相關理論之前，先解釋下本文會用到的一些名詞：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 強制訪問控制（MAC）

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

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

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

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

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

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

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

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

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

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

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

三、背景

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

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

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

四、RBAC四個部件

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

1. 基本模型：RBAC0

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

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

第一步，抽取角色，確定用戶和角色的關系；

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

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

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

表2.1.1 用戶、角色的對應關系

圖2.1.1 角色用例圖

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

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

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

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

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

2. 角色分級模型：RBAC1

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

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

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

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

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

同故事1不同，因為要求角色間有明顯的層級關系，所以在沒有其他需求的情況下，此故事背景下根據(jù)業(yè)務部門和崗位進行角色的抽取，見表2.2.1；

第二步，確定角色之間的層級關系和繼承關系；

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

第三步，進行原型草圖的設計；

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

表2.2.1 角色用戶對應關系

圖 2.2.1 角色層級關系

圖2.2.2 一般繼承關系

圖2.2.3 受限繼承關系

圖2.2.4 添加角色和人員

圖2.2.5 角色管理

說明：

1. 本故事中沒有對各個角色的用例進行描述，但是通過表2.2.1，大家可以自行腦補。

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

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

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

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

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

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

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

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

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

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

第二步，進行原型草圖設計；

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

表2.3.1 角色間關系

圖2.3.1 增加角色和人員

圖2.3.2 角色管理

圖2.3.3 用戶選擇操作角色

說明：

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

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

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

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

在這里就不做過多的贅述，因為只要維護好了角色間的約束關系，其他規(guī)則類的處理方式同RABC1和RABC2。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在做功能權(quán)限時，有時候開發(fā)會說，你這個設計方案不存在無限擴展的可能性啊，我們后期可能存在重新做的風險啊。

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

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

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

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

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

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

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

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

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