摘要：認(rèn)為權(quán)限授權(quán)實際上是的問題。具體的權(quán)限，正向授權(quán)與負(fù)向授權(quán)。應(yīng)用建模業(yè)務(wù)場景權(quán)限管理鑒權(quán)設(shè)計應(yīng)用建模系統(tǒng)架構(gòu)上支撐權(quán)限系統(tǒng)靈活配置，不僵硬字段，不僵硬行為，基于各種業(yè)務(wù)權(quán)限管控的特征靈活設(shè)計。表示許可權(quán)與角色之間多對多的指派關(guān)系。

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

今天準(zhǔn)備從設(shè)計細(xì)節(jié)上分享一二。

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

這里還是尤為的重要，因為他是整套系統(tǒng)設(shè)計的根基。

所以殘忍的從上一篇中復(fù)制了一遍。。。

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

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

What：權(quán)限針對的對象或資源（Resource、Class）。

How：具體的權(quán)限（Privilege，正向授權(quán)與負(fù)向授權(quán)）。

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

Role：角色，一定數(shù)量的權(quán)限的集合。權(quán)限分配的單位與載體,目的是隔離User與Privilege的邏輯關(guān)系.

權(quán)限系統(tǒng)的本質(zhì)就是這個模型（個人觀點勿噴）。我們在此核心思想上，抽象了兩個新概念。

應(yīng)用建模、權(quán)限自治

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

應(yīng)用建模

業(yè)務(wù)場景

權(quán)限管理

鑒權(quán)設(shè)計

系統(tǒng)架構(gòu)上支撐權(quán)限系統(tǒng)靈活配置，不僵硬字段，不僵硬行為，基于各種業(yè)務(wù)權(quán)限管控的特征靈活設(shè)計。

公式一枚：應(yīng)用＝資源＋行為＋角色

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

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

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

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

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

慣性的思維，兩個痛點。

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

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

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

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

資源映射字段（mapField）

資源節(jié)點字段（treeFiled）

資源系統(tǒng)字段（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");
}

表單在網(wǎng)頁中主要負(fù)責(zé)數(shù)據(jù)采集功能。一個表單有三個基本組成部分：

表單標(biāo)簽；

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

表單按鈕。

常規(guī)工作是靜態(tài)表單。

設(shè)計動態(tài)表單模型，基本的思路應(yīng)該是數(shù)據(jù)和表現(xiàn)顯示的分離。拋開表現(xiàn)層，一個表單包含的若干個字段和填寫的數(shù)據(jù)。所謂動態(tài)，就是這些字段名稱可能改變，數(shù)量可能有增減。

通過資源的columns字段控制表現(xiàn)層。

通過資源的數(shù)據(jù)字段控制數(shù)據(jù)層。

通過這種模式，任意資源的Form排版&交互&存儲都動態(tài)實現(xiàn)了。

資源表對應(yīng)的Schema如下：

通過反射API，獲取當(dāng)前應(yīng)用的資源存儲插件（資源Data字段）。

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

通過資源基類做數(shù)據(jù)存儲的統(tǒng)一封裝。

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

protected function beforeSave()
{
    //check attributes
}

很顯然資源Data字段，不能很好的完成單資源行為鑒權(quán)的任務(wù)。

設(shè)計上引入了資源映射字段，每當(dāng)資源變更時，觸發(fā)addMap，會同步字段信息到資源映射關(guān)系表中（資源的語義化索引）。

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

比如菜單類應(yīng)用，映射字段就是菜單鏈接。

比如數(shù)據(jù)類應(yīng)用，映射字段就是數(shù)據(jù)ID。

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

應(yīng)用建模，相對來說是一個較技術(shù)的話題，換個方向，下面來和大家聊一聊系統(tǒng)的業(yè)務(wù)場景。

系統(tǒng)架構(gòu)上支撐多種業(yè)務(wù)形態(tài)的權(quán)限管控。

說到權(quán)限，大多數(shù)應(yīng)用場景都會想到菜單權(quán)限，然而我們也不例外，菜單類的應(yīng)用，就是生產(chǎn)的第一個實例。

舉個栗子：A系統(tǒng)/菜單權(quán)限應(yīng)用

字段

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

行為

訪問、授權(quán)

數(shù)據(jù)類應(yīng)用，相對于菜單類型來說，更關(guān)注的是，對某一行數(shù)據(jù)的行為控制，行為是多樣的。

舉個栗子：A數(shù)據(jù)/數(shù)據(jù)權(quán)限應(yīng)用

字段

數(shù)據(jù)ID、數(shù)據(jù)名稱

行為

訪問、授權(quán)、編輯、刪除、新增、重置、導(dǎo)出、導(dǎo)入

表單類應(yīng)用，在2B的系統(tǒng)中，權(quán)限設(shè)計尤為重要。

舉個栗子：A確認(rèn)單/表單權(quán)限應(yīng)用

字段

模塊ID、模塊名稱（行程模塊、供應(yīng)商模塊、訂單模塊、財務(wù)模塊）

行為

訪問、授權(quán)、只讀、可寫、隱藏

總結(jié)一下權(quán)限的業(yè)務(wù)場景：

菜單類：單資源的單行為（能否”行為“當(dāng)前“資源”）

數(shù)據(jù)類：單資源的多行為

表單類：多資源的多行為

小伙伴們，你們的業(yè)務(wù)場景能實現(xiàn)嗎？（留言吧）

接下來說說權(quán)限管理中的一些設(shè)計之道。

設(shè)計上參考JIRA，當(dāng)前應(yīng)用的管理者主導(dǎo)當(dāng)前應(yīng)用的權(quán)限生態(tài)。

資源的增刪改查

角色的增刪改查

資源字段定義

資源行為定義

資源行為的角色賦予

系統(tǒng)中給每一種資源都天生賦予一種系統(tǒng)行為叫做“授權(quán)”。

任意資源節(jié)點的角色行為賦予，都由擁有該資源節(jié)點授權(quán)行為的角色去分配。

兩個維度授權(quán)，方便檢索，也方便配置。

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

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

^^^^^^^^

下一個階段將會支持默認(rèn)權(quán)限的配置，非應(yīng)用內(nèi)的角色，也同樣可以享有應(yīng)用內(nèi)的部分資源的部分行為的權(quán)限。

最后簡單說下，鑒權(quán)接口的設(shè)計。

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

PA P×R表示許可權(quán)與角色之間多對多的指派關(guān)系。

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

公式一枚：S＝UA ∩ PA

統(tǒng)稱為資源樹接口。

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

統(tǒng)稱為行為鑒權(quán)接口。

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

權(quán)限系統(tǒng)一直以來是我們應(yīng)用系統(tǒng)不可缺少的一個部分，若每個應(yīng)用系統(tǒng)都重新對系統(tǒng)的權(quán)限進(jìn)行設(shè)計，以滿足不同系統(tǒng)用戶的需求，將會浪費我們不少寶貴時間，所以花時間來設(shè)計一個相對通用的權(quán)限系統(tǒng)是很有意義的。

設(shè)計一個相對通用的系統(tǒng)是很有意義的。(不僅僅是權(quán)限)

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