文章為作者基于自身的工作總結(jié)，希望能夠給你帶來一些啟發(fā)與思考

工作中做過一些權(quán)限管理的產(chǎn)品，每次都有總結(jié)，但每次收獲又有不同，都有新的理解。

經(jīng)過經(jīng)驗的積累，知識的豐富，慢慢的發(fā)現(xiàn)主流的權(quán)限管理系統(tǒng)都是RBAC模型（Role-Based Access Control 基于角色的訪問控制）的變形和運(yùn)用，只是根據(jù)不同的業(yè)務(wù)和設(shè)計方案，呈現(xiàn)不同的顯示效果。

本文主要從以下幾個方面進(jìn)行整理說明：RBAC模型的解讀與說明、角色權(quán)限系統(tǒng)實例分析、設(shè)計角色權(quán)限系統(tǒng)時的幾條建議。

一、RBAC模型的解讀與說明

1.1? 角色權(quán)限系統(tǒng)的理解

說明RBAC模型之前，問我們自己一個問題，為什么我們要做角色權(quán)限系統(tǒng)？角色權(quán)限系統(tǒng)最終能實現(xiàn)哪些效果？一個很明顯的答案就是平臺存在不同權(quán)限的用戶，根據(jù)業(yè)務(wù)要求不同人應(yīng)該使用不同的功能、查看不同的內(nèi)容。這個答案中就包含了，角色權(quán)限系統(tǒng)的最重要幾個元素：用戶—-角色—-權(quán)限。

是不是所有平臺都需要建立角色權(quán)限系統(tǒng)呢，是不是所有角色權(quán)限系統(tǒng)給規(guī)律都一樣呢。答案肯定是否定的，但是所有的角色權(quán)限系統(tǒng)有據(jù)可依只是一定。接下來我們就介紹下，角色權(quán)限系統(tǒng)中重要一個基礎(chǔ)內(nèi)容——RBAC模型。

??1.2? RBAC模型是如何承載角色權(quán)限系統(tǒng)

RBAC全稱是基于角色的訪問控制。角色是這個模型核心，角色往前可以和用戶關(guān)聯(lián)，讓用戶擁有角色屬性；角色往后可以和權(quán)限關(guān)聯(lián)，讓權(quán)限有個歸類代表。它們之間的關(guān)系如“圖1.1用戶角色權(quán)限關(guān)系表”所示

圖1.1? 用戶-角色-權(quán)限關(guān)系表

通過上圖有人會問為什么不直接給用戶分配權(quán)限呢，為什么要有角色這一環(huán)節(jié)。其實圖中角色表達(dá)的是傳遞的意思，也就是說可以通過角色來關(guān)聯(lián)用戶和權(quán)限，同時也可以，直接給用戶配權(quán)限。只是直接給用戶配權(quán)限，少了一層關(guān)系，擴(kuò)展性就弱了一些，比較適合那些角色類型少的平臺。具體案例后文有具體說明。

當(dāng)用戶基數(shù)很少時，我們可以直接給相應(yīng)用戶指定相應(yīng)角色；當(dāng)平臺角色類型很少時，我們也可以直接在角色上掛靠用戶。但是當(dāng)平臺用戶基數(shù)增大，角色類型增多時，如果直接給用戶配角色，管理員的工作量就會很大。這時候我們可以引入一個概念“用戶組”，就是將相同屬性的用戶歸類到一起。具體關(guān)系如“圖1.2 用戶組-用戶關(guān)系表”所示。

圖1.2 用戶組-用戶關(guān)系表

如何理解相同用戶屬性的用戶屬于一個用戶組，這里的用戶屬性是什么意思。其實這里的相同用戶屬性是一個泛詞，就是同一部門、同一項目組、同一崗位等等這些信息。具體如何歸類，就看具體業(yè)務(wù)需求是如何規(guī)定的。具體的歸類方法，后面案例給了幾個方式。

有了用戶組，我們就可以直接給用戶組配置權(quán)限，這樣整個用戶組的用戶就擁有了相應(yīng)的權(quán)限。

圖1.2中還有兩個關(guān)鍵詞“（用戶–用戶組）對應(yīng)關(guān)系”和”（用戶組–角色）對應(yīng)關(guān)系“。在這里就先解釋一下?！埃ㄓ脩?#8211;用戶組）對應(yīng)關(guān)系”就是說，用戶按照性別，按照地區(qū)，按照部門，按照崗位，按工作內(nèi)容，或者按照職權(quán)等等組合在一起。“（用戶組–角色）對應(yīng)關(guān)系”就是給用戶組配角色，但是這里要注意，一個用戶組可以有多個角色（比如張小明、王小剛、李小紅既是用戶體驗部的成員，同時又是項目A的交互設(shè)計師）。

