模型中權限這個元素，按顆粒度從大到小，可以分為： * 導航：由路由控制，是否可以訪問一組頁面 * 頁面：是否可以訪問某個頁面 * 操作：訪問某個頁面時，按鈕是否可以見，可否增刪改查 * 字段：頁面中某個字段是否可見、是否可編輯 如果員工沒有某對象“查看列表”的權限，則該對象的功能入口會被隱藏 如果員工沒有某對象的操作點權限，則在對象頁面上隱藏相應操作按鈕 如果員工沒有某對象的指定字段的可見權限，則在對象頁面上隱藏相應字段 同理如果權限較多時也會存在一樣的問題，處理方式是引入權限組的概念，將使用場景相對固定的一組功能或權限打包成組賦予角色。但是一般來講一個系統中權限功能的體量是相對有限和可控的，所以實際應用中對權限組的使用較少。  **3\. 角色繼承的RBAC模型** 在一個業務場景中，如果角色需區分：設計主管、設計組長、設計成員，并且管理方式為向下兼容時，則需使用角色繼承的 RBAC 模型。上層角色繼承下層角色的全部權限，且可額外賦予權限。  此時除了對角色進行定義，還需要管理角色間的關系，通過關系來體現角色的層級關系，從而達到繼承權限的效果。角色的繼承關系主要有兩種：樹形圖和有向無環圖。  繼承關系常常來源于公司團隊的組織結構，此時常將角色與組織結構進行關聯達到繼承角色模型的效果。如下圖所示的趙同學，其角色是「三級團隊負責人」，與其并列的小組中有多個「三級團隊負責人」的角色，但依附于左側的組織結構樹，各級負責人僅有查看和操作自己下屬子節點的權限。  **4\. 限制的RBAC模型** 在一個產品或系統中，部分角色可能是需要隔離的、不允許被同時賦予一個人的。跟大家熟知的不能既是「運動員」又是「裁判員」一個道理。 因此，對于眾多角色中的一組，只能是單選的關系，但多組角色之間可以共同存在。如下圖中，一個用戶可以既為設計師又為管理員，但在設計師角色組中僅能被賦予一個角色，在管理員角色組中也僅能被賦予一個角色。  此外，限制還有可能是數量上的，比如一個產品組中必須有且只有一個管理員，不允許刪除或再分配管理員角色，僅允許將負責人角色變更。  限制的模型不僅僅對分配過程產生影響，有時即使擁有了多種角色，因為不同的角色對同一個功能的使用方式或數據會產生沖突，所以使用時也需要進行限制。如下圖所示為同一時間僅允許以一個身份登錄。  根據不同的業務需求，限制的形式很多。需要注意的是不能僅依賴后端限制，而是要在前端展示清晰的規則和恰當的限制，避免用戶出錯和沮喪。 #### 三、權限的拆分與設計 通過 RBAC 模型已經能夠很好的搭建起用戶、角色與權限之間的關系了。但具體是什么樣的關系，以及「權限」這個抽象的概念具體如何規劃？ 這些都需要分析清楚才能進一步設計出完善的權限系統。 首先需要知道，一般產品的權限由頁面、操作和數據構成。頁面與操作相互關聯，必須擁有頁面權限，才能分配該頁面下對應的操作權限。數據可被增刪改查。 整體關系如下圖所示：  因此，在設計之初我們就需要考慮到未來可能區分角色的地方，盡量解耦、模塊化。對于技術來說，每一個頁面模塊、每一個操作都最好使用獨立的接口。對于設計來說，需要保障所有角色因為權限而屏蔽掉部分操作和數據后，頁面和流程仍能體驗流暢。 保證初期設計支持后，配置權限時，還需要注意以下幾點： **1\. 確定是否支持前端配置** 如果角色和權限相對固定，則一般將角色與權限的關系可以寫在后臺，改動時需要后端變更且重新上線。這種情況適用于公司內部系統等只有一個使用主體的系統。 如果需要自定義角色或者每個角色在不同使用者的場景下有不同的權限，則需要將角色的定義、角色與權限之間的配置體現在「前端用戶配置頁面」。這種情況適用于有頻繁變動的自定義角色權限，和有租戶體系的系統。 **2\. 以基本單元拆分，以業務邏輯配置** 一般可將每個對象的「增、刪、改、查」各自作為一個基本的權限單元。打個比方，在「人員管理」中，查看人員列表、添加人員、刪除人員、編輯人員信息最好拆分為4個權限單元。在技術和設計上，我們希望能盡量做到解耦和模塊化。 但是在業務層面有些操作卻是一體的。這些不能拆開的權限在「前端用戶配置頁面」中建議打包成一個整體提供配置。例如：如果我們確定在系統的現有和未來業務中，僅分為普通成員有「人員管理」的查看權限，管理員有操作權限，則可將「增、刪、改」三個基本權限單位合并為「操作」權限進行配置。 **3\. 頁面權限優先于操作和數據權限** 必須配置了頁面模塊權限后，才能配置當前頁面模塊下具體的操作權限，以及頁面模塊的數據展示權限。 **4\. 查看權限優先于增刪改權限** 正常情況下，一定要先能查看某個模塊或操作，其它的增刪改操作才有意義。因此在設計時，應在獲取查看權限前限制其它權限的配置，或者配置其它權限時默認賦予查看權限。 **5\. 角色與權限的多種關系** 角色與權限的關系不僅是單純「是/否關系」，還包括以某種限制進行操作，和以某種程度訪問數據。 例如在「人員管理」中： * 數據范圍：用戶擁有查看人員列表的權限，但僅能查看自己所在的團隊； * 數據邊界限制（上限等）：添加人員時不能超過20個等。 * 數據字段：HR 能查看人員列表中包括職級、薪資等字段，其它角色僅能查看姓名郵箱等字段； **6\. 角色與權限的設計表達** 在傳達一個系統的權限設計規則時，設計師常常習慣用主觀最直接的方式表達想法，如用「當……時，就……」的句式來表達。但一個平臺中涉及的權限規則是非常多的，當通篇以這樣的形式描述時，表達對象將很難理解。 正確的描述方式：更清晰的是基于開發的語言，和技術模型的結果進行表達。將各角色與權限單元繪制成網格，每個交叉點網格中描述該角色與權限的數據關系和限制。 如下圖所示：  #### 四、需要注意的Tips **1\. 隱形的admin** 在可自定義角色和權限的系統中，一般需要預留一個 admin 角色來進行系統的初始配置，用于添加首批的業務人員和配置基本的角色。 有的系統中允許存在上帝視角的 admin 角色，則其可以作為「超級管理員」顯示在角色配置的列表中。有的系統中不允許這種角色存在，則可將這種角色設置為隱形的狀態，僅賦予維護系統的工作人員。 **2\. 初始權限的賦予** 對于允許用戶自行加入的系統，需要設定一至多個默認的角色，有時可以是僅有最基礎權限的「游客」角色。 初始權限還可以與用戶既有的某些數據字段進行關聯，如添加用戶時獲取到用戶的崗位為「設計師」，則直接賦予「設計師」角色的權限。 **3\. 人員管理中對自己的處理** 在人員管理中，管理員角色處理自己時需要額外注意。因為如果修改或刪除了自己角色后，可能導致系統沒有管理角色，從而無法添加其他成員和正常運行。設計時可添加判斷，當自己為唯一管理角色時，禁止編輯和刪除。 **4\. 無頁面權限的提示** 雖然可以通過頁面權限限制直接隱藏當前用戶沒有權限的頁面，但不能排除用戶獲取到權限外的 url 地址。當用戶意外訪問到沒有權限的頁面時務必提供「無權限」的提示，避免用戶認為系統 bug。 #### 總結 總結一下，整個權限系統設計就是定義各個節點和節點間關系的過程。 節點包括： * 用戶； * 用戶組； * 角色； * 角色組； * 權限（頁面、操作、數據）； * 權限組（頁面、操作、數據）。 關系包括： * 是/否關系； * 繼承關系； * 限制關系（互斥、范圍限制、邊界限制、字段限制……）； 梳理清楚所有邏輯后，通過靈活定義節點和組合各節點之間的關系，便能夠輕松完成角色權限設計的100種解法。 例子： ??先大概解釋下我們的業務，我們做的是教育行業高校云平臺，每個學校都可以在我們平臺進行注冊，注冊完成后可以享受一些基礎的服務，當然了不同級別的用戶享受的基礎服務是不同的，這些基礎的服務包括新生注冊管理、基礎系統管理、考試系統管理、評教系統管理等模塊，每個模塊都相當于一個子系統，每個子系統都有各自的功能，每個功能也都有各自的相關的頁面，而所有的子系統、頁面以及頁面上的功能按鈕都是需要我們權限進行管理，所以我們的權限管理相對來說任務也是比較繁重的。 ? ??我們先來看下我們權限管理模塊的類圖：  用戶組是垂直的概念，相當于部門和人的關系。公司-->部門-->人，至上而下；這個部門只能做這個部門的事情； 角色是水平的概念，相當于是等級的劃分。CEO-->VP-->部門經理-->項目經理-->員工；例如每個經理都可以打考勤考核工資等等，擁有共同的權限。 當需要單獨設置的時候，就需要針對某個用戶進行設置了。 核心還是基于用戶、角色和許可的RBAC模型，只不過我們將這三者分別進行了相應的擴展： ## 用戶 ? ??無論哪個用戶首先它必須是屬于某個部門的，部門是行政單位，而某個部門也可以包含多個用戶，所以部門和用戶的關系為1對多的關系； ? ? 先說一下為什么要有用戶組的概念，如果有一類的用戶都要屬于某個角色，我們一個個給用戶授予角色，重復工作特別多，所以我們把這么一些用戶進行分類，也就是用戶組，這樣的話，我們直接對用戶組賦予角色，減少重復的工作量，這樣達到的目的是這，用戶擁有的所有許可，就是用戶個人所屬角色擁有的許可與該用戶所在用戶組所屬角色擁有的許可之和。一個用戶可以屬于多個用戶組，一個用戶組也可以包括多個用戶，所以用戶與用戶組是多對多的關系； ## 角色 ? ??角色是一定數量的許可的集合，許可的載體，一個角色可以包含多個用戶，一個用戶同樣的也可以屬于多個角色，所以角色與用戶的關系為多對多的關系。同樣的一個角色可以包含多個用戶組，一個用戶組也可以屬于多個角色，所以角色和用戶組也是多對多的關系； ## 許可 ? ??許可我一般稱它為權限，它包括控制對象和操作，控制對象一般為資源，包括菜單、頁面、文件等資源，而操作一般包括增刪改查等，圖中“系統操作”就是操作，“菜單信息”就是控制對象； ? ? 菜單信息中的每個菜單都會有增刪改查等操作，所以菜單信息與系統操作是一對多的關系； ? ??我們給角色授予權限時，授予就是顆粒最小的權限，所以我們將系統操作權限授予某些角色。一個角色可以擁有多個系統操作，一個系統操作同樣也可以屬于多個角色，所以系統操作和角色為多對多的關系。 ? ??到這里我們就將我們的權限模型之間的關系基本上介紹完畢了，在類圖中的兩個類之間的多對多的關系在數據庫中會出現第三張表，所以下面我們來看下我們的數據庫中表的關系圖：  # 四、改進 ? ??現在這個權限模型已經開發出來投入使用了，當然了現在的模型也不一定是最好的，只能說針對于現在的系統的規模是比較合適的，對于現在的權限模型還是有可以擴展的地方，其實就是類圖中的菜單信息，在系統中我們只是粗獷的將子系統名稱、子系統菜單、子系統菜單頁面元素、文件等這些資源全部放到了一個表中即菜單信息表，在表中我們利用類型進行具體區分，同時利用上下級關系來管理他們之間的層次關系，但是在這個表中冗余的數據會特別多，我覺得如果可以更進一步改善的話，可以考慮將菜單表按照菜單類型進行拆分，然后再來一張表資源關系表來管理這些類型資源之間的關系。