本文在RBAC基本思想的基礎上，增加資源權限的概念，設計了在企業應用系統中用戶權限控制的一種具體的簡單實現方法。
關鍵字 用戶權限控制
名詞解釋
資源權限：資源指的是納入企業應用的一切需要管理的信息實體，如進銷存系統中的進貨訂單；資源權限則是系統將要在這些資源的基礎上進行的訪問使用權限的控制；
引言
企業應用系統對安全問題有較高的要求，傳統的訪問控制方法DAC（Discretionary Access Control，自主訪問控制模型）、MAC（Mandatory Access Control，強制訪問控制模型）難以滿足複雜的企業環境需求。因此，NIST（National Institute of Standards and Technology，美國國家標準化和技術委員會）於上世紀90年代初提出了基於角色的訪問控制方法，實現了用戶與訪問權限的邏輯分離，更符合企業的用戶、組織、數據和應用特徵。
本文將首先介紹RBAC（Role Based Access Control）的基本思想，在此基礎上，給出企業應用系統中實現R-F-RBAC（Role-Function-Resource Based Access Control，基於角色-功能-資源的權限控制）的一種具體方法。
RBAC的基本思想可簡單地用圖1來表示，即把整個訪問控制過程分成兩步：訪問權限與角色相關聯，角色再與用戶關聯，從而實現了用戶與訪問權限的邏輯分離。
由於RBAC實現了用戶與訪問權限的邏輯分離，因此它極大的方便了權限管理。例如，如果一個用戶的職位發生變化，只要將用戶當前的角色去掉，加入代表新職務或新任務的角色即可，角色/權限之間的變化比角色/用戶關係之間的變化相對要慢得多，並且委派用戶到角色不需要很多技術，可以由行政管理人員來執行，而配置權限到角色的工作比較複雜，需要一定的技術，可以由專門的技術人員來承擔，但是不給他們委派用戶的權限，這與現實中情況正好一致。
而R-F-RBAC的設計思路是在RBAC基礎上的一個發展，引入了資源的概念。何所謂資源，大體來說可以是納入系統管理的信息，在技術實現層面可以是一張表、一條或一列記錄、甚至可以是表的一個單元格。在實踐使用中，一些高安全級別額的企業應用，僅僅將權限控制到功能是不夠的，要求能控制某些用戶只能操作到指定的系統內容。
案例分析
這裏我們用一個簡單的應用模型實例對R-F-RBAC進行深入分析，即給某企業應用假設一個安全級別較高的合同管理子模塊，這個模塊涉及如下元素：
·合同文件：根據業務要求分爲三個等級（項目級、部門級、公司級）；
·具體功能：根據實際功能要求分爲草擬、上報、會籤、批覈；
·操作角色：根據公司行政職位設置有項目經理、部門經理、總經理；
·操作人員：公司的內部人員A項目經理張三、甲部門經理李四、總經理王二；
系統的安全需求爲A項目經理張三只能草擬並上報僅限於A項目的項目級別合同文件，甲部門經理李四只能草擬、上報、會籤率屬於甲部門下的項目級或部門級的合同文件，而總經理王二則有權任意操作整個公司的三個級別的合同文件，可將此模型歸納爲如下表格：
|
人員 |
角色 |
功能 |
資源 |
|
王二 |
總經理 |
草擬、上報、會籤、批覈 |
三個級別的合同文件 |
|
李四 |
部門經理 |
草擬、上報、會籤 |
甲部門下的項目級或部門級的合同文件 |
|
張三 |
項目經理 |
草擬、上報 |
僅限於A項目的項目級別合同文件 |
解決方案
爲此我們要設計如下幾張關鍵的數據表：
·用戶表： 記錄用戶的相關信息，UserID作爲唯一的用戶標識；
·角色表： 記錄角色的相關信息，RoleID作爲唯一的角色標識；
·模塊及功能表：記錄模塊相關信息及模塊的相關功能，分爲主子關係表；
·資源表： 記錄系統中的所有需要高安全控制的資源信息，其中ResTable是資源對應的數據表名（如合同信息表），ResTerm則是給定該資源的條件（如甲部門下的項目級或部門級的合同文件）用於限定數據提取範圍；
由於本文提到的R-F-RBAC的設計思路均考慮用戶可以授予多角色，因此我們需要建立用戶-角色對應表，用來記錄某用戶可能對應的若干角色信息，同樣需要建立的是角色-功能對應表和角色-資源對應表，以徹底剝離用戶與權限訪問間的關係；
數據庫關係圖（僅涉及關鍵字段）如下：
程序實現
代碼實現應分爲三大部分：
·權限數據維護：該部分主要實現用戶、角色、功能、資源等基礎信息的維護，給系統管理員一個便利的操作接口；
·權限數據處理：指的是在程序內部實現權限調用接口，如根據調用者提供的模塊及用戶的信息給出應該提供可操作數據和功能；
·權限數據引用：在UI層具體的處理用戶對應的組合權限，如根據得到的功能權限信息控制UI上按鈕、菜單等功能元素的顯隱活可用性，或根據得到的資源權限條件組合提數條件以達到某些用戶只能操作到指定的系統內容的控制級別