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