RBAC簡介_動力節點Java學院整理，rbacjava

RBAC簡介_動力節點Java學院整理，rbacjava

什麼是許可權管理

基本上涉及到使用者參與的系統都要進行許可權管理，許可權管理屬於系統安全的範疇，許可權管理實現對使用者訪問系統的控制，按照安全規則或者安全性原則控制使用者可以訪問而且只能訪問自己被授權的資源。

許可權管理組件括使用者身份認證和授權兩部分，簡稱認證授權。對於需要存取控制的資源使用者首先經過身份認證，認證通過後使用者具有該資源的存取權限方可訪問。

使用者身份認證

身份認證，就是判斷一個使用者是否為合法使用者的處理過程。最常用的簡單身份認證方式是系統通過核對使用者輸入的使用者名稱和口令，看其是否與系統中儲存的該使用者的使用者名稱和口令一致，來判斷使用者身份是否正確。對於採用指紋等系統，則出示指紋；對於硬體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介面需要傳入當前操作人的標識，與商品資訊建立人標識對比，不一致則不允許修改商品資訊。