現在比較普遍的權限管理模型就是RBAC(Role-Based Access Control)。

　　1. 權限控制分類

　　菜單功能

　　url控制(控制訪問不同的控制器)

　　2. RBAC的優缺點

　　2.1 優點

　　簡化了用戶和權限的關系

　　易擴展、易維護

　　2.2 缺點

　　RBAC模型沒有提供操作順序的控制機制，這一缺陷使得RBAC模型很難適應哪些對操作次序有嚴格要求的系統。

　　3. RBAC支持的安全原則

　　3.1 最小權限原則

　　RBAC可以將角色配置成其完成任務所需的最小權限集合。

　　3.2 責任分離原則

　　可以通過調用相互獨立互斥的角色來共同完成敏感的任務，例如要求一個記賬員和財務管理員共同參與統一過賬操作。

　　3.3 數據抽象原則

　　可以通過權限的抽象來體現，例如財務操作用借款、存款等抽象權限，而不是使用典型的讀寫權限。

　　4. 遠古時代的權限控制模型

　　當時還沒有RBAC，也沒有這個概念，就是一堆程序員在那鼓搗，覺得登錄這塊該做點什么，基本邏輯如下：

　　新建一個用戶，對這個用戶進行賦予權限。

　　但是一旦用戶多了，權限復雜了，這工作量也是蠻大的。

　　5. RBAC模型

　　5.1 RBAC 1.0

　　直接上圖，一目了然，當程序不是很復雜的時候，RBAC就是這樣設計的，我們公司的權限驗證模塊就是這樣設計的。簡簡單單，五張表，解決。

　　5.2 RBAC 2.0

　　基于RBAC 1.0模型的基礎上，進行了角色的訪問控制。

　　RBAC2中的一個基本限制是互斥角色的限制，互斥角色是指各自權限可以互相制約的兩個角色。對于這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。

　　該模型有以下幾種約束：

　　互斥角色 ：同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則?；コ饨巧侵父髯詸嘞藁ハ嘀萍s的兩個角色。對于這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。常舉的例子：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。

　　基數約束 ：一個角色被分配的用戶數量受限;一個用戶可擁有的角色數目受限;同樣一個角色對應的訪問權限數目也應受限，以控制高級權限在系統中的分配。例如公司的領導人有限的;

　　先決條件角色 ：可以分配角色給用戶僅當該用戶已經是另一角色的成員;對應的可以分配訪問權限給角色，僅當該角色已經擁有另一種訪問權限。指要想獲得較高的權限，要首先擁有低一級的權限。就像我們生活中，國家主席是從副主席中選舉的一樣。

　　運行時互斥 ：例如，允許一個用戶具有兩個角色的成員資格，但在運行中不可同時激活這兩個角色。

　　6. rbac的實現理論分析步驟

　　進入登錄頁面;

　　拿到通過post傳過來的用戶名和密碼;

　　使用orm進行過濾查找;

　　如果能找到值，則說明登錄成功：登錄成功后調用rbac初始化函數，初始化函數的主要功能是獲取用戶的權限和菜單保存到session中，并跳轉客戶列表頁面;如果失敗，頁面進行友好提示;

聲明：本站稿件版權均屬千鋒教育所有，未經許可不得擅自轉載。