這篇文章主要介紹了RBAC簡介，小編覺得挺不錯的，現在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧
什麼是權限管理
基本上涉及到用戶參與的系統都要進行權限管理，權限管理屬於系統安全的範疇，權限管理實現對用戶訪問系統的控制，按照安全規則或者安全策略控制用戶可以訪問而且只能訪問自己被授權的資源。
權限管理包括用戶身份認證和授權兩部分，簡稱認證授權。對於需要訪問控制的資源用戶首先經過身份認證，認證通過後用戶具有該資源的訪問權限方可訪問。
用戶身份認證
身份認證，就是判斷一個用戶是否爲合法用戶的處理過程。最常用的簡單身份認證方式是系統通過覈對用戶輸入的用戶名和口令，看其是否與系統中存儲的該用戶的用戶名和口令一致，來判斷用戶身份是否正確。對於採用指紋等系統，則出示指紋；對於硬件Key等刷卡系統，則需要刷卡。
用戶名密碼身份認證流程
關鍵對象
上邊的流程圖中需要理解以下關鍵對象：
Subject：主體
訪問系統的用戶，主體可以是用戶、程序等，進行認證的都稱爲主體；
n Principal：身份信息
是主體（subject）進行身份認證的標識，標識必須具有唯一性，如用戶名、手機號、郵箱地址等，一個主體可以有多個身份，但是必須有一個主身份（Primary Principal）。
n credential：憑證信息
是隻有主體自己知道的安全信息，如密碼、證書等。
授權
授權，即訪問控制，控制誰能訪問哪些資源。主體進行身份認證後需要分配權限方可訪問系統的資源，對於某些資源沒有權限是無法訪問的。
授權流程
下圖中橙色爲授權流程。
關鍵對象
授權可簡單理解爲who對what(which)進行How操作：
n Who，即主體（Subject），主體需要訪問系統中的資源。
n What，即資源（Resource），如系統菜單、頁面、按鈕、類方法、系統商品信息等。資源包括資源類型和資源實例，比如商品信息爲資源類型，類型爲t01的商品爲資源實例，編號爲001的商品信息也屬於資源實例。
n How，權限/許可（Permission），規定了主體對資源的操作許可，權限離開資源沒有意義，如用戶查詢權限、用戶添加權限、某個類方法的調用權限、編號爲001用戶的修改權限等，通過權限可知主體對哪些資源都有哪些操作許可。
權限分爲粗顆粒和細顆粒，粗顆粒權限是指對資源類型的權限，細顆粒權限是對資源實例的權限。
主體、資源、權限關係如下圖：
權限模型
對上節中的主體、資源、權限通過數據模型表示。
主體（賬號、密碼）
資源（資源名稱、訪問地址）
權限（權限名稱、資源id）
角色（角色名稱）
角色和權限關係（角色id、權限id）
主體和角色關係（主體id、角色id）
如下圖：
通常企業開發中將資源和權限表合併爲一張權限表，如下：
資源（資源名稱、訪問地址）
權限（權限名稱、資源id）
合併爲：
權限（權限名稱、資源名稱、資源訪問地址）
上圖常被稱爲權限管理的通用模型，不過企業在開發中根據系統自身的特點還會對上圖進行修改，但是用戶、角色、權限、用戶角色關係、角色權限關係是需要去理解的。
權限分配
對主體分配權限，主體只允許在權限範圍內對資源進行操作，比如：對u01用戶分配商品修改權限，u01用戶只能對商品進行修改。
權限分配的數據通常需要持久化，根據上邊的數據模型創建表並將用戶的權限信息存儲在數據庫中。
權限控制
用戶擁有了權限即可操作權限範圍內的資源，系統不知道主體是否具有訪問權限需要對用戶的訪問進行控制。
基於角色的訪問控制
RBAC基於角色的訪問控制（Role-Based Access Control）是以角色爲中心進行訪問控制，比如：主體的角色爲總經理可以查詢企業運營報表，查詢員工工資信息等，訪問控制流程如下：
上圖中的判斷邏輯代碼可以理解爲：
if(主體.hasRole("總經理角色id")){
查詢工資
}
缺點：以角色進行訪問控制粒度較粗，如果上圖中查詢工資所需要的角色變化爲總經理和部門經理，此時就需要修改判斷邏輯爲“判斷主體的角色是否是總經理或部門經理”，系統可擴展性差。
修改代碼如下：
if(主體.hasRole("總經理角色id") || 主體.hasRole("部門經理角色id")){
查詢工資
}
基於資源的訪問控制
RBAC基於資源的訪問控制（Resource-Based Access Control）是以資源爲中心進行訪問控制，比如：主體必須具有查詢工資權限纔可以查詢員工工資信息等，訪問控制流程如下：
上圖中的判斷邏輯代碼可以理解爲：
if(主體.hasPermission("查詢工資權限標識")){
查詢工資
}
優點：系統設計時定義好查詢工資的權限標識，即使查詢工資所需要的角色變化爲總經理和部門經理也只需要將“查詢工資信息權限”添加到“部門經理角色”的權限列表中，判斷邏輯不用修改，系統可擴展性強。
權限管理解決方案
粗顆粒度和細顆粒度
什麼是粗顆粒度和細顆粒度
對資源類型的管理稱爲粗顆粒度權限管理，即只控制到菜單、按鈕、方法，粗粒度的例子比如：用戶具有用戶管理的權限，具有導出訂單明細的權限。對資源實例的控制稱爲細顆粒度權限管理，即控制到數據級別的權限，比如：用戶只允許修改本部門的員工信息，用戶只允許導出自己創建的訂單明細。
如何實現粗顆粒度和細顆粒度
對於粗顆粒度的權限管理可以很容易做系統架構級別的功能，即系統功能操作使用統一的粗顆粒度的權限管理。
對於細顆粒度的權限管理不建議做成系統架構級別的功能，因爲對數據級別的控制是系統的業務需求，隨着業務需求的變更業務功能變化的可能性很大，建議對數據級別的權限控制在業務層個性化開發，比如：用戶只允許修改自己創建的商品信息可以在service接口添加校驗實現，service接口需要傳入當前操作人的標識，與商品信息創建人標識對比，不一致則不允許修改商品信息。