RBAC模型的探究（一）

最近在作本身的畢設，須要用到RBAC模型！如下內容是本身從書上或網上得來的！

 角色訪問控制（RBAC）引入了Role的概念,目的是爲了隔離User(即動做主體，Subject)與Privilege(權限，表示對Resource的一個操做，即Operation+Resource)。
Role做爲一個用戶(User)與權限(Privilege)的代理層，解耦了權限和用戶的關係，全部的受權應該給予Role而不是直接給User或Group。Privilege是權限顆粒，由Operation和Resource組成，表示對Resource的一個Operation。例如，對於新聞的刪除操做。Role-Privilege是many-to-many的關係，這就是權限的核心。基於角色的訪問控制方法（RBAC）的顯著的兩大特徵是：1.因爲角色/權限之間的變化比角色/用戶關係之間的變化相對要慢得多，減少了受權管理的複雜性，下降管理開銷。2.靈活地支持企業的安全策略，並對企業的變化有很大的伸縮性。

1.1       肯定角色須要操做的對象

1.1.1 以數據庫中的表做爲資源

在本系統中能夠存在兩種方案來定義角色須要操做的對象，一種方案是角色直接與數庫中的表相關聯，也就是說創建一張角色與表的關係表就能夠放映出這個關係，可是這樣設計有一個地方很差控制，系統完成後是以一個一個頁面的形式存在於客戶面前，而每個頁面裏面所表現的內容難道只和數據庫中的一張表有關係？若是存在和多張表的關係時候，那就得首先判斷某特定用戶屬於的角色對這些表的全部權限以後再處理具體的表示層；這種作法須要請求一個頁面的時候進行比較多的判斷，至關於在角色頁面中又增長了一個數據庫，即爲角色，數據庫，頁面之間的關係，在作一個對數據庫操做比較少的系統時這麼作顯然是很麻煩的。

1.1.2 以頁面做爲資源

本系統另一種定義資源的方式是以頁面作爲資源，當頁面作爲資源的時候，咱們能夠在一開就用一個 asp.net內置的對象session來存儲角色，而後再用戶要請求該頁面的時候用這個session來查數據庫中的角色權限表，來判斷該角色是否對該頁面有各類操做的權限，固然某一個用戶可能有好幾個角色，那隻須要多生成幾個session來存儲角色。這樣作的好處是，在用戶請求頁面的時候判斷比較容易。

1.1.3       資源選擇總結

以上兩種方案我選擇的是以頁面作爲資源，主要是該系統對於數據庫的操做不會像 HIS系統中那樣對於數據庫的操做那樣多。

 

1.2       操做的描述

操做做爲權限的核心之一，一般狀況下包括了增刪改查四種操做，關鍵的問題就在於如何在數據庫中放映出這四種操做，這裏仍然有兩種方案。第一能夠將這四種操做分別做爲四個字段，用一個標誌號來表示某主體是否具備某種操做，第二能夠將這四個操做放在一個字段中用 4位二進制數表示，有某一操做就將具體的二進制數至1。這樣作的好處，對於權限的操做看起來清晰明瞭，並且在具體查詢角色權限表的時候也只用去查詢一個字段，不用查詢4個字段，操做上會減小很多。

 

1.3       對於角色和用戶的簡單描述

一個系統會有使用它的用戶羣，這個羣裏，確定會有不少具備對這個系統有着同等權力的

用戶，因而將這些具備同等權力的用戶分進某一個角色裏。這樣角色的數量確定會少於用戶的數量，因而在之後的對龐大的用戶資料進行的維護過程當中，能夠將維護過程簡化爲用戶角色管理與角色權限管理了。

 

1.4       本系統關於用戶權限的基本數據表

通過以上分析，本系統所須要的用戶管理模塊所須要基本數據表就出來了

1.     用戶信息表

2.     角色信息表

3.     用戶角色關係表

4.     角色權限關係表

5.     權限對象說明表

以上的表格中，每張表都會用一個 ID號來做爲該表的主鍵，其中用戶和角色之間是多對多的關係，角色和權限之間也是多對多的關係。每一個表中具體字段暫且不表。

 

1．5          分析基本數據表

如今假設一個用戶登錄本系統且這個用戶爲合法用戶，那麼在他登錄以後就能夠根據用戶角色表肯定該用戶的角色（這個角色能夠是一個角色，也能夠是多個角色）；而後再根據角色權限表能夠最終肯定該用戶對那幾個頁面有某種具體的組合操做的權力。

