摘要：認為權限授權實際上是的問題。具體的權限，正向授權與負向授權。應用建模業務場景權限管理鑒權設計應用建模系統架構上支撐權限系統靈活配置，不僵硬字段，不僵硬行為，基于各種業務權限管控的特征靈活設計。表示許可權與角色之間多對多的指派關系。

之前寫過一篇大話權限中心的PHP架構之道，主要是從軟件工程角度介紹，如何通過編碼規范、依賴管理、數據源架構、事務處理、單元測試等技術，來保障權限系統的高可用，并未真正的涉及這套系統的架構。

今天準備從設計細節上分享一二。

望各位看官，心有“空杯”，帶著“問題”一探究竟。

這里還是尤為的重要，因為他是整套系統設計的根基。

所以殘忍的從上一篇中復制了一遍。。。

RBAC認為權限授權實際上是Who、What、How的問題。在RBAC模型中，who、what、how構成了訪問權限三元組，也就是“Who對What(Which)進行How的操作”。

Who：權限的擁用者或主體（如Principal、User、Group、Role、Actor等等）

What：權限針對的對象或資源（Resource、Class）。

How：具體的權限（Privilege，正向授權與負向授權）。

Operator：操作。表明對What的How操作。也就是Privilege+Resource

Role：角色，一定數量的權限的集合。權限分配的單位與載體,目的是隔離User與Privilege的邏輯關系.

權限系統的本質就是這個模型（個人觀點勿噴）。我們在此核心思想上，抽象了兩個新概念。

應用建模、權限自治

下面將從以下4個層面展開介紹。

應用建模

業務場景

權限管理

鑒權設計

系統架構上支撐權限系統靈活配置，不僵硬字段，不僵硬行為，基于各種業務權限管控的特征靈活設計。

公式一枚：應用＝資源＋行為＋角色

簡單點說，就是要管控資源的屬性和行為。

比如要管控菜單，屬性就包括菜單ID、菜單名稱、菜單URL、菜單ICON、上級菜單ID等，行為就包括訪問、授權等。（菜單權限）

比如要管控城市，屬性就包括區域ID、區域名稱、區域代碼、所屬區域ID等，行為就包括訪問、授權等。（區域權限）

比如要管控CMS，字段就包含頁面ID、頁面名稱等，行為就包括訪問、授權、編輯、重置等。（CMS數據權限）

按照慣性的思維，這里就是3張資源表對應角色表，同時還有3張資源角色關系表，換而言之，就是有多少資源需要管控就有多少張表（又是個人觀點，勿噴）。

慣性的思維，兩個痛點。

每一種資源都要獨立存儲。

每一種資源都要有一套Form排版&交互&存儲實現。

為了解決這個問題，我們做了以下的設計。

任意資源的字段，都可以抽象成如下幾類。

資源映射字段（mapField）

資源節點字段（treeFiled）

資源系統字段（systemFields）

資源表單字段（columns）

資源行為字段（privileges）

舉個栗子：菜單資源。

class menu extends app
{
    public static $appMapField = "url";
    public static $appTreeField = "name";
    public static $columns = array(
        array(
            "id" => "id",
            "label"  => "菜單ID",
            "type"  => "input",
            "format" => "int",
            "option" => array()
        ),
        array(
            "id" => "name",
            "label"  => "菜單名稱",
            "type"  => "input",
            "format" => "string",
            "option" => array()
        )
    );
    public static $privileges = array(
        array(
            "id"    => "access",
            "name"  => "訪問"
        )
    );
    public static $systemFields = array("id", "parent_id");
}

表單在網頁中主要負責數據采集功能。一個表單有三個基本組成部分：

表單標簽；

表單域，包含了文本框、密碼框、隱藏域、多行文本框、復選框、單選框、下拉選擇框和文件上傳框等；

表單按鈕。

常規工作是靜態表單。

設計動態表單模型，基本的思路應該是數據和表現顯示的分離。拋開表現層，一個表單包含的若干個字段和填寫的數據。所謂動態，就是這些字段名稱可能改變，數量可能有增減。

