RBAC權限管理

　　基於角色的訪問控制（Role-Based Access Control）就是用戶經過角色與權限進行關聯。簡單地說，一個用戶擁有若干角色，每個角色擁有若干權限。這樣，就構形成「用戶-角色-權限」的受權模型。在這種模型中，用戶與角色之間，角色與權限之間，通常者是多對多的關係。

　　在RBAC中，權限與角色相關聯，用戶經過成爲適當角色的成員而獲得這些角色的權限。這就極大地簡化了權限的管理。在一個組織中，角色是爲了完成各類工做而創造，用戶則依據它的責任和資格來被指派相應的角色，用戶能夠很容易地從一個角色被指派到另外一個角色。角色可依新的需求和系統的合併而賦予新的權限，而權限也可根據須要而從某角色中回收。角色與角色的關係能夠創建起來以囊括更普遍的客觀狀況。

　　角色能夠理解爲必定數量的權限的集合，它是權限的載體。例如：一個論壇系統，「超級管理員」、「版主」都是角色。版主可管理版內的帖子、可管理版內的用戶等，這些是權限。要給某個用戶授予這些權限，不須要直接將權限授予用戶，可將「版主」這個角色賦予該用戶。 

　　這裏咱們舉出一個例子，用以說明在用戶、角色、權限三者在MySQL數據庫中表字段的設計。假設用戶A是管理員、B是普通用戶、C是匿名用戶，管理員擁有管理、修改和查看的權限、普通用戶擁有修改和查看的權限、匿名用戶擁有查看的權限。在Mysql數據庫中數據表的設計以下：

　　當用戶的數量很是大時，要給系統每一個用戶逐一受權（授角色），是件很是煩瑣的事情。這時，就須要給用戶分組，每一個用戶組內有多個用戶。除了可給用戶受權外，還能夠給用戶組受權。這樣一來，用戶擁有的全部權限，就是用戶我的擁有的權限與該用戶所在用戶組擁有的權限之和。（下圖爲用戶組、用戶與角色三者的關聯關係）

　　在應用系統中，權限表現成什麼？對功能模塊的操做，對上傳文件的刪改，菜單的訪問，甚至頁面上某個按鈕、某個圖片的可見性控制，均可屬於權限的範疇。有些權限設計，會把功能操做做爲一類，而把文件、菜單、頁面元素等做爲另外一類，這樣構成「用戶-角色-權限-資源」的受權模型。而在作數據表建模時，可把功能操做和資源統一管理，也就是都直接與權限表進行關聯，這樣可能更具便捷性和易擴展性。（見下圖）

　　請留意權限表中有一列「權限類型」，咱們根據它的取值來區分是哪一類權限，如「MENU」表示菜單的訪問權限、「OPERATION」表示功能模塊的操做權限、「FILE」表示文件的修改權限、「ELEMENT」表示頁面元素的可見性控制等。

　　這樣設計的好處有二。其一，不須要區分哪些是權限操做，哪些是資源，（實際上，有時候也很差區分，如菜單，把它理解爲資源呢仍是功能模塊權限呢？）。其二，方便擴展，當系統要對新的東西進行權限控制時，我只須要創建一個新的關聯表「權限XX關聯表」，並肯定這類權限的權限類型字符串。

　　這裏要注意的是，權限表與權限菜單關聯表、權限菜單關聯表與菜單表都是一對一的關係。（文件、頁面權限點、功能操做等同理）。也就是每添加一個菜單，就得同時往這三個表中各插入一條記錄。這樣，能夠不須要權限菜單關聯表，讓權限表與菜單表直接關聯，此時，須在權限表中新增一列用來保存菜單的ID，權限表經過「權限類型」和這個ID來區分是種類型下的哪條記錄。

　　到這裏，RBAC權限模型的擴展模型的完整設計圖以下：

　　隨着系統的日益龐大，爲了方便管理，可引入角色組對角色進行分類管理，跟用戶組不一樣，角色組不參與受權。例如：某電網系統的權限管理模塊中，角色就是掛在區局下，而區局在這裏可看成角色組，它不參於權限分配。另外，爲方便上面各主表自身的管理與查找，可採用樹型結構，如菜單樹、功能樹等，固然這些可不須要參於權限分配。

 

參考：http://blog.csdn.net/painsonline/article/details/7183613/

http://www.cnblogs.com/paulhe/p/4028389.html