狹義上的權限管理有了這 5張代表顯已經足夠了，可是咱們系統中存在一個功能樹，樹的節點是根據特定角色的權限來顯示的，也就是說得加一個表功能樹數據表，裏面將頁面對象與樹的節點關聯起來，固然並非全部的頁面都會與某一個節點對應，也不是全部的節點必定要對應於一個頁面，關於這個功能樹的表的設計問題在層次數據庫設計中本人已經作過度析，這裏再也不詳述。我採用的是父節點加子節點的設計方式。

那麼在用戶登錄以後查找到了該用戶對應的能操做的且存在於功能樹結點中的頁面，是否是就可以很順利的顯示出樹呢？看來彷佛還有個小問題須要解決掉！

由於一個用戶可能對應於幾個角色，好幾個角色中顯然也有可能存在對同一個頁面有相同的操做權力，若是該頁面是功能樹的一個節點，在用戶登錄以後要顯示出樹就得想辦法去掉相同的節點。

在後臺代碼中咱們能夠作到這一點，具體作法確定是把某用戶所對應的全部角色的相關頁面 id號放入一個datatable（ado.net中一個具體對象，至關於一張表格）,而後去掉重複的頁面，即id號相同的頁面，而後再從功能樹數據表中去查找這些頁面的父節點生成一顆功能樹（具體生成方案兩種作法，深度遍歷和廣度遍歷，本章不作討論）。固然咱們徹底能夠在數據庫中在作一張表爲角色功能樹節點對應表，這樣直接經過查找這張表格找出不重複的節點來生成樹，這樣就減小了不少後臺邏輯，帶來了很大的方便。

1．6          權限管理模塊總結

綜上所述，本系統的權限管理模塊一共有 7張數據表：

1. 用戶信息表

2. 角色信息表

3. 用戶角色關係表

4. 角色權限關係表

5. 權限對象說明表

6. 功能樹數據表

7．角色功能樹節點對應表

1． 7   對RBAC模型的分析

      NIST（The National Institute of Standards and Technology，美國國家標準與技術研究院）標準RBAC模型由4個部件模型組成，這4個部件模型分別是基本模型RBAC0（Core RBAC）、角色分級模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和統一模型RBAC3（Combines RBAC）。

       上述幾節主要是針對RBAC0來談的，從實際運用和RBAC的其餘3個模型咱們能夠看出，在RBAC模型中對於角色的設計實際上是擴展性和靈活性都很強的，本系統中主要是涉及的角色種類並不太多，因此沒有考慮角色的繼承和限制關係。可是在多以爲功能樹節點的重複問題上，明顯也能夠用角色的繼承和限制加以解決，可是因爲功能樹的節點並很少，全部節點一共也就不到二十個，因此並無採用RBAC3模型。

      固然該模型還有一些能夠擴展的地方,在參閱了一些文章後，我以爲如下幾點能夠更好的擴展RBAC模型。

       1.用戶組受權功能。

          2.角色類型功能。這個功能並非很重要，創建一個類型表，每一個角色能夠歸屬一個角色類型，便於表達方便，層次清晰，這個功能主要的做用在於表示層的顯示上。

          3.角色優先功能。能夠定義一個優先級別表，給每一個角色賦予優先級別，在處理角色的請求時，根據角色的優先級別排入鏈表裏進行處理，鏈表裏的角色請求能夠根據優先級別的不一樣動態調整，系統在處理角色請求時，每次都從隊首取一個角色請求，再將隊首指針指向下一個角色請求。

      4.角色生存週期功能。這個功能能夠指定角色的生存時間，時間能夠是用戶指定的，也能夠是根據某個條件來決定的。

        5.角色根據責任鏈動態變動權限功能。在一個責任鏈裏，一個客戶程序發出請求，這個請求將沿着責任鏈進行傳遞，責任鏈裏的每一個結點將依次處理該請求，若是結點不能處理該請求，則將此請求轉發到責任鏈的下一結點上；或者是，責任鏈中的每個結點都對該請求進行處理。在處理的過程當中，角色的權限將根據需求動態變化。

      6.角色根據狀態動態變動權限功能。在應用程序中可能存在多種狀態，好比在一個字處理程序中，當文件狀態是隻讀時，和文件狀態在可讀可寫時，它的功能是不同的，那麼角色須要根據這種狀態的變動而動態變動權限集，以便適應這種應用程序的要求。

固然了模型的存在並不意味着任何設計都必定要套用某種模型，只是說這個模型給了咱們一些很好的啓示和一套已經比較成熟的方法論，畢竟這些只是工程模型並非數學或者物理定理，咱們再設計中實事求是的根據需求，合理的考慮一些擴展性結合這些模型確定能設計出一套知足咱們須要的系統。