通過資源的columns字段控制表現層。

通過資源的數據字段控制數據層。

通過這種模式，任意資源的Form排版&交互&存儲都動態實現了。

資源表對應的Schema如下：

通過反射API，獲取當前應用的資源存儲插件（資源Data字段）。

app::find($params["app_id"])->getResoucePlugin()->save($params["data"]);

通過資源基類做數據存儲的統一封裝。

public function save()
{
    $this->beforeSave($this->attributes);
}

protected function beforeSave()
{
    //check attributes
}

很顯然資源Data字段，不能很好的完成單資源行為鑒權的任務。

設計上引入了資源映射字段，每當資源變更時，觸發addMap，會同步字段信息到資源映射關系表中（資源的語義化索引）。

舉幾個栗子，方便大家理解這個字段：

比如菜單類應用，映射字段就是菜單鏈接。

比如數據類應用，映射字段就是數據ID。

public function addMap()
{
    if ($this->map) {
        //sync map field
    } else {
        //create map field
    }
}

應用建模，相對來說是一個較技術的話題，換個方向，下面來和大家聊一聊系統的業務場景。

系統架構上支撐多種業務形態的權限管控。

說到權限，大多數應用場景都會想到菜單權限，然而我們也不例外，菜單類的應用，就是生產的第一個實例。

舉個栗子：A系統/菜單權限應用

字段

菜單ID、菜單名稱、菜單鏈接、菜單上級ID

行為

訪問、授權

數據類應用，相對于菜單類型來說，更關注的是，對某一行數據的行為控制，行為是多樣的。

舉個栗子：A數據/數據權限應用

字段

數據ID、數據名稱

行為

訪問、授權、編輯、刪除、新增、重置、導出、導入

表單類應用，在2B的系統中，權限設計尤為重要。

舉個栗子：A確認單/表單權限應用

字段

模塊ID、模塊名稱（行程模塊、供應商模塊、訂單模塊、財務模塊）

行為

訪問、授權、只讀、可寫、隱藏

總結一下權限的業務場景：

菜單類：單資源的單行為（能否”行為“當前“資源”）

數據類：單資源的多行為

表單類：多資源的多行為

小伙伴們，你們的業務場景能實現嗎？（留言吧）

接下來說說權限管理中的一些設計之道。

設計上參考JIRA，當前應用的管理者主導當前應用的權限生態。

資源的增刪改查

角色的增刪改查

資源字段定義

資源行為定義

資源行為的角色賦予

系統中給每一種資源都天生賦予一種系統行為叫做“授權”。

任意資源節點的角色行為賦予，都由擁有該資源節點授權行為的角色去分配。

兩個維度授權，方便檢索，也方便配置。

基于角色＋行為，選擇資源。

基于資源＋行為，選擇角色。

^^^^^^^^

下一個階段將會支持默認權限的配置，非應用內的角色，也同樣可以享有應用內的部分資源的部分行為的權限。

最后簡單說下，鑒權接口的設計。

U、R、P、S分別表示用戶集合、角色集合、許可權集合和會話集合。

PA P×R表示許可權與角色之間多對多的指派關系。

UA U×R表示用戶與角色之間多對多的指派關系。

公式一枚：S＝UA ∩ PA

統稱為資源樹接口。

舉個栗子：R角色在A應用中擁有P行為的資源。

統稱為行為鑒權接口。

舉個栗子：R角色在A應用中是否擁有R資源的P行為。

權限系統一直以來是我們應用系統不可缺少的一個部分，若每個應用系統都重新對系統的權限進行設計，以滿足不同系統用戶的需求，將會浪費我們不少寶貴時間，所以花時間來設計一個相對通用的權限系統是很有意義的。

設計一個相對通用的系統是很有意義的。(不僅僅是權限)

多交流，多分享，書寫更好的代碼。
享受編程和技術所帶來的快樂。