什么是權(quán)限管理

基本上涉及到用戶(hù)參與的系統(tǒng)都要進(jìn)行權(quán)限管理，權(quán)限管理屬于系統(tǒng)安全的范疇，權(quán)限管理實(shí)現(xiàn)對(duì)用戶(hù)訪(fǎng)問(wèn)系統(tǒng)的控制，按照安全規(guī)則或者安全策略控制用戶(hù)可以訪(fǎng)問(wèn)而且只能訪(fǎng)問(wèn)自己被授權(quán)的資源。

權(quán)限管理包括用戶(hù)身份認(rèn)證和授權(quán)兩部分，簡(jiǎn)稱(chēng)認(rèn)證授權(quán)。對(duì)于需要訪(fǎng)問(wèn)控制的資源用戶(hù)首先經(jīng)過(guò)身份認(rèn)證，認(rèn)證通過(guò)后用戶(hù)具有該資源的訪(fǎng)問(wèn)權(quán)限方可訪(fǎng)問(wèn)。

用戶(hù)身份認(rèn)證

身份認(rèn)證，就是判斷一個(gè)用戶(hù)是否為合法用戶(hù)的處理過(guò)程。最常用的簡(jiǎn)單身份認(rèn)證方式是系統(tǒng)通過(guò)核對(duì)用戶(hù)輸入的用戶(hù)名和口令，看其是否與系統(tǒng)中存儲(chǔ)的該用戶(hù)的用戶(hù)名和口令一致，來(lái)判斷用戶(hù)身份是否正確。對(duì)于采用指紋等系統(tǒng)，則出示指紋；對(duì)于硬件Key等刷卡系統(tǒng)，則需要刷卡。

 用戶(hù)名密碼身份認(rèn)證流程

 關(guān)鍵對(duì)象

上邊的流程圖中需要理解以下關(guān)鍵對(duì)象：

Subject：主體

訪(fǎng)問(wèn)系統(tǒng)的用戶(hù)，主體可以是用戶(hù)、程序等，進(jìn)行認(rèn)證的都稱(chēng)為主體；

n Principal：身份信息

是主體（subject）進(jìn)行身份認(rèn)證的標(biāo)識(shí)，標(biāo)識(shí)必須具有唯一性，如用戶(hù)名、手機(jī)號(hào)、郵箱地址等，一個(gè)主體可以有多個(gè)身份，但是必須有一個(gè)主身份（Primary Principal）。

n credential：憑證信息

是只有主體自己知道的安全信息，如密碼、證書(shū)等。

授權(quán)

授權(quán)，即訪(fǎng)問(wèn)控制，控制誰(shuí)能訪(fǎng)問(wèn)哪些資源。主體進(jìn)行身份認(rèn)證后需要分配權(quán)限方可訪(fǎng)問(wèn)系統(tǒng)的資源，對(duì)于某些資源沒(méi)有權(quán)限是無(wú)法訪(fǎng)問(wèn)的。

授權(quán)流程

 下圖中橙色為授權(quán)流程。

關(guān)鍵對(duì)象

授權(quán)可簡(jiǎn)單理解為who對(duì)what(which)進(jìn)行How操作：

n Who，即主體（Subject），主體需要訪(fǎng)問(wèn)系統(tǒng)中的資源。

n What，即資源（Resource），如系統(tǒng)菜單、頁(yè)面、按鈕、類(lèi)方法、系統(tǒng)商品信息等。資源包括資源類(lèi)型和資源實(shí)例，比如商品信息為資源類(lèi)型，類(lèi)型為t01的商品為資源實(shí)例，編號(hào)為001的商品信息也屬于資源實(shí)例。

n How，權(quán)限/許可（Permission），規(guī)定了主體對(duì)資源的操作許可，權(quán)限離開(kāi)資源沒(méi)有意義，如用戶(hù)查詢(xún)權(quán)限、用戶(hù)添加權(quán)限、某個(gè)類(lèi)方法的調(diào)用權(quán)限、編號(hào)為001用戶(hù)的修改權(quán)限等，通過(guò)權(quán)限可知主體對(duì)哪些資源都有哪些操作許可。

權(quán)限分為粗顆粒和細(xì)顆粒，粗顆粒權(quán)限是指對(duì)資源類(lèi)型的權(quán)限，細(xì)顆粒權(quán)限是對(duì)資源實(shí)例的權(quán)限。

主體、資源、權(quán)限關(guān)系如下圖：

權(quán)限模型

對(duì)上節(jié)中的主體、資源、權(quán)限通過(guò)數(shù)據(jù)模型表示。

主體（賬號(hào)、密碼）

資源（資源名稱(chēng)、訪(fǎng)問(wèn)地址）

權(quán)限（權(quán)限名稱(chēng)、資源id）

角色（角色名稱(chēng)）

角色和權(quán)限關(guān)系（角色id、權(quán)限id）

主體和角色關(guān)系（主體id、角色id）

如下圖：

通常企業(yè)開(kāi)發(fā)中將資源和權(quán)限表合并為一張權(quán)限表，如下：

資源（資源名稱(chēng)、訪(fǎng)問(wèn)地址）

權(quán)限（權(quán)限名稱(chēng)、資源id）

合并為：

權(quán)限（權(quán)限名稱(chēng)、資源名稱(chēng)、資源訪(fǎng)問(wèn)地址）

