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

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

經過經驗的積累，知識的豐富，慢慢的發現主流的權限管理系統都是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中還有兩個關鍵詞“（用戶–用戶組）對應關系”和”（用戶組–角色）對應關系“。在這里就先解釋一下?！埃ㄓ脩?#8211;用戶組）對應關系”就是說，用戶按照性別，按照地區，按照部門，按照崗位，按工作內容，或者按照職權等等組合在一起?！埃ㄓ脩艚M–角色）對應關系”就是給用戶組配角色，但是這里要注意，一個用戶組可以有多個角色（比如張小明、王小剛、李小紅既是用戶體驗部的成員，同時又是項目A的交互設計師）。

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

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

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

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

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

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

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

項目背景說明：

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

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

解決方案：

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

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

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

用戶管理

圖2.2 用戶管理表

說明：

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

角色

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

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

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

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

圖2.3組織機構配權限

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

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

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

權限

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

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

總結：

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

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

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

2.2 禪道

背景說明：

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

解決方案：

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

圖2.5禪道角色用戶分析表

用戶：

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

用戶列表圖

圖2.6禪道用戶列表

角色：

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

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

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

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

圖2.7禪道角色權限管理表

權限：

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

圖2.8禪道權限配置表

總結：

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

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

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

2.3 某某CRM系統

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

圖2.10某系統權限配置圖

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

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

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

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

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

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

后續

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

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

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

題圖來自PEXELS，基于CC0協議