壹 RBAC模型
目前，接受度較高的功能權限模型是RBAC（Role-Based Access Control）模型。在RBAC中，權限與角色相關聯，用戶通過成為適當角色的成員而得到這些角色的權限。這就極大地簡化了權限的管理。在壹個組織中，角色是為了完成各種工作而創造，用戶則依據它的責任和資格來被指派相應的角色，用戶可以很容易地從壹個角色被指派到另壹個角色。角色可依新的需求和系統的合並而賦予新的權限，而權限也可根據需要而從某角色中回收。
1.角色的作用
如果沒有角色的概念，直接用戶對應權限，雖然會更加靈活，但是後臺的數據表設計會變得復雜，操作成本也會很高，同時容錯能力也會變得很差。
而引入“角色”概念後，用戶與角色可為多對壹或多對多的關系，當壹個用戶的角色為多對多時，當前用戶的權限是多個角色的並集。此時只需要為角色賦予權限，能夠大大減輕管理負擔，同時將用戶與權限解耦，提供更大的靈活性，同時整個設計的容錯能力也提高了很多。
2.引入用戶組
? 壹些大型的平臺上，如果用戶數量較大，新增角色時，需要為大量用戶分配新的角色，工作量巨大，此時可以引入用戶組的概念，將這些用戶拉到同壹個用戶組中，然後對整個用戶組進行角色的指定，這就大大減少了角色分配的工作量。
同理如果權限較多時也會存在壹樣的問題，對角色進行權限設置時也需要大量的操作，此時可以考慮引入權限組的概念，將關聯性較強的權限大包成組賦予角色，從而減少賦值時的工作量，現實中權限組的使用相對較少，因為系統中的權限壹般來講是有限的。需要註意的是即使有用戶組或權限組的存在，也可以允許用戶或權限與角色直接關聯，這個可以視具體業務情況而定。
下圖所示為mac系統中運行添加用戶組，並以用戶組為單位配置權限。
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。
總結壹下，整個權限系統設計就是定義各個節點和節點間關系的過程。
節點包括：
用戶；用戶組；角色；角色組；權限（頁面、操作、數據）；權限組（頁面、操作、數據）；