上面解釋了用戶和角色，那權(quán)限我們又如何理解呢。詳情見“圖1.3 用戶-角色-權(quán)限關(guān)系表”。

圖1.3 用戶-角色-權(quán)限關(guān)系表

權(quán)限是資源的集合。這里的資源指的是軟件中所有的頁面、模塊、標(biāo)簽、文件、功能、字段等等。具體的權(quán)限配置上，目前有多種分類方式，有的人按照功能類、數(shù)據(jù)類、字段類進(jìn)行分類整理；有的人就直接把頁面、標(biāo)簽這些直接當(dāng)成權(quán)限詳情進(jìn)行配置。不管哪種方式，都是將軟件權(quán)限根絕業(yè)務(wù)需求進(jìn)行分類。

以上是我根據(jù)自己的工作經(jīng)驗對RBAC模型的理解。這是一種比較通用、詳細(xì)的規(guī)劃思路，但是不同的產(chǎn)品，不同的平臺的業(yè)務(wù)需求不同，對權(quán)限系統(tǒng)的需求度也不一樣。在設(shè)計時，根據(jù)自己的業(yè)務(wù)特點(diǎn)進(jìn)行篩減、整合。

二、角色權(quán)限系統(tǒng)實例分析

目前大多數(shù)B端產(chǎn)品都會建立比較復(fù)雜的角色分類，從而滿足自身平臺業(yè)務(wù)所需。在B端產(chǎn)品的角色權(quán)限系統(tǒng)中，每個用戶至少扮演一個角色，每個角色至少具備一種權(quán)限；兩個完全不同的角色可以分配完全相同的權(quán)限；角色之間、用戶之間、權(quán)限之間可能都存從屬關(guān)系和并列關(guān)系。用戶和角色之間是多對多的關(guān)系，角色和權(quán)限也是多對多的關(guān)系。所以說理解RBAC模型只是基礎(chǔ)，重要的還要結(jié)合具體業(yè)務(wù)進(jìn)行設(shè)計，下面將介紹三個項目實例來說明用戶、角色、權(quán)限之間的變化關(guān)系。

?2.1 某工程類項目管理平臺。（由于項目本身是內(nèi)部軟件，所以會回避一些關(guān)鍵詞）

項目背景說明：

整個平臺是提供一套完整的工程項目現(xiàn)場管理的解決方案。

• ?權(quán)限劃分方式多樣，變化性強(qiáng)：在平臺上，一個公司可以同時承接多個項目，一個項目內(nèi)同時又有多個公司，而這些公司之間又沒有必然的聯(lián)系。公司甲和公司乙在項目A中存在上下級關(guān)系，而在項目B中可能又是同級關(guān)系。
• 角色類型多樣：在整個平臺中，角色類型既有平臺級的，同時也有公司級的，項目級。在具體的業(yè)務(wù)事件上，又有不同的角色類型。

解決方案：

通過上面的描述，我們簡單有一個初步認(rèn)知，下面我們針對業(yè)務(wù)特點(diǎn)，我們做具體分析，如“圖2.1 項目管理平臺角色用戶分析表”所示。

圖2.1 項目管理平臺角色用戶分析表

如圖2.1中所寫的那樣，我們在設(shè)計權(quán)限系統(tǒng)時候，要更加注重系統(tǒng)的擴(kuò)展性，兼容性。在具體設(shè)計時，將平臺的角色權(quán)限系統(tǒng)分為系統(tǒng)級權(quán)限系統(tǒng)、企業(yè)級權(quán)限系統(tǒng)、項目級權(quán)限系統(tǒng)、用戶級權(quán)限系統(tǒng)。接下來具體說明下項目級角色權(quán)限系統(tǒng)。其他子系統(tǒng)邏輯相似。

用戶管理

圖2.2 用戶管理表

說明：

1. 將項目中，各個公司人員分開管理，構(gòu)成整個項目的用戶表；
2. 此處僅僅是對用戶信息的增刪改查；
3. 按照組織機(jī)構(gòu)、崗位將用戶進(jìn)行分類。讓用戶擁有現(xiàn)實中的崗位信息和組織機(jī)構(gòu)信息。
   
4. 可查看用戶信息。用戶信息分為賬號信息、登錄信息、個人基本信息、職位信息。

角色

