為什麼系統需要許可權控制？
生活中有沒有許可權限制？
災難片電影《2012》中富人和權貴有權登上諾亞方舟，窮苦老百姓只有等著災難的來臨；
屌絲身邊為什麼沒有那些長得漂亮、身材好的姑娘存在？
因為有錢人和漂亮姑娘都是珍貴稀有的，稀有的人在一起玩耍。而普通人往往無權擁有他們所擁有的許可權。
許可權管理的本質
web程式透過 url 的切換檢視不同的頁面（功能），所以許可權管理指的其實就是URL管理，對url控制就是對許可權的控制。
因此，一個人有多少個許可權取決於他可以訪問多少個URL。
RBAC是什麼？
RBAC（Role-Based Access Control）
，是基於角色的訪問控制，是一種先進的許可權管理的模型。RBAC把使用者透過角色與許可權進行關聯。即讓一個使用者擁有若干角色，每一個角色擁有若干許可權。
這樣就構造成了“使用者-角色-許可權”的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。
許可權系統中的概念
使用者
應用系統的具體操作者，使用者可以自己擁有許可權資訊，可以歸屬於0～n個角色，可屬於0～n個組。他的許可權集是自身具有的許可權、所屬的各角色具有的許可權、所屬的各組具有的許可權的合集。它與許可權、角色、組之間的關係都是n對n的關係。
角色
為了對許多擁有相似許可權的使用者進行分類管理，定義了角色的概念，例如系統管理員、管理員、使用者、訪客等角色。角色具有上下級關係，可以形成樹狀檢視，父級角色的許可權是自身及它的所有子角色的許可權的綜合。父級角色的使用者、父級角色的組同理可推。
組
為了更好地管理使用者，對使用者進行分組歸類，簡稱為使用者分組。組也具有上下級關係，可以形成樹狀檢視。在實際情況中，我們知道，組也可以具有自己的角色資訊、許可權資訊。這讓我想到我們的QQ使用者群，一個群可以有多個使用者，一個使用者也可以加入多個群。每個群具有自己的許可權資訊。例如檢視群共享。QQ群也可以具有自己的角色資訊，例如普通群、高階群等。
許可權
系統的所有許可權資訊表達了兩層含義。即控制的物件、操作。向上引申可將許可權劃分為3個組成部分：
頁面許可權：
使用者可以看到那些頁面；
操作許可權：
使用者可以在頁面內進行那些操作，增刪改查等；
資料許可權：
使用者可以看到那些資料或內容；
許可權模組設計
完整的許可權管理做大可作為獨立 系統進行開發，小做也必定做為SAAS平臺的核心基礎模板，在最初迭代初期就進入規劃、設計環節。在進行許可權模組設計時，產品可以從兩個角度考慮：
1.許可權控制管理
即對系統中各類涉及許可權限制的元素進行使用、檢視等操作的許可權控制。
l最基本的許可權管理是選單管理，
使用者沒有許可權的功能模組在選單節點上不顯示。
如：普通業務人員登入系統後，是看不到【使用者管理】選單的。
l功能許可權管理
，B/S系統的功能體現為URL，所以功能許可權管理主要是針對URL訪問的管理。
如：經過授權，部門經理可以檢視【使用者管理】選單，並檢視部門使用者資訊，但許可權設計要求，該部門經理沒有新增使用者的許可權。所以在訪問【新增使用者】的功能（URL）時，應該有沒有授權的提示資訊。同時在【使用者管理】頁面上，【新增使用者】的按鈕應該灰色顯示，不能點選。
l行級許可權管理
如：論壇管理員，許可權設計要求 A能管理論壇 【新聞版塊】，不能管理論壇 【技術交流】此時的許可權設計就應該根據論壇的相應ID來判斷許可權資訊。
l列級許可權管理
如：業務許可權設計要求，除銷售人員以外，其他使用者不能看到客戶的聯絡方式資訊。
此時的許可權設計要判斷相應的欄位（列）是否可以顯示。
l組織機構/部門級資料許可權管理
如：業務許可權設計要求，銷售一部的人員只能看到本部門的銷售訂單，銷售二部的人員只能看到本部門的銷售訂單，但銷售經理可以同時看到銷售一部和銷售二部的銷售訂單。此時的許可權設計就要根據銷售訂單資料本身的部門屬性來做判斷
l範圍型業務資料許可權管理
如：大賣場銷售人員在下銷售訂單時，要選擇相應的產品所在倉庫資訊。業務許可權設計要求，【國美】的銷售人員在選擇倉庫的下拉列表中不能看到【廣州倉庫】，而【大中電器】的銷售人員在選擇倉庫的下拉列表中不能看到【北京順義倉庫】
2.許可權分配管理
針對許可權管理內容透過系統授權功能分配給具體的使用者，角色的過程。
l直接對使用者授權
，直接分配到使用者的許可權具有最優先級別。
l對使用者所屬崗位授權
，使用者所屬崗位資訊可以看作是一個分組，和角色的作用一樣，但是每個使用者只能關聯一個崗位資訊。
l對使用者所屬角色授權，
使用者所屬角色資訊可以看作是一個許可權分組，每個使用者可以關聯多個角色。
l角色直接關聯具體的功能許可權（URL）
，也可以關聯負許可權，即此角色關聯的許可權不能使用負許可權功能。負許可權具有優先級別。
l分級授權，
系統管理員可以將自己擁有的許可權資訊授權給其他使用者。即可以設定分級管理員和超級管理員。
介面總體設計
想想一個簡單的許可權系統應該有什麼功能呢？當然是：使用者-角色-許可權，下圖所示過程：
建立角色列表
在角色列表快速建立一個角色：點選建立角色，支援建立角色時配置許可權。
創
建使用者列表
在使用者列表快速建立一個使用者：支援使用者關聯角色的功能。使用者許可權管理常見設計包括：
l所屬角色：
當用戶選擇“修改”按鈕時，彈出角色樹形結構，操作人可以透過勾選或取消勾選來修改該使用者所屬的角色。
l所屬組：
當用戶選擇“修改”按鈕時，彈出組的樹形結構，操作人可以透過勾選或取消勾選來修改該使用者所屬的組。
l使用者許可權：
透過對已具有的許可權取消勾選，或為某許可權新增勾選，來修改使用者的許可權資訊，點選“儲存”按鈕儲存修改資訊。
l總許可權：
透過對已具有的許可權取消勾選，或為某許可權新增勾選，來修改使用者的許可權資訊，點選“儲存”按鈕儲存修改資訊。
l使用者管理：
當選擇了某使用者時，點選右鍵，彈出選單列表：修改、刪除、取消，點選修改和刪除按鈕可以實現使用者的刪除和修改功能。
選擇某個組織，例如 “廣州分公司”，彈出選單列表：新增子組織、刪除組織、修改組織、新增使用者、取消，點選新增使用者按鈕可以實現使用者的新增功能。
l組織管理：
選擇某個組織，彈出選單列表：新增子組織、刪除組織、修改組織、新增使用者、取消，點選新增子組織、刪除組織、修改組織按鈕可以實現組織的新增、刪除和修改功能。
上述案例是基於最簡單的RBAC0模型建立，適用於大部分常規的許可權管理系統。
角色許可權管理
我們還可以在上面的內容基礎上再加上角色等級。角色許可權管理設計中，通常包括以下內容：
l包含使用者：
當用戶選擇“修改”按鈕時，彈出使用者列表，操作人可以透過勾選或取消勾選來修改該角色所包含的使用者。
l包含組：
當用戶選擇“修改”按鈕時，彈出使用者列表，操作人可以透過勾選或取消勾選來修改該角色所包含的組。
l角色許可權：
透過對已具有的許可權取消勾選，或為某許可權新增勾選，來修改角色的許可權資訊，點選“儲存”按鈕儲存修改資訊。
l管理角色：
選中組1的時候，右鍵點選可彈出組的操作列表，包括新增、刪除和修改按鈕，從而完成在該組下新增子組，刪除該組以及修改該組的功能。
具體介面呈現如下圖：
組權
限管理
除此之外，還有組許可權管理
l包含使用者：
當用戶選擇“修改”按鈕時，彈出使用者列表，操作人可以透過勾選或取消勾選來修改該組所包含的使用者。
l所屬角色：
當用戶選擇“修改”按鈕時，彈出角色樹形結構，操作人可以透過勾選或取消勾選來修改該組所屬的角色。
l組許可權：
透過對已具有的許可權取消勾選，或為某許可權新增勾選，來修改組的許可權資訊，點選“儲存”按鈕儲存修改資訊
l總許可權：
透過對已具有的許可權取消勾選，或為某許可權新增勾選，來修改組的許可權資訊，點選“儲存”按鈕儲存修改資訊
l組管理：
選中組1的時候，右鍵點選可彈出組的操作列表，包括新增、刪除和修改按鈕，從而完成在該組下新增子組，刪除該組以及修改該組的功能
操作日誌管理
l查詢操作日誌：
輸入上圖表單中的查詢資訊後，點選“查詢”按鈕，可查詢出符合條件的資訊。
l刪除操作日誌：
輸入上圖表單中的查詢資訊後，點選“查詢”按鈕，可查詢出符合條件的資訊。而後點選“刪除”按鈕，可刪除符合查詢條件的操作日誌。