rbac（role-based access control，基於角色的訪問控制），就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成「使用者-角色-許可權」的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。（如下圖）
角色是什麼？可以理解為一定數量的許可權的集合，許可權的載體。例如：乙個論壇系統，「超級管理員」、「版主」都是角色。版主可管理版內的帖子、可管理版內的使用者等，這些是許可權。要給某個使用者授予這些許可權，不需要直接將許可權授予使用者，可將「版主」這個角色賦予該使用者。
當使用者的數量非常大時，要給系統每個使用者逐一授權（授角色），是件非常煩瑣的事情。這時，就需要給使用者分組，每個使用者組內有多個使用者。除了可給使用者授權外，還可以給使用者組授權。這樣一來，使用者擁有的所有許可權，就是使用者個人擁有的許可權與該使用者所在使用者組擁有的許可權之和。（下圖為使用者組、使用者與角色三者的關聯關係）
在應用系統中，許可權表現成什麼？對功能模組的操作，對上傳檔案的刪改，選單的訪問，甚至頁面上某個按鈕、某個的可見性控制，都可屬於許可權的範疇。有些許可權設計，會把功能操作作為一類，而把檔案、選單、頁面元素等作為另一類，這樣構成「使用者-角色-許可權-資源」的授權模型。而在做資料表建模時，可把功能操作和資源統一管理，也就是都直接與許可權表進行關聯，這樣可能更具便捷性和易擴充套件性。（見下圖）
請留意許可權表中有一列「許可權型別」，我們根據它的取值來區分是哪一類許可權，如「menu」表示選單的訪問許可權、「operation」表示功能模組的操作許可權、「file」表示檔案的修改許可權、「element」表示頁面元素的可見性控制等。
這樣設計的好處有二。其一，不需要區分哪些是許可權操作，哪些是資源，（實際上，有時候也不好區分，如選單，把它理解為資源呢還是功能模組許可權呢？）。其二，方便擴充套件，當系統要對新的東西進行許可權控制時，我只需要建立乙個新的關聯表「許可權xx關聯表」，並確定這類許可權的許可權型別字串。
這裡要注意的是，許可權表與許可權選單關聯表、許可權選單關聯表與選單表都是一對一的關係。（檔案、頁面許可權點、功能操作等同理）。也就是每新增乙個選單，就得同時往這三個表中各插入一條記錄。這樣，可以不需要許可權選單關聯表，讓許可權表與選單表直接關聯，此時，須在許可權表中新增一列用來儲存選單的id，許可權表通過「許可權型別」和這個id來區分是種型別下的哪條記錄。
到這裡，rbac許可權模型的擴充套件模型的完整設計圖如下：
戲說 ofbiz 許可權組 角色 控制
ofbiz 裡面的許可權管理 發現大家還是有點迷惑 我舉個例子來幫助大家理解吧 a說 提議 要去 高原看藍天白雲 應用a b說 提議 要去內蒙古看大草原 應用b c說 提議 說要去三亞海邊看海 看美女 應用c d說 還是 去上海野生動物園看猴子吧！應用d 這個比較好舉例子，暫且就先去動物園吧 進動物...
使用者，使用者組，角色，許可權
基於 rbac role based access control 許可權訪問控制。也就是說乙個使用者可以有多個角色，乙個角色可以有多個許可權，通過將角色和許可權分離開來提高設計的可擴充套件性，通常乙個使用者有多個角色，乙個角色也會屬於多個使用者 多對多 乙個角色有多個許可權，乙個許可權也會屬於多個...
使用者 許可權 使用者組 角色
使用者是系統的操作人員。使用者組和角色都是乙個許可權的集合。使用者組是縱向的資料許可權定義，你屬於某乙個使用者組才可以檢視相關的資料。角色是橫向的功能許可權定義，你是某個角色才能做某些操作。使用者組和角色的交集確定許可權。用乙個簡單的例子來說明他們之間的聯絡。乙個公司包含業務部 人力資源部 財務部三...