該平臺中的角色權(quán)限系統(tǒng)的關(guān)鍵點(diǎn)就是如何將角色定義好， 角色是權(quán)限集合和用戶集合的綜合體， 而在實際工作中，一個崗位，一個組織機(jī)構(gòu)都有自己的規(guī)定的工作內(nèi)容，不同的工作內(nèi)容對應(yīng)不用權(quán)限，所以將用戶現(xiàn)實中擁有的身份（崗位、組織機(jī)構(gòu)）當(dāng)作角色的一種類型，這樣就很自然的將用戶實際工作與角色權(quán)限系統(tǒng)整合在一起。

但是，使用這種邏輯設(shè)計角色權(quán)限系統(tǒng)時，應(yīng)滿足兩個條件。

• 第一、公司組織機(jī)構(gòu)職權(quán)和權(quán)限劃分相同。（說明：一個軟件開發(fā)的公司引入了一個項目管理軟件，這時候就不能直接用組織機(jī)構(gòu)當(dāng)角色，因為在組織機(jī)構(gòu)中會計這種崗位在項目管理軟件上沒有權(quán)限。但是如果是引入一個OA軟件，就可以直接可以把組織機(jī)構(gòu)當(dāng)成角色的一種）；
• 第二、崗位與崗位之間、組織機(jī)構(gòu)與組織機(jī)構(gòu)之間有明顯的職權(quán)區(qū)分。因為職權(quán)太過于相似，也沒有必要用組織機(jī)構(gòu)做角色，這樣反而會增加使用負(fù)擔(dān)。（說明：例如企業(yè)微信除了一些管理員外，大多數(shù)都是普通用戶）

將組織機(jī)構(gòu)當(dāng)成一種角色，給部門配權(quán)限，部門中的人就用于了相應(yīng)權(quán)限。操作頁面如“圖2.2組織機(jī)構(gòu)配權(quán)限”所示（圖中是組織機(jī)構(gòu)，崗位類似）

圖2.3組織機(jī)構(gòu)配權(quán)限

看到這里有人就有疑問，給部門整體配權(quán)限是不是部門負(fù)責(zé)人和員工一樣的權(quán)限，在權(quán)限上就沒有區(qū)分度了。其實這也是該平臺設(shè)計的特色。除了組織機(jī)構(gòu)配權(quán)外，還有崗位配權(quán)，作為具體一個部門的部門經(jīng)理就可以配適合他的權(quán)限。而在組織機(jī)構(gòu)出，只配置適合整個部門的權(quán)限。這樣做靈活性就高了很多，方面后期調(diào)整擴(kuò)展。

另外，如果要實現(xiàn)某些具體的上下級權(quán)限關(guān)系也不僅僅都要通過權(quán)限來實現(xiàn)，該平臺的一些業(yè)務(wù)上使用的工作流引擎，指定不同的角色就可以實現(xiàn)任務(wù)的流轉(zhuǎn)，完全可以實現(xiàn)不同人做不同權(quán)限的事，同時也避免角色之間的互斥（一個人既是申報人又是審批人）。還有很多其他業(yè)務(wù)設(shè)計流程，與角色權(quán)限系統(tǒng)相輔相成共同實現(xiàn)平臺運(yùn)作。

除了這種具體身份的角色外，平臺還有系統(tǒng)角色，比如，系統(tǒng)安全管理員，項目超級管理員等等，這些角色都可以直接配給用戶。

權(quán)限

前面也說過，權(quán)限是資源的集合。該系統(tǒng)的做法是將所有應(yīng)用的頁面、模塊、功能、字段都作為一種資源類型，進(jìn)行統(tǒng)一權(quán)限管理。詳細(xì)頁面就不貼了，這里說明下，由于改平臺需要進(jìn)行權(quán)限管理的應(yīng)用模塊多，所以在將權(quán)限配個角色前，先將權(quán)限做了分類，增加了一層配置。

也就是說，將資源構(gòu)成一些列的小權(quán)限，然后在將小權(quán)限合成大權(quán)限，形成一個權(quán)限樹結(jié)果，然后，不同角色從樹上找適合自己的權(quán)限。

總結(jié)：

1. 平臺中，將資源歸類成權(quán)限，將權(quán)限配給角色，然后把角色和用戶關(guān)聯(lián)。通過三層權(quán)限管理，盡管略顯復(fù)雜，但是針對大型的平臺軟件來說，其后期的擴(kuò)展和維護(hù)就方便很多；
2. 平臺中，把角色分為組織機(jī)構(gòu)類型、崗位類型、和其他類型，比較符合具體業(yè)務(wù)，分類較為完整。

該平臺中，角色權(quán)限系統(tǒng)關(guān)系圖如圖2.4所示

圖2.4工程管理項目用戶-角色-權(quán)限關(guān)系圖

