RBAC權限模型及資料權限擴充的實踐

話說大家對RBAC權限模型應該是耳熟能詳了，但真正用的好的并不多。而且原始的RBAC模型并不包含資料權限的管理，網上也幾乎沒有相關的文章可以參考。本人經過幾個項目的實戰，在其基礎上擴充出一套可行的、簡單的資料權限模型，希望能夠幫助大家解決資料權限管理上的老大難問題。至于什麼是資料權限，請移步我的其他文章，這裡不再敷述。

1、關于角色的繼承：

在上圖描述的模型中，并沒有實作角色的繼承。既然一個使用者可以配置設定多個角色，那麼角色能否繼承還有什麼必要呢？實作這個毫無必要的功能需要大大增加應用的複雜度，可謂是得不償失。

2、關于資源和功能：

大家可以從圖中看到隻有一張表的一個字段用來描述資源或功能的授權。在大多數場景中，資源和功能實際上無法進行嚴格的區分，有所差別的隻是顆粒度的不同而已。一個業務組可以算是一種顆粒度最粗的資源，一個頁面或窗體相對就精細一些了；到頁面内菜單、工具欄按鈕，就更精細了；如果控制的顆粒度達到頁面元素或界面控件的程度，就是最細顆粒度的權限控制了。是以無論你叫資源還是功能、操作，都沒有差別，你要控制的就是那些東西，隻需要你描述出來，就可以被控制。

3、關于資料權限：

資料權限的授權相對功能權限來說，是完全不同的兩種類型。如何為資料授權，這必須從資料權限的本質出發，從如何鑒别資料出發，隻有能夠像鑒别資源一樣對資料加以鑒别，我們才能對資料進行正确的授權。

如果我們抛開資料值的不同（值的不同不是本質的不同）來分析資料，就會發現在一般場景中，資料的不同首先是業務類型的不同。譬如：訂單資料、結算資料、生産計劃資料等等。對于同一類型資料，還可以以産生資料的對象：業務部門、業務人員加以區分，這也是經常遇到的需求：經理可以看到所有的訂單，業務員隻能看自己的。什麼叫全部？什麼叫自己的？前一個概念對于不同的業務部門，實際的内容往往并不相同，A經理的全部訂單指的是A部門的訂單；而B經理的全部訂單則是B部門的訂單。至于所謂的“自己的”，就更加明顯是一個相對概念了。張三的和李四的一般來說是不存在交集的。但有時候，也有一些絕對性的需求，譬如要求C部門的張三要管A部門訂單的稽核，同樣C部門的王五則負責B部門。

這樣，資料權限的授權必須要從相對和絕對兩個次元進行定義，才能做到邏輯完備。是以模型中也通過兩張表來描述資料權限，在相對模式中，用Mode字段來描述不同的顆粒度，而在絕對模式中使用者可以直接指定部門或使用者的ID。此外，用ModuleId字段來定義資料的類型，也就是産生業務的子產品，這個字段所包含的邏輯不僅是差別資料的業務類型，更重要的是為應用資料權限提供依據。

4、關于權限的應用：

本人在項目中，功能權限和資料權限都應用在資料通路層，利用資料庫函數傳回給應用程式被授權的資源或功能的ID集合。應用程式根據ID集合通過反射加載資源或功能，達到使用者不能通路非授權資源的目的。資料權限的應用方法也差不多，将資料庫函數join到業務表上去，未授權的業務資料就會被過濾掉，通過join增加的Permission列，則描述了該行資料的讀寫權限為隻讀還是讀寫。