RBAC權限模型及數據權限擴展的實踐

話說你們對RBAC權限模型應該是耳熟能詳了。但真正用的好的並很少。而且原始的RBAC模型並不包括數據權限的管理，網上也差點兒沒有相關的文章能夠參考。本人通過幾個項目的實戰，在其基礎上擴展出一套可行的、簡單的數據權限模型，但願能夠幫助你們解決數據權限管理上的老大難問題。

至於什麼是數據權限，請移步個人其它文章，這裏再也不敷述。

一、關於角色的繼承：

在上圖描寫敘述的模型中，並無實現角色的繼承。既然一個用戶可以分配多個角色，那麼角色是否能繼承還有什麼必要呢？實現這個毫無必要的功能需要大大添加應用的複雜度，可謂是得不償失。

二、關於資源和功能：

你們可以從圖中看到僅僅有一張表的一個字段用來描寫敘述資源或功能的受權。在大多數場景中，資源和功能實際上沒法進行嚴格的區分。有所差異的僅僅是顆粒度的不一樣而已。一個業務組可以算是一種顆粒度最粗的資源。一個頁面或窗口相對就精細一些了；到頁面內菜單、工具欄button，就更精細了。假設控制的顆粒度達到頁面元素或界面控件的程度，就是最細顆粒度的權限控制了。因此無論你叫資源仍是功能、操做。都沒有差異。你要控制的就是那些東西，僅僅需要你描寫敘述出來，就可以被控制。

三、關於數據權限：

數據權限的受權相對功能權限來講，是全然不一樣的兩種類型。怎樣爲數據受權，這必須從數據權限的本質出發，從怎樣鑑別數據出發，僅僅有能夠像鑑別資源同樣對數據加以鑑別，咱們才幹對數據進行正確的受權。

假設咱們拋開數據值的不一樣（值的不一樣不是本質的不一樣）來分析數據，就會發現在通常場景中，數據的不一樣首先是業務類型的不一樣。譬如：訂單數據、結算數據、生產計劃數據等等。

對於同一類型數據，還可以以產生數據的對象：業務部門、業務人員加以區分。這也是經常遇到的需求：經理可以看到全部的訂單，業務員僅僅能看本身的。

什麼叫全部？什麼叫本身的？前一個概念對於不一樣的業務部門，實際的內容每每並不相同。A經理的全部訂單指的是A部門的訂單；而B經理的全部訂單則是B部門的訂單。

至於所謂的「本身的」。就更加明顯是一個相對概念了。張三的和李四的通常來講是不存在交集的。但有時候。也有一些絕對性的需求。譬如要求C部門的張三要管A部門訂單的審覈，相同C部門的王五則負責B部門。

這樣，數據權限的受權必須要從相對和絕對兩個維度進行定義，才幹作到邏輯完備。因此模型中也經過兩張表來描寫敘述數據權限，在相對模式中，用Mode字段來描寫敘述不一樣的顆粒度，而在絕對模式中用戶可以直接指定部門或用戶的ID。此外，用ModuleId字段來定義數據的類型，也就是產生業務的模塊。這個字段所包括的邏輯不只是差異數據的業務類型，更重要的是爲應用數據權限提供根據。

四、關於權限的應用：

本人在項目中，功能權限和數據權限都應用在數據訪問層。利用數據庫函數返回給應用程序被受權的資源或功能的ID集合。

應用程序依據ID集合經過反射載入資源或功能，達到用戶不能訪問非受權資源的目的。數據權限的應用方法也差點兒相同，將數據庫函數join到業務表上去，未受權的業務數據就會被過濾掉。經過join添加的Permission列，則描寫敘述了該行數據的讀寫權限爲僅僅讀仍是讀寫。