基于角色的訪問控制設(shè)計思想分析訪問控制的一般設(shè)計思路，提出一套基于角色的訪問控制的設(shè)計思路，并使其成為一個模塊加入到系統(tǒng)中使得系統(tǒng)能實現(xiàn)為不同角色的用戶提供不同的權(quán)限并進(jìn)行驗證等功能。
有這么一個案例：國內(nèi)有一家大型知名醫(yī)藥企業(yè)，它們使用了一套企業(yè)管理系統(tǒng)， 總公司經(jīng)理 用自己的賬戶登錄后能進(jìn)行 查看企業(yè)銷售報表 ， 審核訂單 等操作，而 區(qū)域銷售代表 用自己的賬戶登錄后能夠使用該系統(tǒng)進(jìn)行 客戶信息維護(hù) 、 為客戶下訂單 、 提取預(yù)付款 等操作，在公司總部大樓內(nèi)， 財務(wù)部會計 用自己的賬戶登錄后可以使用 帳務(wù)結(jié)算 、 工資發(fā)放 等操作…
在這套系統(tǒng)中，區(qū)域銷售代表是無權(quán)查看企業(yè)銷售報表，也無權(quán)進(jìn)行審核訂單操作的，其他人也類似，整個企業(yè)的所有員工在該系統(tǒng)中都各司其職，都無法越權(quán)使用超越自己職責(zé)范圍的操作。甚至他們各自進(jìn)入系統(tǒng)所能看到的界面都不盡相同。這對該系統(tǒng)來說，它就必須要有一個判斷邏輯：主體、行為、對象，也就是說 誰能做什么事 或者 誰不能做什么事 。 本文將和你一起討論該訪問控制模塊的設(shè)計思想，首先將會提供一些模型并加以分析，然后一步步改進(jìn)，最后得到一個小型但是比較完整的模型。
注意本文所實現(xiàn)的模型并不是完整意義的訪問控制系統(tǒng)，它僅僅實現(xiàn)了其中的一小部分，它只解決一些粗粒度的權(quán)限，也就是僅僅告訴系統(tǒng)誰能做什么事或者誰不能做什么事。從程序的角度來講，它只是以能為上層的訪問控制系統(tǒng)提供服務(wù)為目標(biāo)。 相當(dāng)多細(xì)粒度的權(quán)限問題因其極其獨特而不具通用意義，它們被看作是 業(yè)務(wù)邏輯 的一部分。比如，要求： 合同只能被它的創(chuàng)建者刪除，與創(chuàng)建者同組的用戶可以修改，所有的用戶能夠瀏覽 ，這既可以認(rèn)為是一個細(xì)粒度的權(quán)限問題，也可以認(rèn)為是一個業(yè)務(wù)邏輯問題，在整個權(quán)限系統(tǒng)的架構(gòu)設(shè)計之中對其不予過多考慮。
當(dāng)然，權(quán)限系統(tǒng)的架構(gòu)也必須要能支持這樣的控制判斷?；蛘哒f，系統(tǒng)提供足夠多但不是完全的控制能力。 系統(tǒng)只提供粗粒度的權(quán)限，細(xì)粒度的權(quán)限被認(rèn)為是業(yè)務(wù)邏輯的職責(zé) ，它不提供所有關(guān)于權(quán)限的問題的解決方法，只提供一個基礎(chǔ)，并解決那些具有 “ 共性 ” 的 ( 或者說粗粒度的 ) 部分。
在 總公司經(jīng)理張三審核訂單 中， 總公司經(jīng)理 是一個角色， 張三 是一個用戶， 訂單 是一個資源， 審核 是對該資源的一個行為。如果只說審核，這是無意義的，當(dāng)它結(jié)合了一個特定資源的實例（訂單）時，可以稱為這是一個 權(quán)限 ，也就是說， 審核訂單 是一個 權(quán)限 。對于 總公司經(jīng)理 來說， 審核訂單 這一權(quán)限是得到 許可授權(quán) 的，當(dāng) 張三 得到 總公司經(jīng)理 這一角色的任命后，它就得到了 審核訂單 這一權(quán)限的 許可授權(quán) 。當(dāng)然， 張三 既然是 總公司經(jīng)理 了， 總公司經(jīng)理 的權(quán)限有一大堆，比如 查看銷售報表 ，所以 張三 還能進(jìn)行 查看銷售報表 等操作。當(dāng)然還有其它幾個人也具有 總公司經(jīng)理 這一角色，所以他們能進(jìn)行和 張三 同樣的工作。
于是，對于 張三 ，它通過 總公司經(jīng)理 這一角色獲得了屬于它的一系列 權(quán)限集 （ 審核訂單 、查看銷售報表 等）。 這樣就形成一個映射關(guān)系：
從張三到他的權(quán)限的映射關(guān)系
如圖所示， 用戶 和 權(quán)限 被隔離開來，中間插入了一個 角色 的概念， 用戶 只有 綁定 了某一 角色 后，才能獲得該角色所對應(yīng)的 權(quán)限集 。這就是本文的核心思想。 有人可能會提出這樣的問題：為什么不直接將各個權(quán)限指派給具體用戶呢，如下圖所示，這樣可以更加靈活地為每一個用戶定義其權(quán)限。
從張三到他的權(quán)限的映射關(guān)系（排除角色）
實際上這樣做是可以的，當(dāng)然也有很多項目是這樣設(shè)計的。但是要考慮到兩個方面：
存在整個系統(tǒng)中各部分隨時間發(fā)生變化的概率導(dǎo)致的維護(hù)難度。例如：系統(tǒng)增加新功能，人員調(diào)動，公司業(yè)務(wù)擴(kuò)大而增設(shè)新崗位，新員工上崗等，都可以產(chǎn)生對用戶的權(quán)限重新分配的需要；這時就帶來對涉及到的用戶進(jìn)行一定的權(quán)限分配的維護(hù)的復(fù)雜性。
存在為大量用戶進(jìn)行權(quán)限分配時帶來重復(fù)操作的可能性。
當(dāng)系統(tǒng)中權(quán)限相對較少，并且用戶數(shù)量不大的情況下，這種方法還比較可行，但是隨著用戶數(shù)量發(fā)生大量的變化，或者其它原因?qū)е聶?quán)限數(shù)量的擴(kuò)大，大量重復(fù)操作帶來的時間上的浪費將是不可原諒的。 設(shè)想一下： 張三 因某種原因離開公司，在辦理辭職手續(xù)的時候要 取消 掉他所有分配到的權(quán)限，同時將其 總公司經(jīng)理 的權(quán)限分配給 李四 ，但是李四僅僅臨時擔(dān)任了一天，董事會任命的 王五 就正式來上任了，緊接著公司的 區(qū)域銷售代表劉六 報告說人手暫時不足，需要抽調(diào)人力臨時幫助一下 …… 天！為了給他們分配相應(yīng)的權(quán)限，光是這些點鼠標(biāo)的操作就夠你忙上一陣的了。而且都是重復(fù)性地操作。如果正好碰到上司正在為你的工作效率發(fā)脾氣的話，可能你連這個季度的獎金都會泡湯掉的。而這個時候你甚至可能會認(rèn)為電腦辦事情其實不如人快呢。 但是如果考慮一下角色會怎么樣？ 張三 辭職的時候，把他所 綁定 的 總公司經(jīng)理 角色取消掉，然后找到 李四 這個用戶，給他綁定一下這個角色， 王五 來上任后，再 取消 掉李四的這個角色，給 王五 綁定上，當(dāng) 區(qū)域銷售代表劉六 打電話來要求人手的時候，將上司列出的名單上的人找出來，把 區(qū)域銷售代表 這一角色拖過來，一點鼠標(biāo)，咔擦幾下搞定！整個過程不過三五分鐘甚至更少，而且不需要去看每個人需要有的權(quán)限是哪些，呵呵，這個管理員當(dāng)?shù)煤茌p松。 考慮到這些問題，對于基于角色的這一方案來講，還是有其適用范圍的，因為 角色 相對于用戶來說發(fā)生變化的概率要小得多，同時它減少了用戶和權(quán)限這兩個變化概率較大的部分之間的耦合度，因此會帶來一定的便利。 現(xiàn)在言歸正傳，上面提到的兩種解決方案有其各自的應(yīng)用范圍，本文所建議的基于角色的方案是基于有一定數(shù)量的用戶群體和一定數(shù)量的權(quán)限來考慮的。本文將設(shè)計一個基于角色的訪問控制模塊，它向其它模塊提供如下大致功能：
主要功能
識別當(dāng)前用戶，為其提供當(dāng)前用戶所屬的權(quán)限集；
判斷當(dāng)前用戶對某資源的操作的合法性；
權(quán)限
對系統(tǒng)中所有資源做一定整理和歸納并儲存，可以對其進(jìn)行檢索；
對系統(tǒng)中各資源所針對的行為進(jìn)行一定整理和歸納并儲存，可以對其進(jìn)行檢索；
角色
維護(hù)角色以及角色與權(quán)限的映射關(guān)系；
用戶
建立并維護(hù)用戶與角色之間的綁定關(guān)系；
下面將對其進(jìn)行詳細(xì)闡述。 先列出兩個部分： 用戶接口 和 權(quán)限 。角色呢？這里暫時先放一下，呵呵。整個模塊對于使用該模塊的其它模塊來說，它實際就是一個從 用戶 到 權(quán)限 的映射關(guān)系。如下圖所示：
不同的用戶分配不同的角色
而對于該模塊自身來說，從 用戶接口 到 權(quán)限 之間的通訊是一個虛通訊 ，中間插入了一個 角色服務(wù) ，對于 用戶接口 來說，它的所有請求都發(fā)送到 角色服務(wù) ，再由 角色服務(wù) 和 權(quán)限 打交道，處理結(jié)果由 角色服務(wù) 發(fā)給用戶接口。如下圖所示：
基于角色的訪問控制
用戶交互接口是直接面向用戶的模塊，它負(fù)責(zé)與角色服務(wù)進(jìn)行直接通信，請求或者響應(yīng)相關(guān)用戶或者用戶組的資源，以及對所獲取的資源進(jìn)行驗證。它主要有三個部分：用戶、用戶組、校驗器 這里的用戶從狹義上將，它僅僅維護(hù)用戶的標(biāo)識并用于綁定角色。而對于帳戶密碼管理、個人信息管理、安全登錄等功能它是不負(fù)責(zé)處理的。當(dāng)然它們可以儲存在一起，但是這里的用戶模塊是不對其負(fù)責(zé)的，因為前面已經(jīng)限定了該模塊實現(xiàn)的功能僅僅是完成用戶與權(quán)限的映射關(guān)系。
很多時候在系統(tǒng)使用一段時間后會出現(xiàn)一些角色變更，例如出現(xiàn)人員調(diào)動、部門機(jī)構(gòu)調(diào)整等，這時需要給原來的部分用戶重新進(jìn)行角色綁定，在給用戶綁定角色的時候，存在一種針對大量用戶進(jìn)行相同的角色綁定操作的可能，因此可以設(shè)置一些用戶組，并對這些用戶組進(jìn)行角色綁定。在創(chuàng)建用戶時就可以選擇將該用戶歸為某一用戶組，當(dāng)出現(xiàn)一次性對某一用戶組的用戶做大量相同的角色綁定時，就可以選擇將這些用戶所對應(yīng)的用戶組進(jìn)行角色綁定，能再次減少一些重復(fù)操作的勞累。用戶組可以被歸為另一用戶組，形成樹狀關(guān)系，用戶組成為各個節(jié)點，而用戶是葉子。
用戶和用戶組的樹狀關(guān)系
一個用戶可以被歸到多個用戶組，而一個用戶組可以包括多個用戶，這樣它們形成一個多對多的關(guān)系。如下圖所示：
用戶和用戶組的關(guān)系
1 ）將這一部分用戶解除該用戶組的歸屬并重新歸入一個新用戶組，然后對該用戶組做角色綁定；
2 ）單獨對每一個用戶進(jìn)行角色綁定。
選擇前者的話，可能出現(xiàn)這種結(jié)果：用戶組的數(shù)量比用戶數(shù)量還要多，并且大多都屬于無用的用戶組，但是已經(jīng)分不清哪些是哪些了。如果選擇后者的話又可能存在大量重復(fù)操作。這是不希望看到的結(jié)果。
校驗器負(fù)責(zé)為當(dāng)前用戶請求和檢索該用戶對應(yīng)的權(quán)限集，并根據(jù)一定的授權(quán)方式判斷當(dāng)前用戶的操作是否合法。它的判斷結(jié)果是系統(tǒng)授權(quán)模塊的授權(quán)依據(jù)，它將判斷為合法的用戶操作進(jìn)行許可授權(quán)、而判斷為非法的用戶操作將被拒絕服務(wù)。 校驗器的授權(quán)判斷邏輯有兩種：正向授權(quán)、反向授權(quán)。后文對其進(jìn)行折中后提出一種更為方便的基于安全級別的判斷邏輯。
校驗器認(rèn)為所有的資源默認(rèn)都是授權(quán)為拒絕的，只有在該用戶的權(quán)限表中有對其授權(quán)為許可的權(quán)限才認(rèn)為該用戶對該資源被授權(quán)為許可。而授權(quán)為拒絕的權(quán)限以及沒有授權(quán)的權(quán)限都認(rèn)為是拒絕。
校驗器認(rèn)為所有的資源默認(rèn)都是授權(quán)為許可的，只有在該用戶的權(quán)限表中有對其授權(quán)為拒絕的權(quán)限才認(rèn)為該用戶對該資源被授權(quán)為拒絕。而授權(quán)為許可的權(quán)限以及沒有授權(quán)的權(quán)限都認(rèn)為是許可。
不論是正向授權(quán)還是反向授權(quán)都是一個系統(tǒng)偏向兩個極端的授權(quán)方式，在一個稍微復(fù)雜的系統(tǒng)中可能需要一種較為折中的方式，這里就提出一個方法：基于安全級別的授權(quán)判斷邏輯。該方法定義如下： 為系統(tǒng)定義一系列由高到低的安全級別，如定義五種： Highest 、 High 、 Standard 、 Low 、 Lowest ，然后設(shè)定一個 當(dāng)前系統(tǒng)安全級別，假如定義為 Standard ； 為 權(quán)限定義一個 訪問級別，當(dāng)該用戶的權(quán)限集里沒有明確定義該權(quán)限時，校驗器根據(jù)其 訪問級別以及 當(dāng)前系統(tǒng)安全級別進(jìn)行級別高低的判斷。如果該資源的 訪問級別 不 高于 當(dāng)前系統(tǒng)安全級別的話，校驗器認(rèn)為該用戶對該權(quán)限應(yīng)判斷為非法，反之則為合法。 接開篇時的例子，假定該醫(yī)藥企業(yè)的系統(tǒng)當(dāng)前安全級別為 Standard ，有一個權(quán)限 審核訂單 ，其 訪問級別 定義為 High 。對于 劉六 ，該用戶沒有對這些權(quán)限的明確定義，那么在 劉六 進(jìn)行 審核訂單 操作時，校驗器發(fā)現(xiàn)該權(quán)限的 訪問級別（ High ）高于當(dāng)前系統(tǒng)安全級別 (Standard) ，那么校驗器認(rèn)為 劉六審核訂單 為 合法 ，如果將 當(dāng)前系統(tǒng)安全級別 調(diào)節(jié)到 Highest 后，劉六再次進(jìn)行審核訂單操作，這時候因為審核訂單的 訪問級別（ High ）低于當(dāng)前系統(tǒng)安全級別（ Highest ） ，校驗器則認(rèn)為 劉六審核訂單 為 非法 。 如果當(dāng)前系統(tǒng)安全級別設(shè)置到最高級，則校驗器的判斷邏輯等同于反向授權(quán)，反之則等同于正向授權(quán)。
將這一模塊定義為服務(wù)是因為它內(nèi)部的處理對用戶接口是不開放的，它僅僅開放接收用戶或用戶組標(biāo)識，處理后響應(yīng)給用戶接口一張權(quán)限集。該模塊一共分為三部分：綁定、角色、授權(quán)。其關(guān)系圖如下：
角色服務(wù)模塊關(guān)系圖
這里要提一點， RBAC_Binding 是綁定表，其中的 ClientID 表示用戶標(biāo)識或者用戶組標(biāo)識，這樣使用的前提是用戶標(biāo)識和用戶組標(biāo)識必須 唯一 ，假如用戶標(biāo)識已有編號 1000 ，則用戶組中則不能有編號為 1000 的標(biāo)識。所以 RBAC_Binding 只能認(rèn)為是一張抽象表，如果是喜歡用自動編號的朋友建議用兩張綁定表分別記錄用戶綁定和用戶組綁定，或者將用戶和用戶組表合并成一張表。
輸入客戶端標(biāo)識獲得其角色
綁定模塊記錄用戶或用戶組標(biāo)識和角色標(biāo)識，用于生成并管理 用戶或用戶組 和 角色 之間的映射關(guān)系，向其輸入用戶標(biāo)識可以獲得其綁定角色的輸出。按照企業(yè)應(yīng)用經(jīng)驗，這個綁定可以是無限期的，也可以有一定時效性：
在綁定的同時為其設(shè)定一個或多個不交叉的時間段，則當(dāng)前系統(tǒng)時間落在該綁定在這些時間段內(nèi)才 有效 ，如果在這些時間段之外則該綁定 無效 。這種綁定需要記錄各個時間段標(biāo)識（ 起始時間 、 結(jié)束時間或時長 ），對應(yīng)于綁定表則還需要有一張時間段表來記錄時間段，它們是零對多的關(guān)系。
時間段綁定
在綁定的同時為其設(shè)定一個或多個不交叉的周期性時間段，同樣，只有當(dāng)前系統(tǒng)時間落在當(dāng)前周期性時間段內(nèi)該綁定才 有效 。如果在這些時間段之外則該綁定 無效 。這種綁定需要記錄各個周期性時間段標(biāo)識（ 周期間隔時長 、 周期次數(shù) 、 起始時間 、 結(jié)束時間或時長 ），對應(yīng)于綁定表則還需要有一張周期性時間段表來記錄周期性時間段，它們是零對多的關(guān)系。同樣，周期和時間段是一對多的關(guān)系，即一個周期內(nèi)可以有多個時間段。
周期性時間段綁定
無限期綁定即不限制用戶的綁定時效，只需不存在上面幾種時效關(guān)系即可。
它以一定的規(guī)則處理其查詢所得的權(quán)限資源集，包括整理冗余權(quán)限資源、處理權(quán)限資源授權(quán)沖突等操作。 從用戶角度來看，角色就像一個權(quán)限資源集的過濾器，通過這個過濾器用戶可以獲得其相應(yīng)的權(quán)限資源集，將相對于該用戶或用戶組為非法的訪問資源過濾掉。從系統(tǒng)角度來看，系統(tǒng)負(fù)責(zé)維護(hù)一張角色表，記錄角色標(biāo)識、角色名稱。
從角色與角色之間的相互影響來看，角色和角色有下面幾種關(guān)系： 共存關(guān)系 。角色和角色之間不存在后面幾種關(guān)系時便認(rèn)為它們?yōu)楣泊骊P(guān)系，可以說它們之間沒有相互影響。這些角色可以一起綁定到同一個用戶 / 用戶組。 互斥關(guān)系 和排斥關(guān)系。角色和角色之間相互排斥時稱其為互斥關(guān)系，互斥的角色不能同時綁定到同一個用戶或用戶組，如：會計角色和出納角色就是互斥關(guān)系，這兩個角色不能綁定到同一個用戶。如果將互斥的范圍擴(kuò)大，一個角色和其他所有角色都是互斥關(guān)系的話，便稱之為排斥關(guān)系，一個用戶或用戶組綁定了該角色的話，它不能同時再綁定其它任何角色。 繼承關(guān)系 和概括關(guān)系。一個角色繼承其它一個或多個角色的內(nèi)容，我們稱前者為子角色，后者為父角色（ 可以是多個，但不能互斥），子角色作為對父角色的繼承，它將所有父角色的權(quán)限合并，可以覆蓋父角色的授權(quán)。我們說子角色和父角色是繼承關(guān)系的同時，反過來也可以說父角色和子角色是概括關(guān)系。
它負(fù)責(zé)對指定的角色分配相應(yīng)的權(quán)限并做授權(quán)，存放在一張權(quán)限表中（記錄角色標(biāo)識、資源標(biāo)識、行為、和授權(quán)方式），并進(jìn)行維護(hù)管理。角色服務(wù)以特定的角色列表為條件在角色授權(quán)表中做查詢得到一張授權(quán)資源表。授權(quán)所指定的資源同時也包括該資源下所有子資源，除非其子資源有單獨的授權(quán)定義將其覆蓋。
授權(quán)
授權(quán)方式有 許可授權(quán) 、 拒絕授權(quán) 和 零授權(quán) 。
對指定角色的某一權(quán)限做允許的授權(quán)，也就是它設(shè)定 允許 某一 角色 對某一 資源 的 行為 。
對指定角色的某一權(quán)限做拒絕的授權(quán)，也就是它設(shè)定 拒絕 某一 角色 對某一 資源 的 行為 。
對指定角色的某一權(quán)限做既不允許也不拒絕的授權(quán)。如果是該角色是子角色的話，其最終授權(quán)由其各個父角色的授權(quán)來判斷是否許可或拒絕，父角色也是零授權(quán)的話則由校驗器根據(jù) 當(dāng)前系統(tǒng)安全級別 來進(jìn)行實際授權(quán)（ 正向授權(quán) 、 反向授權(quán) ）。
每一項權(quán)限是由一個特定資源的實例及對該實例的一個行為構(gòu)成。例如： 訂單 是一個 資源 ，對于該資源，有 新建 、 更新 、 刪除 、 審核 、 查看 等 行為 ，所以就形成這些權(quán)限： 新建訂單 、 更新訂單 、 刪除訂單 、 審核訂單 、 查看訂單 。
權(quán)限
注意這里所指的權(quán)限是一個粗粒度級的權(quán)限。 粗粒度是表示類別級，即僅考慮對象的類別 (the type of object) ，不考慮對象的某個特定實例。比如， 用戶管理中，創(chuàng)建、刪除，對所有的用戶都一視同仁，并不區(qū)分操作的具體對象實例 。 細(xì)粒度是表示實例級，即需要考慮具體對象的實例 (the instance of object) ，當(dāng)然，細(xì)粒度是在考慮粗粒度的對象類別之后才再考慮特定實例。比如， 合同管理中，列表、刪除，需要區(qū)分該合同實例是否為當(dāng)前用戶所創(chuàng)建 。 權(quán)限邏輯需要配合業(yè)務(wù)邏輯。即權(quán)限系統(tǒng)以為業(yè)務(wù)邏輯提供服務(wù)為目標(biāo)。相當(dāng)多細(xì)粒度的權(quán)限問題因其極其獨特而不具通用意義，它們被看作是“業(yè)務(wù)邏輯”的一部分。比如，要求：“合同資源只能被它的創(chuàng)建者刪除，與創(chuàng)建者同組的用戶可以修改，所有的用戶能夠瀏覽”。這既可以認(rèn)為是一個細(xì)粒度的權(quán)限問題，也可以認(rèn)為是一個業(yè)務(wù)邏輯問題，在整個權(quán)限系統(tǒng)的架構(gòu)設(shè)計之中對其不予過多考慮。當(dāng)然，權(quán)限系統(tǒng)的架構(gòu)也必須要能支持這樣的控制判斷?；蛘哒f，系統(tǒng)提供足夠多但不是完全的控制能力。即，設(shè)計原則歸結(jié)為：“系統(tǒng)只提供粗粒度的權(quán)限，細(xì)粒度的權(quán)限被認(rèn)為是業(yè)務(wù)邏輯的職責(zé)”。 這里表述的訪問控制模塊僅是一個“不完全”的訪問控制模塊，即，它不提供所有關(guān)于權(quán)限的問題的解決方法。它提供一個基礎(chǔ)，并解決那些具有“共性”的 ( 或者說粗粒度的 ) 部分。在這個基礎(chǔ)之上，根據(jù)“業(yè)務(wù)邏輯”的獨特權(quán)限需求，編碼實現(xiàn)剩余部分 ( 或者說細(xì)粒度的 ) 部分，才算完整。
資源有很多種，如用戶界面資源、用戶操作資源、網(wǎng)址資源等，這里并不泛泛而談，僅僅以用戶操作資源為主，也就是前文例子中諸如 訂單 、 新聞 等。資源創(chuàng)建者將系統(tǒng)中各個面向用戶的功能進(jìn)行分類整理，生成一張資源表，并為每一項資源分配一個唯一標(biāo)識。 如 圖表 8 ? 1 ， RBAC_Res 就是一張資源表，其中 ResID 是每一項資源的唯一標(biāo)識字段，而 DefActionID 指向該資源的一個默認(rèn)行為，如 查看 。資源可以反向包含自身，形成樹狀結(jié)構(gòu)。在 RBAC_Res 中有一個 ParentResID 標(biāo)識指向該資源的父資源標(biāo)識。對父資源的授權(quán)其子資源在同樣行為下可以繼承，也可以覆蓋。 考慮資源的動態(tài)變化性（加入新功能、增加欄目等）在有大量角色的情況下為其更新授權(quán)不便，這時可以考慮加入域（ Domain ）的概念，這類似于用戶和用戶組的關(guān)系，將類似的資源進(jìn)行歸納，劃入某一域中，這時候可以以域直接參加授權(quán)而不是各個資源．
行為是針對資源的操作方式，如針對 訂單 可以有 新建 、 查看 、 更新 、 刪除 、 發(fā)布 等。 行為可以分為公共行為和私有行為。 公共行為 就是針對所有資源的公共操作方式，如 新建 、 查看 、 更新 、 刪除 等。 私有行為 是針對特定資源的操作方式，如針對訂單資源除了有其公共行為外，還有 審核 行為等。
結(jié)合前文提出一個用戶 - 角色 - 權(quán)限的查詢流程圖主線，對于維護(hù)相關(guān)數(shù)據(jù)的操作本文暫時不提供。 從用戶登錄系統(tǒng)伊始，該模塊就開始發(fā)揮作用，主要過程就是根據(jù)當(dāng)前用戶所持有的身份證明（有的文章成為令牌，或者會話）在該模塊所管理的所有權(quán)限中查詢該用戶當(dāng)前的操作是否合法
用戶 - 角色 - 權(quán)限數(shù)據(jù)關(guān)系圖
如果有讀者曾經(jīng)讀過阿西莫夫（ Issac Asimov ）的《基地》三部曲，你可能會發(fā)現(xiàn)，整個銀河帝國兩千五百萬個所謂的世界雖然由一個皇帝統(tǒng)治，但是各個單位都是有一定自治權(quán)的，畢竟那么大的國家，總部如果什么都要管的話那么它早就忙著崩潰了。 如果一個系統(tǒng)過于龐大和分散，里頭有數(shù)不清的角色，這時可以考慮一下分成一個個單獨的子系統(tǒng)，并將大部分權(quán)力下放，同時這個基于角色的訪問控制模塊也隨著下放，讓各個子系統(tǒng)行使最大的自治權(quán)。而總部僅僅保留一些 過問 的權(quán)力。這可能有點不可思議，但是現(xiàn)實中有很多案例的： 微軟的 Passport 就是一個龐大的銀河帝國，只要你得到 Passport SDK 的授權(quán)，就可以讓自己的系統(tǒng)使用統(tǒng)一的 MSN 帳戶進(jìn)行登錄而不必自行維護(hù)用戶數(shù)據(jù)，對于用戶來說該系統(tǒng)只要支持 Passport ，那么只要有一個 MSN 帳戶就通行無阻。連注冊都省掉了，當(dāng)然一些特定的用戶信息錄入不可省。如同入境手續(xù)一樣。 一個門戶網(wǎng)站就可能有很多業(yè)務(wù)系統(tǒng)：招聘應(yīng)聘、社區(qū)、聊天、郵件、新聞、 Blog 、教學(xué)、游戲、音樂、下載、交友等等，可能會有幾十個（看看國內(nèi)那幾個超級門戶網(wǎng)站就知道了），對應(yīng)的角色有一大堆，是不是很數(shù)不清，恐怕連這個網(wǎng)站的管理員都無法說清有多少角色和資源！ 但是這是一個自治的例子，總站只負(fù)責(zé)從子系統(tǒng)提取一些許可的數(shù)據(jù)，并維護(hù)一下單點登陸（系統(tǒng)雖多，但是一個用戶一個通行證，各系統(tǒng)根據(jù)通行證的級別各自控制訪問）、在線支付結(jié)算等公共事務(wù)，對于總部來說是不是很輕松？他不必去刻意了解該用戶是否是郵件系統(tǒng)的 VIP 用戶還是普通用戶，只需告訴郵件系統(tǒng)：這是我們的人，請根據(jù)貴處保留的此人的信息自行處理！
一個子系統(tǒng)中角色數(shù)量一般達(dá)到兩位數(shù)就足夠了，如果太多的話那么請考慮一下系統(tǒng)的設(shè)計是否需要修改一下，劃分成一個個單獨的子系統(tǒng)再各自考慮。例如：一個大型企業(yè)的系統(tǒng)規(guī)模過大時可以考慮一下是否可以將郵件、新聞、人事、物流、財務(wù)、文件等各個系統(tǒng)劃分出來，各自單獨使用訪問控制模塊，并提供一些接口調(diào)用，這樣不至于造成一個龐大的訪問控制系統(tǒng)并造成龐大的維護(hù)開銷。 當(dāng)然這些劃分并不是一定要在物理上劃分不可，把他們放在一起并以不同的標(biāo)識區(qū)分也可以，這要看實際應(yīng)用的需要了。
新加入一個子系統(tǒng)時并不一定要從零開始設(shè)置角色、用戶組等初始化信息，經(jīng)驗豐富的設(shè)計者或維護(hù)人員可以根據(jù)以往同類系統(tǒng)的應(yīng)用精心設(shè)計一套或幾套 RBAC 模板，新加入的子系統(tǒng)可以直接套用即可，當(dāng)然可以根據(jù)實際情況進(jìn)行修改，但總比從零開始要快多了。
代文龍：權(quán)限系統(tǒng)概要 (
http://www.jdon.com)
