RBAC（Role-Based Access Control汹押，基于角色的訪問控制），就是用戶通過角色與權(quán)限進行關(guān)聯(lián)猛们。簡單地說念脯，一個用戶擁有若干角色，每一個角色擁有若干權(quán)限阅懦。這樣和二，就構(gòu)造成“用戶-角色-權(quán)限”的授權(quán)模型。在這種模型中耳胎，用戶與角色之間惯吕，角色與權(quán)限之間朽褪，一般者是多對多的關(guān)系硬猫。（如下圖）
角色是什么？可以理解為一定數(shù)量的權(quán)限的集合，權(quán)限的載體徒蟆。例如：一個論壇系統(tǒng)，“超級管理員”趾断、“版主”都是角色媚送。版主可管理版內(nèi)的帖子、可管理版內(nèi)的用戶等羽戒，這些是權(quán)限缤沦。要給某個用戶授予這些權(quán)限，不需要直接將權(quán)限授予用戶易稠，可將“版主”這個角色賦予該用戶缸废。
當用戶的數(shù)量非常大時，要給系統(tǒng)每個用戶逐一授權(quán)（授角色）驶社，是件非常煩瑣的事情企量。這時，就需要給用戶分組亡电，每個用戶組內(nèi)有多個用戶届巩。除了可給用戶授權(quán)外，還可以給用戶組授權(quán)份乒。這樣一來恕汇，用戶擁有的所有權(quán)限，就是用戶個人擁有的權(quán)限與該用戶所在用戶組擁有的權(quán)限之和冒嫡。（下圖為用戶組拇勃、用戶與角色三者的關(guān)聯(lián)關(guān)系）
在應用系統(tǒng)中，權(quán)限表現(xiàn)成什么孝凌？對功能模塊的操作方咆，對上傳文件的刪改，菜單的訪問蟀架，甚至頁面上某個按鈕瓣赂、某個圖片的可見性控制，都可屬于權(quán)限的范疇片拍。有些權(quán)限設計煌集，會把功能操作作為一類，而把文件捌省、菜單苫纤、頁面元素等作為另一類，這樣構(gòu)成“用戶-角色-權(quán)限-資源”的授權(quán)模型。而在做數(shù)據(jù)表建模時卷拘，可把功能操作和資源統(tǒng)一管理喊废，也就是都直接與權(quán)限表進行關(guān)聯(lián)，這樣可能更具便捷性和易擴展性栗弟。（見下圖）
請留意權(quán)限表中有一列“權(quán)限類型”污筷，我們根據(jù)它的取值來區(qū)分是哪一類權(quán)限，如“MENU”表示菜單的訪問權(quán)限乍赫、“OPERATION”表示功能模塊的操作權(quán)限瓣蛀、“FILE”表示文件的修改權(quán)限、“ELEMENT”表示頁面元素的可見性控制等雷厂。
這樣設計的好處有二惋增。其一，不需要區(qū)分哪些是權(quán)限操作改鲫，哪些是資源器腋，（實際上，有時候也不好區(qū)分钩杰，如菜單，把它理解為資源呢還是功能模塊權(quán)限呢诊县？）讲弄。其二，方便擴展依痊，當系統(tǒng)要對新的東西進行權(quán)限控制時避除，我只需要建立一個新的關(guān)聯(lián)表“權(quán)限XX關(guān)聯(lián)表”，并確定這類權(quán)限的權(quán)限類型字符串胸嘁。
這里要注意的是瓶摆，權(quán)限表與權(quán)限菜單關(guān)聯(lián)表、權(quán)限菜單關(guān)聯(lián)表與菜單表都是一對一的關(guān)系性宏。（文件群井、頁面權(quán)限點、功能操作等同理）毫胜。也就是每添加一個菜單书斜，就得同時往這三個表中各插入一條記錄。這樣酵使，可以不需要權(quán)限菜單關(guān)聯(lián)表荐吉，讓權(quán)限表與菜單表直接關(guān)聯(lián)，此時口渔，須在權(quán)限表中新增一列用來保存菜單的ID样屠，權(quán)限表通過“權(quán)限類型”和這個ID來區(qū)分是種類型下的哪條記錄。
到這里，RBAC權(quán)限模型的擴展模型的完整設計圖如下：
隨著系統(tǒng)的日益龐大痪欲，為了方便管理悦穿，可引入角色組對角色進行分類管理，跟用戶組不同勤揩，角色組不參與授權(quán)咧党。例如：某電網(wǎng)系統(tǒng)的權(quán)限管理模塊中，角色就是掛在區(qū)局下陨亡，而區(qū)局在這里可當作角色組傍衡，它不參于權(quán)限分配。另外负蠕，為方便上面各主表自身的管理與查找蛙埂，可采用樹型結(jié)構(gòu)，如菜單樹遮糖、功能樹等绣的，當然這些可不需要參于權(quán)限分配。
轉(zhuǎn)自：http://blog.csdn.net/painsonline/article/details/7183613/