2.2 禪道

背景說明：

禪道是一個可以進(jìn)行項目管理、產(chǎn)品管理、文件管理的軟件。接下來就簡單分析下禪道的角色權(quán)限系統(tǒng)。

解決方案：

禪道是一個項目管理軟件，對于一個軟件公司，也只有和軟件相關(guān)的人會使用，所以簡單分析下禪道用戶和角色的特點(diǎn)，如“圖2.4禪道角色用戶分析表”所示

圖2.5禪道角色用戶分析表

用戶：

禪道是一個項目管理 軟件，所以平臺上的用戶更多的是項目相關(guān)的用戶，和企業(yè)自身的組織機(jī)構(gòu)，沒有一一對應(yīng)關(guān)系。并且此處的用戶只需要做用戶信息的基礎(chǔ)管理即可。

用戶列表圖

圖2.6禪道用戶列表

角色：

項目定位清晰，業(yè)務(wù)流程明確，有自身完整一套規(guī)范的使用流程，所以在角色設(shè)定上，主要是按目的進(jìn)行角色設(shè)置。

用戶屬性，按照目的將用戶分成不同的用戶組，代表一種角色。

權(quán)限屬性，根據(jù)業(yè)務(wù)針對每一種角色進(jìn)行配置。

禪道的角色權(quán)限目的明確，軟件本身結(jié)構(gòu)簡單，都做在一個頁面上。

圖2.7禪道角色權(quán)限管理表

權(quán)限：

該系統(tǒng)權(quán)限數(shù)量不是太多，所以直接將資源配置在角色上。

圖2.8禪道權(quán)限配置表

總結(jié)：

1. 該平臺所服務(wù)的對象業(yè)務(wù)流程清晰，過程角色可清晰量化（比如軟件開發(fā)中的各個角色“設(shè)計、開發(fā)、測試”）故權(quán)限配置管理上，可按目的進(jìn)行角色定義。
2. 該平臺，用戶量，權(quán)限分層和數(shù)量都較少。

該平臺，把用戶組管理和權(quán)限管理整合在一起。關(guān)系圖如下所示；

圖2.9禪道用戶角色權(quán)限關(guān)系圖

2.3 某某CRM系統(tǒng)

該系統(tǒng)中，對角色劃分需求度更低，只需要區(qū)分出管理員和普通用戶即可，沒有復(fù)雜的用戶關(guān)系。

圖2.10某系統(tǒng)權(quán)限配置圖

該系統(tǒng)，由于角色類型說，軟件本身是輔助性軟件，所以直接對用戶進(jìn)行權(quán)限配置。關(guān)系圖如下所示；

圖2.11某系統(tǒng)禪道用戶角色權(quán)限關(guān)系圖

三、設(shè)計角色權(quán)限系統(tǒng)時的幾條建議

上面列舉的三個角色權(quán)限實例都是基于RBAC模型。三個案例由繁至簡，結(jié)合不同的業(yè)務(wù)需求，進(jìn)行模式調(diào)整。盡管樣式不同，但萬變不離其宗，理解清楚RBAC模型后，結(jié)合自己的業(yè)務(wù)就可以設(shè)計出一套符合自己平臺需求的角色權(quán)限系統(tǒng)。

上面三個案例比較有代表性，可以結(jié)合參考。但同時，自己設(shè)計時一定要先理清“2個關(guān)系3個多少”

1. 用戶與用戶之間的關(guān)系。用戶有哪些？他們的身份是什么？他們的關(guān)系又是怎樣？他們做的事有什么不同？用戶之間有哪些不同的屬性；
2. 用戶與角色之間的關(guān)系。是怎樣的對應(yīng)關(guān)系，業(yè)務(wù)上需要哪類角色？角色間有什么差異？角色間是否有交叉和從屬關(guān)系？
3. 用戶量多少。
4. 角色類型多少。
5. 需要進(jìn)行權(quán)限控制的應(yīng)用有多少。哪些頁面，哪些功能，哪些數(shù)據(jù)需要進(jìn)行權(quán)限控制。

后續(xù)

以上是自己主導(dǎo)過，或者使用過的系統(tǒng)平臺。根據(jù)自己的理解給出的一套解讀方案。有不足之處，希望大家多多交流。

自己在工作中有些許總結(jié)。最近準(zhǔn)備將零散的總結(jié)整合到一起，分享出來，大家一起討論下，互相溝通。主要分為，設(shè)計技能、業(yè)務(wù)技能、思考分享、其他幾個維度。

本文由 @victorcjp 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自PEXELS，基于CC0協(xié)議