上圖常被稱(chēng)為權(quán)限管理的通用模型，不過(guò)企業(yè)在開(kāi)發(fā)中根據(jù)系統(tǒng)自身的特點(diǎn)還會(huì)對(duì)上圖進(jìn)行修改，但是用戶(hù)、角色、權(quán)限、用戶(hù)角色關(guān)系、角色權(quán)限關(guān)系是需要去理解的。

權(quán)限分配

對(duì)主體分配權(quán)限，主體只允許在權(quán)限范圍內(nèi)對(duì)資源進(jìn)行操作，比如：對(duì)u01用戶(hù)分配商品修改權(quán)限，u01用戶(hù)只能對(duì)商品進(jìn)行修改。

權(quán)限分配的數(shù)據(jù)通常需要持久化，根據(jù)上邊的數(shù)據(jù)模型創(chuàng)建表并將用戶(hù)的權(quán)限信息存儲(chǔ)在數(shù)據(jù)庫(kù)中。

 權(quán)限控制

用戶(hù)擁有了權(quán)限即可操作權(quán)限范圍內(nèi)的資源，系統(tǒng)不知道主體是否具有訪(fǎng)問(wèn)權(quán)限需要對(duì)用戶(hù)的訪(fǎng)問(wèn)進(jìn)行控制。

基于角色的訪(fǎng)問(wèn)控制

RBAC基于角色的訪(fǎng)問(wèn)控制（Role-Based Access Control）是以角色為中心進(jìn)行訪(fǎng)問(wèn)控制，比如：主體的角色為總經(jīng)理可以查詢(xún)企業(yè)運(yùn)營(yíng)報(bào)表，查詢(xún)員工工資信息等，訪(fǎng)問(wèn)控制流程如下：

上圖中的判斷邏輯代碼可以理解為：

if(主體.hasRole("總經(jīng)理角色id")){

查詢(xún)工資

}

缺點(diǎn)：以角色進(jìn)行訪(fǎng)問(wèn)控制粒度較粗，如果上圖中查詢(xún)工資所需要的角色變化為總經(jīng)理和部門(mén)經(jīng)理，此時(shí)就需要修改判斷邏輯為“判斷主體的角色是否是總經(jīng)理或部門(mén)經(jīng)理”，系統(tǒng)可擴(kuò)展性差。

修改代碼如下：

if(主體.hasRole("總經(jīng)理角色id") || 主體.hasRole("部門(mén)經(jīng)理角色id")){

查詢(xún)工資

}

基于資源的訪(fǎng)問(wèn)控制

RBAC基于資源的訪(fǎng)問(wèn)控制（Resource-Based Access Control）是以資源為中心進(jìn)行訪(fǎng)問(wèn)控制，比如：主體必須具有查詢(xún)工資權(quán)限才可以查詢(xún)員工工資信息等，訪(fǎng)問(wèn)控制流程如下：

上圖中的判斷邏輯代碼可以理解為：

if(主體.hasPermission("查詢(xún)工資權(quán)限標(biāo)識(shí)")){

查詢(xún)工資

}

優(yōu)點(diǎn)：系統(tǒng)設(shè)計(jì)時(shí)定義好查詢(xún)工資的權(quán)限標(biāo)識(shí)，即使查詢(xún)工資所需要的角色變化為總經(jīng)理和部門(mén)經(jīng)理也只需要將“查詢(xún)工資信息權(quán)限”添加到“部門(mén)經(jīng)理角色”的權(quán)限列表中，判斷邏輯不用修改，系統(tǒng)可擴(kuò)展性強(qiáng)。

權(quán)限管理解決方案

粗顆粒度和細(xì)顆粒度

 什么是粗顆粒度和細(xì)顆粒度

對(duì)資源類(lèi)型的管理稱(chēng)為粗顆粒度權(quán)限管理，即只控制到菜單、按鈕、方法，粗粒度的例子比如：用戶(hù)具有用戶(hù)管理的權(quán)限，具有導(dǎo)出訂單明細(xì)的權(quán)限。對(duì)資源實(shí)例的控制稱(chēng)為細(xì)顆粒度權(quán)限管理，即控制到數(shù)據(jù)級(jí)別的權(quán)限，比如：用戶(hù)只允許修改本部門(mén)的員工信息，用戶(hù)只允許導(dǎo)出自己創(chuàng)建的訂單明細(xì)。

 如何實(shí)現(xiàn)粗顆粒度和細(xì)顆粒度

對(duì)于粗顆粒度的權(quán)限管理可以很容易做系統(tǒng)架構(gòu)級(jí)別的功能，即系統(tǒng)功能操作使用統(tǒng)一的粗顆粒度的權(quán)限管理。

對(duì)于細(xì)顆粒度的權(quán)限管理不建議做成系統(tǒng)架構(gòu)級(jí)別的功能，因?yàn)閷?duì)數(shù)據(jù)級(jí)別的控制是系統(tǒng)的業(yè)務(wù)需求，隨著業(yè)務(wù)需求的變更業(yè)務(wù)功能變化的可能性很大，建議對(duì)數(shù)據(jù)級(jí)別的權(quán)限控制在業(yè)務(wù)層個(gè)性化開(kāi)發(fā)，比如：用戶(hù)只允許修改自己創(chuàng)建的商品信息可以在service接口添加校驗(yàn)實(shí)現(xiàn)，service接口需要傳入當(dāng)前操作人的標(biāo)識(shí)，與商品信息創(chuàng)建人標(biāo)識(shí)對(duì)比，不一致則不允許修改商品信息。