摘要：例如，系統(tǒng)中某個用戶辭職了，只需要將系統(tǒng)中該用戶的角色授權(quán)撤銷即可。

一些概念的具體定義如下

用戶（user）： 和計(jì)算機(jī)系統(tǒng)交互的人（在許多設(shè)計(jì)方案中，單個用戶可能擁有多個登錄標(biāo)識（ID），這些標(biāo)識可能同時處于活躍狀態(tài)，但身份驗(yàn)證機(jī)制可以使多個標(biāo)識匹配到某個具體的人，即用戶對于計(jì)算機(jī)系統(tǒng)來說具有唯一性）

主體（subject）： 一個代表用戶行為的計(jì)算機(jī)進(jìn)程（可以看成是用戶的agent）

客體（object）： 計(jì)算機(jī)系統(tǒng)中任意可訪問的資源

操作（operation）： 由客體觸發(fā)的活動進(jìn)程

權(quán)限（permission）： 系統(tǒng)中授權(quán)可以執(zhí)行的動作，即客體和操作的組合

角色： 不同權(quán)限或角色(職責(zé)）的集合

會話（session） : 用戶和系統(tǒng)交互的實(shí)例

請自行參考百度百科和維基百科

核心概念：用戶通過指派角色而獲取相應(yīng)的權(quán)限，而非直接把權(quán)限賦予用戶

通常用戶和權(quán)限的關(guān)系變更頻繁，而角色和權(quán)限的關(guān)系則相對穩(wěn)定。例如，系統(tǒng)中某個用戶辭職了，只需要將系統(tǒng)中該用戶的角色授權(quán)撤銷即可。

RBAC0總結(jié)：

元素： 用戶，角色，權(quán)限，組成權(quán)限的操作，操作對應(yīng)的客體

映射： 用戶-角色，角色-權(quán)限（角色與角色，角色與權(quán)限之間沒有多層繼承）

權(quán)限： 綁定在在計(jì)算機(jī)操作和資源客體上的抽象概念（操作 + 客體）

RBAC基礎(chǔ)模型的動態(tài)組件包括： 角色激活和主體訪問

主體： 能夠訪問處于控制下的角色、操作和客體的活動實(shí)體（主體代表用戶完成其所有請求，主體到用戶應(yīng)是單一映射，而用戶到主體則不一定），這個概念主要出現(xiàn)在動態(tài)模型中

RBAC1總結(jié)：

基于rbac0，與rbac0的區(qū)別是角色之間可以多層繼承

使用多層角色的原因：單一角色通常出現(xiàn)功能重疊的現(xiàn)象（屬于不同角色的用戶都會被授予一些一般性權(quán)限）

連接器角色：通常不直接賦予用戶；可以包含任意的權(quán)限集，作為抽象功能，抽象職責(zé)，抽象任務(wù)或抽象活動（便于重用）；通常如果在角色中有80%或更多的權(quán)限重疊，那么就可以選擇創(chuàng)建一個連接器角色；

RBAC2總結(jié)：

基于rbac0，與rbac0的區(qū)別是增加約束概念（主要是職責(zé)分離約束）

職責(zé)分離(SoD): 關(guān)鍵操作必須由兩個或更多的人來完成，這樣任何一個人都不可能多帶帶的破壞安全系統(tǒng)（所以在rbac中滿足職責(zé)分離約束即有效角色A和有效角色B對應(yīng)的用戶集合不能有交集）

職責(zé)分離方法： 靜態(tài)和動態(tài)方法

靜態(tài)職責(zé)分離模型：在為用戶指派角色時，就為角色施加約束（例如，如果為某用戶授予角色A,就不能再為其授予角色B）

動態(tài)職責(zé)分離模型：用戶以活動狀態(tài)使用系統(tǒng)時其約束才會發(fā)揮作用（例如，它可以同時賦予某用戶角色A和角色B，但不允許在一個會話中同時充當(dāng)兩個角色）

用戶管理：用戶的增刪改查

角色管理：角色的增刪改查

權(quán)限管理：權(quán)限的增刪改查

日志管理：日志的增刪改查

授權(quán)與撤銷授權(quán)操作

資源管理：資源的增刪改查（注意：這里的資源指的是那些需要被rbac模塊進(jìn)行權(quán)限管理的資源）

權(quán)限判斷操作：提供用于判斷權(quán)限的接口（常見形式如：checkAccess（user，role，params））

會話管理：即對用戶在當(dāng)前交互中的活動角色進(jìn)行管理

權(quán)限授予和身份鑒別是訪問控制的基礎(chǔ)

正確的權(quán)限授予事實(shí)上依賴于身份鑒別

身份鑒別是確定“你是誰“的過程；權(quán)限授予則是確定”你能干什么“的過程（即權(quán)限授予機(jī)制對用戶是否可以訪問系統(tǒng)資源做出”是“或”否“的決定）

以下僅為個人經(jīng)驗(yàn)

分析系統(tǒng)，列出一些可能存在的角色

分析系統(tǒng)，列出所有需要被管理的資源

對每種資源列出所有需要被管理的操作

根據(jù)每種資源的每種操作，組合出所有的基本（操作，資源）（只分析需要進(jìn)行權(quán)限管理的），形成"最底層permission"

對所有當(dāng)前存在的permission構(gòu)成的集合進(jìn)行逐層劃分（按照最小權(quán)限原則，并聯(lián)系可能存在的角色）

根據(jù)上一步的劃分，在每一個分界處提取出角色（其中可能包含連接器角色）

整理以上的工作，得到基本權(quán)限繼承結(jié)構(gòu)

對基本權(quán)限繼承結(jié)構(gòu)中的元素進(jìn)行分析，確定是否需要附加rule（rule可以用于確保是在滿足一些前置條件的情況下進(jìn)行權(quán)限判定，rule不一定非要附加在permission或role上，也可以附加于assignment上，看實(shí)際編碼時的考慮）

將帶有rule的"permission"作為其"最底層permission"的上層權(quán)限，最后如果"最底層permission"沒有上層角色，則可以考慮從結(jié)構(gòu)中刪除

整理并回顧，優(yōu)化每個元素的命名

如果在第7步中不選擇在permission或role上附加rule，則需要考慮如何在assignment上附加rule

問題的具體描述：

在某一系統(tǒng)中，資源（客體）A需要進(jìn)行權(quán)限管理。（A指的是一類資源，假設(shè)其中包括具體的該類資源a，b，c...）

存在用戶u，u可以訪問（access）A類資源中的a和b

用戶u對于資源a被賦予角色r1，u對于資源b被賦予角色r2

需要如何實(shí)現(xiàn)rbac使得其滿足以上需求？

Answer:

通常需要在rbac添加一個新的基本元素rule，rule的作用在于：當(dāng)進(jìn)行權(quán)限判定時，限定前置條件。

rule可以附加在permission，role或assignment（即某個用戶賦予某種角色：（user，role））中，在判定權(quán)限過程中，需要執(zhí)行rule

對應(yīng)于上面的問題，可以添加一張表T，T中的每條記錄包含（user，resourceA,role）,執(zhí)行rule的目的是判斷（u，a，r1）或（u，b，r2）存在于表T中

個人偏向于在assignment中綁定rule，這樣可以使權(quán)限繼承結(jié)構(gòu)更為清晰

通常在實(shí)現(xiàn)的時候會用到遞歸，下面以YII2中提供的代碼為例（源碼在yii2中的位置為vendoryiisoftyii2 bacDbManager.php,這里的代碼刪減了一些無關(guān)的內(nèi)容）

public function checkAccess($userId, $permissionName, $params = [])
{
    $assignments = $this->getAssignments($userId);//先查找當(dāng)前用戶的已經(jīng)授予的所有角色
    if ($this->hasNoAssignments($assignments)) {
        return false;//如果沒有任何授權(quán)的話，當(dāng)然是判定失敗
    }
    //遞歸
    return $this->checkAccessRecursive($userId, $permissionName, $params, $assignments);
}

protected function checkAccessRecursive($user, $itemName, $params, $assignments)
{
    if (($item = $this->getItem($itemName)) === null) {
        return false;//如果所要判定的permission或role根本不存在，自然判定失敗
    }
    
    //需要判定的item存在，先執(zhí)行當(dāng)前Item的rule，rule可以用于執(zhí)行一些業(yè)務(wù)邏輯
    if (!$this->executeRule($user, $item, $params)) {
        return false;
    }

    //如果當(dāng)前需要判定的role確實(shí)授予了該用戶，那么就可以返回true，結(jié)束遞歸
    if (isset($assignments[$itemName]) || in_array($itemName, $this->defaultRoles)) {
        return true;
    }

    //獲取當(dāng)前Item的上一層item，遞歸判定
    $query = new Query;
    $parents = $query->select(["parent"])
        ->from($this->itemChildTable)
           ->where(["child" => $itemName])
        ->column($this->db);
    foreach ($parents as $parent) {
        if ($this->checkAccessRecursive($user, $parent, $params, $assignments)) {
               return true;
        }
     }

     return false;
 }

在上面的代碼中可以看到，當(dāng)中使用了rule，在yii2中可以在permission或role中綁定相應(yīng)的rule（但在assignment中無法綁定rule）,引入rule可以解決Q7中的問題

為了實(shí)現(xiàn)在assignment中綁定rule，以下是經(jīng)過修改后的代碼（除了checkAccessRecursive方法需要修改外，還有其他的相關(guān)方法需要修改，但此處就不列出了，具體可以查看github項(xiàng)目：https://github.com/Darkgel/tr...）

protected function checkAccessRecursive($user, $itemName, $params, $assignments)
{
    if (($item = $this->getItem($itemName)) === null) {
        return false;
    }

    if (!$this->executeRule($user, $item, $params)) {
        return false;
    }

    if(in_array($itemName, $this->defaultRoles)){
        return true;
    }

       //這里添加了對assignment中的rule進(jìn)行判斷
    if (isset($assignments[$itemName])) {
        $assignment = $assignments[$itemName];
        if($this->executeRule($user, $assignment, $params)){
            return true;
        }
    }

    $query = new Query;
    $parents = $query->select(["parent"])
        ->from($this->itemChildTable)
        ->where(["child" => $itemName])
        ->column($this->db);
    foreach ($parents as $parent) {
        if ($this->checkAccessRecursive($user, $parent, $params, $assignments)) {
            return true;
        }
    }

    return false;
}