以RBAC模型為基礎，分析B端權限系統的設計思路（業務技能）

文章為作者基於自身的工作總結，希望能夠給你帶來一些啟發與思考

工作中做過一些權限管理的產品，每次都有總結，但每次收穫又有不同，都有新的理解。

經過經驗的積累，知識的豐富，慢慢的發現主流的權限管理系統都是RBAC模型（Role-Based Access Control 基於角色的訪問控制）的變形和運用，只是根據不同的業務和設計方案，呈現不同的顯示效果。

本文主要從以下幾個方面進行整理說明： RBAC模型的解讀與說明、角色權限系統實例分析、設計角色權限系統時的幾條建議 。

一、 RBAC模型的解讀與說明

1.1 角色權限系統的理解

說明RBAC模型之前，問我們自己一個問題，為什麼我們要做角色權限系統？角色權限系統最終能實現哪些效果？一個很明顯的答案就是平台存在不同權限的用戶，根據業務要求不同人應該使用不同的功能、查看不同的內容。這個答案中就包含了，角色權限系統的最重要幾個元素：用戶—-角色—-權限。

是不是所有平台都需要建立角色權限系統呢，是不是所有角色權限系統給規律都一樣呢。答案肯定是否定的，但是所有的角色權限系統有據可依只是一定。接下來我們就介紹下，角色權限系統中重要一個基礎內容——RBAC模型。

1.2 RBAC模型是如何承載角色權限系統

RBAC全稱是基於角色的訪問控制。角色是這個模型核心，角色往前可以和用戶關聯，讓用戶擁有角色屬性；角色往後可以和權限關聯，讓權限有個歸類代表。它們之間的關係如“圖1.1用戶角色權限關係表”所示

圖1.1 用戶-角色-權限關係表

通過上圖有人會問為什麼不直接給用戶分配權限呢，為什麼要有角色這一環節。其實圖中角色表達的是傳遞的意思，也就是說可以通過角色來關聯用戶和權限，同時也可以，直接給用戶配權限。只是直接給用戶配權限，少了一層關係，擴展性就弱了一些，比較適合那些角色類型少的平台。具體案例後文有具體說明。

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

圖1.2 用戶組-用戶關係表

如何理解相同用戶屬性的用戶屬於一個用戶組，這裡的用戶屬性是什麼意思。其實這裡的相同用戶屬性是一個泛詞，就是同一部門、同一項目組、同一崗位等等這些信息。具體如何歸類，就看具體業務需求是如何規定的。具體的歸類方法，後面案例給了幾個方式。

有了用戶組，我們就可以直接給用戶組配置權限，這樣整個用戶組的用戶就擁有了相應的權限。

圖1.2中還有兩個關鍵詞“（用戶–用戶組）對應關係”和”（用戶組–角色）對應關係“。在這裡就先解釋一下。 “（用戶–用戶組）對應關係”就是說，用戶按照性別，按照地區，按照部門，按照崗位，按工作內容，或者按照職權等等組合在一起。 “（用戶組–角色）對應關係”就是給用戶組配角色，但是這裡要注意，一個用戶組可以有多個角色（比如張小明、王小剛、李小紅既是用戶體驗部的成員，同時又是項目A的交互設計師）。

上面解釋了用戶和角色，那權限我們又如何理解呢。詳情見“圖1.3 用戶-角色-權限關係表”。

圖1.3 用戶-角色-權限關係表

權限是資源的集合。這裡的資源指的是軟件中所有的頁面、模塊、標籤、文件、功能、字段等等。具體的權限配置上，目前有多種分類方式，有的人按照功能類、數據類、字段類進行分類整理；有的人就直接把頁面、標籤這些直接當成權限詳情進行配置。不管哪種方式，都是將軟件權限根絕業務需求進行分類。

以上是我根據自己的工作經驗對RBAC模型的理解。這是一種比較通用、詳細的規劃思路，但是不同的產品，不同的平台的業務需求不同，對權限系統的需求度也不一樣。在設計時，根據自己的業務特點進行篩減、整合。

二、角色權限系統實例分析

目前大多數B端產品都會建立比較複雜的角色分類，從而滿足自身平台業務所需。在B端產品的角色權限系統中，每個用戶至少扮演一個角色，每個角色至少具備一種權限；兩個完全不同的角色可以分配完全相同的權限；角色之間、用戶之間、權限之間可能都存從屬關係和並列關係。用戶和角色之間是多對多的關係，角色和權限也是多對多的關係。所以說理解RBAC模型只是基礎，重要的還要結合具體業務進行設計，下面將介紹三個項目實例來說明用戶、角色、權限之間的變化關係。

2.1 某工程類項目管理平台。（由於項目本身是內部軟件，所以會迴避一些關鍵詞）

項目背景說明：

整個平台是提供一套完整的工程項目現場管理的解決方案。

權限劃分方式多樣，變化性強：在平台上，一個公司可以同時承接多個項目，一個項目內同時又有多個公司，而這些公司之間又沒有必然的聯繫。公司甲和公司乙在項目A中存在上下級關係，而在項目B中可能又是同級關係。
角色類型多樣：在整個平台中，角色類型既有平台級的，同時也有公司級的，項目級。在具體的業務事件上，又有不同的角色類型。

解決方案：

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

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

如圖2.1中所寫的那樣，我們在設計權限系統時候，要更加註重系統的擴展性，兼容性。在具體設計時，將平台的角色權限系統分為系統級權限系統、企業級權限系統、項目級權限系統、用戶級權限系統。接下來具體說明下項目級角色權限系統。其他子系統邏輯相似。

