RBAC使用者角色權限設計方案
RBAC（Role-Based Access Control，基于角色的通路控制），就是使用者通過角色與權限進行關聯。簡單地說，一個使用者擁有若幹角色，每一個角色擁有若幹權限。這樣，就構造成“使用者-角色-權限”的授權模型。在這種模型中，使用者與角色之間，角色與權限之間，一般者是多對多的關系。（如下圖）
角色是什麼？可以了解為一定數量的權限的集合，權限的載體。例如：一個論壇系統，“超級管理者”、“版主”都是角色。版主可管理版内的文章、可管理版内的使用者等，這些是權限。要給某個使用者授予這些權限，不需要直接将權限授予使用者，可将“版主”這個角色賦予該使用者。
當使用者的數量非常大時，要給系統每個使用者逐一授權（授角色），是件非常煩瑣的事情。這時，就需要給使用者分組，每個使用者組内有多個使用者。除了可給使用者授權外，還可以給使用者組授權。這樣一來，使用者擁有的所有權限，就是使用者個人擁有的權限與該使用者所在使用者組擁有的權限之和。（下圖為使用者組、使用者與角色三者的關聯關系）
在應用系統中，權限表現成什麼？對功能子產品的操作，對上傳檔案的删改，菜單的通路，甚至頁面上某個按鈕、某個圖檔的可見性控制，都可屬于權限的範疇。有些權限設計，會把功能操作作為一類，而把檔案、菜單、頁面元素等作為另一類，這樣構成“使用者-角色-權限-資源”的授權模型。而在做資料表模組化時，可把功能操作和資源統一管理，也就是都直接與權限表進行關聯，這樣可能更具便捷性和易擴充性。（見下圖）
請留意權限表中有一列“權限類型”，我們根據它的取值來區分是哪一類權限，如“MENU”表示菜單的通路權限、“OPERATION”表示功能子產品的操作權限、“FILE”表示檔案的修改權限、“ELEMENT”表示頁面元素的可見性控制等。
這樣設計的好處有二。其一，不需要區分哪些是權限操作，哪些是資源，（實際上，有時候也不好區分，如菜單，把它了解為資源呢還是功能子產品權限呢？）。其二，友善擴充，當系統要對新的東西進行權限控制時，我隻需要建立一個新的關聯表“權限XX關聯表”，并确定這類權限的權限類型字元串。
這裡要注意的是，權限表與權限菜單關聯表、權限菜單關聯表與菜單表都是一對一的關系。（檔案、頁面權限點、功能操作等同理）。也就是每添加一個菜單，就得同時往這三個表中各插入一條記錄。這樣，可以不需要權限菜單關聯表，讓權限表與菜單表直接關聯，此時，須在權限表中新增一列用來儲存菜單的ID，權限表通過“權限類型”和這個ID來區分是種類型下的哪條記錄。
到這裡，RBAC權限模型的擴充模型的完整設計圖如下：
随着系統的日益龐大，為了友善管理，可引入角色組對角色進行分類管理，跟使用者組不同，角色組不參與授權。例如：某電網系統的權限管理子產品中，角色就是挂在區局下，而區局在這裡可當作角色組，它不參于權限配置設定。另外，為友善上面各主表自身的管理與查找，可采用樹型結構，如菜單樹、功能樹等，當然這些可不需要參于權限配置設定。
以上，是從基本的RBAC模型進行了擴充，具體的設計要根據項目業務的需要作調整。
設計使用者組是否必要:
有人認為設計使用者組時還需要為使用者添加使用者組以及為使用者組添權重限,這和直接對單個使用者添權重限異曲同工.但是當需要給已經存在的使用者賦予權限時,如果之前使用了使用者組這樣的設計模式,那麼便可以直接在使用者組中賦予權限,不必去給每個使用者賦予權限.而且使用使用者組也是展現使用者層級關系的一種結構,是以個人認為使用使用者組是有必要的.
場景1：
預算系統中的填報權限
a. 到預算版本的填報權限；
b. 到預算單元的填報權限；
c.不受a與b控制的預算管理者填報權限；
解決辦法：
以下配置都屬于業務系統 預算管理系統 的
像這種和業務有關系，需要和業務表字段強關聯起來。配置業務表的關聯字段如ysbbh、ysdybh，表示 這個業務系統下 某個角色（或使用者組或使用者） 到 某些ysbbh、ysdybh的 填報權限
場景2：
報表管理系統中的檢視權限
a. 到報表菜單的權限
b. 到菜單下分組的權限
c. 到分組下卡片的權限
解決辦法：角色（或使用者組或使用者） 到 菜單、分組、卡片 的 檢視權限
場景3：
子管理者權限；
解決辦法： 子管理者也是一種角色
綜上可以模拟釘釘對客戶的權限功能；
這個權限管理就是釘釘公司；
各個業務系統就是釘釘的客戶；
權限系統可以對各個業務系統授權 如 釘釘公司可以對各個客戶授權 ；
各個業務系統可以根據業務需求維護自己的角色與授權 如 釘釘的客戶可以根據自己公司的需要維護自己的角色與授權；
與釘釘公司權限系統不同的是 這裡的權限系統 可以配置一些基本的角色，提供給各個業務系統的負責人來選擇；
業務系統的權限通常分為：菜單通路權限 頁面元素的可見性權限 資料權限