前言
工作中做過一些許可權管理的產品，每次都有總結，但每次收穫又有不同，都有新的理解。經過經驗的積累，知識的豐富，慢慢的發現主流的許可權管理系統都是RBAC模型（Role-Based Access Control 基於角色的訪問控制）的變形和運用，只是根據不同的業務和設計方案，呈現不同的顯示效果。本文主要從以下幾個方面進行整理說明：RBAC模型的解讀與說明、角色許可權系統實例分析、設計角色許可權系統時的幾條建議。
一、RBAC模型的解讀與說明
1.1 角色許可權系統的理解
說明RBAC模型之前，問我們自己一個問題，為什麼我們要做角色許可權系統？角色許可權系統最終能實現哪些效果？一個很明顯的答案就是平台存在不同許可權的用戶，業務要求不同人應該使用不同的功能、查看不同的內容。這個答案中就包含了，角色許可權系統的最重要幾個元素：用戶----角色----許可權。
是不是所有平台都需要建立角色許可權系統呢，是不是所有角色許可權系統給規律都一樣呢。答案肯定是否定的，但是所有的角色許可權系統有據可依只是一定。接下來我們就介紹下，角色許可權系統中重要一個基礎內容——RBAC模型。
1.2 RBAC模型是如何承載角色許可權系統
RBAC全稱是基於角色的訪問控制。角色是這個模型核心，角色往前可以和用戶關聯，讓用戶擁有角色屬性；角色往後可以和許可權關聯，讓許可權有個歸類代表。它們之間的關係如「圖1.1用戶角色許可權關係表」所示
圖1.1 用戶-角色-許可權關係表
通過上圖有人會問為什麼不直接給用戶分配許可權呢，為什麼要有角色這一環節。其實圖中角色表達的是傳遞的意思，也就是說可以通過角色來關聯用戶和許可權，同時也可以，直接給用戶配許可權。只是直接給用戶配許可權，少了一層關係，擴展性就弱了一些，比較適合那些角色類型少的平台。具體案例後文有具體說明。
當用戶基數很少時，我們可以直接給相應用戶指定相應角色；當平台角色類型很少時，我們也可以直接在角色上掛靠用戶。但是當平台用戶基數增大，角色類型增多時，如果直接給用戶配角色，管理員的工作量就會很大。這時候我們可以引入一個概念「用戶組」，就是將相同屬性的用戶歸類到一起。具體關係如「圖1.2 用戶組-用戶關係表」所示。
圖1.2 用戶組-用戶關係表
如何理解相同用戶屬性的用戶屬於一個用戶組，這裡的用戶屬性是什麼意思。其實這裡的相同用戶屬性是一個泛詞，就是同一部門、同一項目組、同一崗位等等這些信息。具體如何歸類，就看具體業務需求是如何規定的。具體的歸類方法，後面案例給了幾個方式。
有了用戶組，我們就可以直接給用戶組配置許可權，這樣整個用戶組的用戶就擁有了相應的許可權。
圖中還有兩個關鍵詞「（用戶--用戶組）對應關係」和」（用戶組--角色）對應關係「。在這裡就先解釋一下。「（用戶--用戶組）對應關係」就是說，用戶按照性別，按照地區，按照部門，按照崗位，按工作內容，或者按照職權等等組合在一起。「（用戶組--角色）對應關係」就是給用戶組配角色，但是這裡要注意，一個用戶組可以有多個角色（比如張小明、王小剛、李小紅既是用戶體驗部的成員，同時又是項目A的交互設計師）。
有了用戶，有了角色，那許可權我們又如何理解呢。詳情見「圖1.3 用戶-角色-許可權關係表」。
圖1.3 用戶-角色-許可權關係表
許可權是資源的集合。這裡的資源指的是軟體中所有的頁面、模塊、標籤、文件、功能、欄位等等。具體的許可權配置上，目前有多種分類方式，有的人按照功能類、數據類、欄位類進行分類整理；有的人就直接把頁面、標籤這些直接當成許可權詳情進行配置。不管哪種方式，都是將軟體許可權根絕業務需求進行分類。
以上是我根據自己的工作經驗對RBAC模型的理解。這是一種比較通用、詳細的規劃思路，但是不同的產品，不同的平台的業務需求不同，對許可權系統的需求度也不一樣。在設計時，根據自己的業務特點進行篩減、整合。
二、角色許可權系統實例分析
目前大多數B端產品都會建立比較複雜的角色分類，從而滿足自身平台業務所需。在B端產品的角色許可權系統中，每個用戶至少扮演一個角色，每個角色至少具備一種許可權；兩個完全不同的角色可以分配完全相同的許可權；角色之間、用戶之間、許可權之間可能都存從屬關係和並列關係。用戶和角色之間是多對多的關係，角色和許可權也是多對多的關係。所以說理解RBAC模型只是基礎，重要的還要結合具體業務進行設計，下面將介紹三個項目實例來說明用戶、角色、許可權之間的變化關係。
2.1 某工程類項目管理平台。（由於項目本身是內部軟體運行，所以會迴避一些關鍵詞）
項目背景說明：
整個平台是提供一套完整的工程項目現場管理的解決方案。
- 許可權劃分方式多樣，變化性強：在平台，上一個公司可以同時承接多個項目，一個項目內同時又有多個公司，而這些公司之間又沒有必然的聯繫。公司甲和公司乙在項目A中存在上下級關係，而在項目B中可能又是同級關係。
- 角色類型多樣：在整個平台中，角色類型既有平台級的，同時也有公司級的，項目級。在具體的業務事件上，又有不同的角色類型。
解決方案：
通過上面的描述，我們簡單有一個初步認知，下面我們針對業務特點，我們做簡要分析，如「圖2.1 項目管理平台角色用戶分析表」所示。
圖2.1 項目管理平台角色用戶分析表
如圖中所寫的那樣，我們在設計許可權系統時候，要更加註重系統的擴展性，兼容性。在具體設計時，將平台的角色許可權系統分為系統級許可權系統、企業級許可權系統、項目級許可權系統、用戶級許可權系統。接下來具體說明下項目級角色許可權系統。其他子系統邏輯相似。
用戶管理
說明：
1、將項目中，各個公司人員分開管理，構成整個項目的用戶表；
2、此處僅僅是對用戶信息的增刪改查；
3、按照組織機構、崗位將用戶進行分類。讓用戶擁有現實中的崗位信息和組織機構信息。
4、可查看用戶信息。用戶信息分為賬號信息、登錄信息、個人基本信息、職位信息。
角色
該平台中的角色許可權系統的關鍵點就是如何將角色定義好， 角色是許可權集合和用戶集合的綜合體， 而在實際工作中，一個崗位，一個組織機構都有自己的規定的工作內容，不同的工作內容對應不用許可權，所以將用戶現實中擁有的身份（崗位、組織機構）當作角色的一種類型，這樣就很自然的將用戶實際工作與角色許可權系統整合在一起。
但是，用這種邏輯設計角色許可權系統時，應滿足兩個條件。第一、公司組織機構職權和許可權劃分相同。（說明：一個軟體開發的公司引入了一個項目管理軟體，這時候就不能直接用組織機構當角色，因為在組織機構中會計這種崗位在項目管理軟體上沒有許可權。但是如果是引入一個OA軟體，就可以直接可以把組織機構當成角色的一種）；第二、崗位與崗位之間、組織機構與組織機構之間有明顯的職權區分。因為職權太過於相似，也沒有必要用組織機構做角色，這樣反而會增加使用負擔。（說明：例如企業微信除了一些管理員外，大多數都是普通用戶）
將組織機構當成一種角色，給部門配許可權，部門中的人就用於了相應許可權。操作頁面如「圖2.2組織機構配許可權」所示（圖中是組織機構，崗位類似）
圖2.2組織機構配許可權
看到這裡有人就有疑問，給部門整體配許可權是不是部門負責人和員工一樣的許可權，在許可權上就沒有區分度了。其實這也是該平台設計的特色。除了組織機構配權外，還有崗位配權，作為具體一個部門的部門經理就可以配適合他的許可權。而在組織機構出，只配置適合整個部門的許可權。這樣做靈活性就高了很多，方面後期調整擴展。另外，如果要實現某些具體的上下級許可權關係也不僅僅都要通過許可權來實現，該平台的一些業務上使用的工作流引擎，指定不同的角色就可以實現任務的流轉，完全可以實現不同人做不同許可權的事，同時也避免角色之間的互斥（一個人既是申報人又是審批人）。還有很多其他業務設計流程，與角色許可權系統相輔相成共同實現平台運作。
除了這種具體身份的角色外，平台還有系統角色，比如，系統安全管理員，項目超級管理員等等，這些角色都可以直接配給用戶。
許可權
前面也說過，許可權是資源的集合。該系統的做法是將所有應用的頁面、模塊、功能、欄位都作為一種資源類型，進行統一許可權管理。詳細頁面就不貼了，這裡說明下，由於改平台需要進行許可權管理的應用模塊多，所以在將許可權配個角色前，先將許可權做了分類，增加了一層配置。也就是說，將資源構成一些列的小許可權，然後在將小許可權合成大許可權，形成一個許可權樹結果，然後，不同角色從樹上找適合自己的許可權。
總結：
該平台中，角色許可權系統關係圖如圖2.3所示
圖2.3工程管理項目用戶-角色-許可權關係圖
2.2 禪道
背景說明：
禪道是一個可以進行項目管理、產品管理、文件管理的軟體。接下來就簡單分析下禪道的角色許可權系統。
解決方案：
禪道是一個項目管理軟體，對於一個軟體公司，也只有和軟體相關的人會使用，所以簡單分析下禪道用戶和角色的特點，如「圖2.4禪道角色用戶分析表」所示
圖2.4禪道角色用戶分析表
用戶：
禪道是一個項目管理 軟體，所以平台上的用戶更多的是項目相關的用戶，和企業自身的組織機構，沒有一一對應關係。並且此處的用戶只需要做用戶信息的基礎管理即可。
用戶列表圖
圖2.5禪道用戶列表
角色：
項目定位清晰，業務流程明確，有自身完整一套規範的使用流程，所以在角色設定上，主要是按目的進行角色設置。
用戶屬性，按照目的將用戶分成不同的用戶組，代表一種角色。
許可權屬性，根據業務針對每一種角色進行配置。
禪道的角色許可權目的明確，軟體本身結構簡單，都做在一個頁面上。
圖2.6禪道角色許可權管理表
許可權：
該系統許可權數量不是太多，所以直接將資源配置在角色上。
圖2.7禪道許可權配置表
總結：
該平台，把用戶組管理和許可權管理整合在一起。關係圖如下所示；
圖2.7禪道用戶角色許可權關係圖
2.3 某某CRM系統
此系統中，對角色劃分需求度更低，只需要區分出管理員和普通用戶即可，沒有複雜的用戶關係。
圖2.8某系統許可權配置圖
該系統，由於角色類型說，軟體本身是輔助性軟體，所以直接對用戶進行許可權配置。關係圖如下所示；
圖2.9某系統禪道用戶角色許可權關係圖
三、設計角色許可權系統時的幾條建議
上面列舉的三個角色許可權實例都是基於RBAC模型。三個案例由繁至簡，結合不同的業務需求，進行模式調整。儘管樣式不同，但萬變不離其宗，理解清楚RBAC模型后，結合自己的業務就可以設計出一套符合自己平台需求的角色許可權系統。
上面三個案例比較有代表性，可以結合參考。但同時，自己設計時一定要先理清「2個關係3個多少」
1、用戶與用戶之間的關係。用戶有哪些？他們的身份是什麼？他們的關係又是怎樣？他們做的事有什麼不同？用戶之間有哪些不同的屬性；
2、用戶與角色之間的關係。是怎樣的對應關係，業務上需要哪類角色？角色間有什麼差異？角色間是否有交叉和從屬關係？
4、用戶量多少。
5、角色類型多少。
6、需要進行許可權控制的應用有多少。哪些頁面，哪些功能，哪些數據需要進行許可權控制。
後續
以上是自己主導過，或者使用過的系統平台。根據自己的理解給出的一套解讀方案。有不足之處，希望大家多多交流。
自己在工作中有些許總結。最近準備將零散的總結整合到一起，分享出來，大家一起討論下，互相溝通。主要分為，設計技能、業務技能、思考分享、其他幾個維度。