用戶管理

圖2.2 用戶管理表

說明：

將項目中，各個公司人員分開管理，構成整個項目的用戶表；
此處僅僅是對用戶信息的增刪改查；
按照組織機構、崗位將用戶進行分類。讓用戶擁有現實中的崗位信息和組織機構信息。
可查看用戶信息。用戶信息分為賬號信息、登錄信息、個人基本信息、職位信息。

角色

該平台中的角色權限系統的關鍵點就是如何將角色定義好，角色是權限集合和用戶集合的綜合體，而在實際工作中，一個崗位，一個組織機構都有自己的規定的工作內容，不同的工作內容對應不用權限， 所以將用戶現實中擁有的身份（崗位、組織機構）當作角色的一種類型，這樣就很自然的將用戶實際工作與角色權限系統整合在一起 。

但是，使用這種邏輯設計角色權限系統時，應滿足兩個條件。

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

將組織機構當成一種角色，給部門配權限，部門中的人就用於了相應權限。操作頁面如“圖2.2組織機構配權限”所示（圖中是組織機構，崗位類似）

圖2.3組織機構配權限

看到這裡有人就有疑問，給部門整體配權限是不是部門負責人和員工一樣的權限，在權限上就沒有區分度了。其實這也是該平台設計的特色。除了組織機構配權外，還有崗位配權，作為具體一個部門的部門經理就可以配適合他的權限。而在組織機構出，只配置適合整個部門的權限。這樣做靈活性就高了很多，方面後期調整擴展。

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

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

權限

前面也說過，權限是資源的集合。該系統的做法是將所有應用的頁面、模塊、功能、字段都作為一種資源類型，進行統一權限管理。詳細頁面就不貼了，這裡說明下，由於改平台需要進行權限管理的應用模塊多，所以在將權限配個角色前，先將權限做了分類，增加了一層配置。

也就是說，將資源構成一些列的小權限，然後在將小權限合成大權限，形成一個權限樹結果，然後，不同角色從樹上找適合自己的權限。

總結：

平台中，將資源歸類成權限，將權限配給角色，然後把角色和用戶關聯。通過三層權限管理，儘管略顯複雜，但是針對大型的平台軟件來說，其後期的擴展和維護就方便很多；
平台中，把角色分為組織機構類型、崗位類型、和其他類型，比較符合具體業務，分類較為完整。

該平台中，角色權限系統關係圖如圖2.4所示

圖2.4工程管理項目用戶-角色-權限關係圖

2.2 禪道

背景說明：

禪道是一個可以進行項目管理、產品管理、文件管理的軟件。接下來就簡單分析下禪道的角色權限系統。

解決方案：

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

圖2.5禪道角色用戶分析表

用戶：

禪道是一個項目管理軟件，所以平台上的用戶更多的是 項目相關的用戶 ，和企業自身的組織機構，沒有一一對應關係。並且此處的用戶只需要做用戶信息的基礎管理即可。

用戶列表圖

圖2.6禪道用戶列表

角色：

項目定位清晰，業務流程明確，有自身完整一套規範的使用流程，所以在角色設定上，主要是按目的進行角色設置。

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

權限屬性，根據業務針對每一種角色進行配置。

禪道的角色權限目的明確，軟件本身結構簡單，都做在一個頁面上。

圖2.7禪道角色權限管理表

權限：

該系統權限數量不是太多，所以直接將資源配置在角色上。

圖2.8禪道權限配置表

總結：

該平台所服務的對象業務流程清晰，過程角色可清晰量化（比如軟件開發中的各個角色“設計、開發、測試”）故權限配置管理上，可按目的進行角色定義。
該平台，用戶量，權限分層和數量都較少。

該平台，把用戶組管理和權限管理整合在一起。關係圖如下所示；

圖2.9禪道用戶角色權限關係圖

2.3 某某CRM系統

該系統中，對角色劃分需求度更低，只需要區分出管理員和普通用戶即可，沒有復雜的用戶關係。

圖2.10某系統權限配置圖

該系統， 由於角色類型說，軟件本身是輔助性軟件，所以直接對用戶進行權限配置。 關係圖如下所示；

圖2.11某系統禪道用戶角色權限關係圖

三、設計角色權限系統時的幾條建議

上面列舉的三個角色權限實例都是基於RBAC模型。三個案例由繁至簡，結合不同的業務需求，進行模式調整。儘管樣式不同，但萬變不離其宗，理解清楚RBAC模型後，結合自己的業務就可以設計出一套符合自己平台需求的角色權限系統。

上面三個案例比較有代表性，可以結合參考。但同時，自己設計時一定要先理清“2個關係3個多少”

用戶與用戶之間的關係。用戶有哪些？他們的身份是什麼？他們的關係又是怎樣？他們做的事有什麼不同？用戶之間有哪些不同的屬性；
用戶與角色之間的關係。是怎樣的對應關係，業務上需要哪類角色？角色間有什麼差異？角色間是否有交叉和從屬關係？
用戶量多少。
角色類型多少。
需要進行權限控制的應用有多少。哪些頁面，哪些功能，哪些數據需要進行權限控制。

後續

以上是自己主導過，或者使用過的系統平台。根據自己的理解給出的一套解讀方案。有不足之處，希望大家多多交流。

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

本文由 @victorcjp 原創發佈於人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基於CC0協議