使用者許可權設計(三)——通用資料許可權管理系統設計

paulchenbo發表於2007-02-27
通用資料許可權管理系統設計
 
作者：逸雲
 
前言：
 本文提供一種整合功能許可權和資料許可權的解決方法，以滿足多層次組織中許可權管理方面的集中控制。本方法是RBAC（基於角色的訪問控制方法）的進一步擴充套件和延伸，即在功能許可權的基礎上增加資料許可權的管理，實現資料許可權和功能許可權的集中處理。
 
解釋：
 功能許可權：能做什麼的問題，如增加銷售訂單；
 資料許可權：能在哪裡幹什麼的問題，如察看北京分公司海淀銷售部張三的銷售訂單；
 
術語：
 資源：系統中的資源，主要是各種業務物件，如銷售單、付款單等；
 操作型別：對資源可能的訪問方法，如增加、刪除、修改等；
 功能：對資源的操作，是資源與操作型別的二元組，如增加銷售單、修改銷售單等；
 資料型別：業務系統中常用的資料許可權型別，如公司、部門、專案、個人等；
 資料物件：具體的業務物件，如甲公司、乙部門等等，包括所有涉及到資料許可權的物件值；
 許可權：角色可使用的功能，分角色的功能許可權和角色的資料許可權；
 角色：特定許可權的集合；
 使用者：參與系統活動的主體，如人，系統等。
 
 
通用資料許可權管理系統設計（二）
 
方法說明：
 在實際應用中，資料許可權的控制點一般相對固定，如針對公司、部門、個人、客戶、供應商等，也就是說資料許可權一般針對指定資料型別下的一些資料物件。
 
 本方法中，資料許可權的依賴於功能許可權，是對功能許可權的進一步描述，說明角色在指定的功能點上的資料控制許可權。
本方法中採用“沒有明確規定即視為有效”的原則，如果沒有定義功能的資料許可權，則說明該角色具有該功能的全部的許可權。如果定義了功能的某種型別的資料許可權，則該使用者只具有該型別下指定資料的資料許可權。
 
 這段話比較繞口，下面舉個例子實際例子。
 
 某公司有北京銷售部、上海銷售部和廣州銷售部三個銷售部，現在需要定義幾種角色：
    銷售總監      -- 能察看所有銷售部的銷售訂單；
    北京銷售經理 -- 只能察看北京銷售部的所有銷售訂單；
    上海銷售經理 -- 只能察看上海銷售部的所有銷售訂單；  
    廣州銷售經理 -- 只能察看廣州銷售部的所有銷售訂單；  
 
 上述角色的定義如下：
 
     -------------------------------------------------------------------
     角色名稱             功能             資料型別     資料物件  
     -------------------------------------------------------------------
     銷售總監           察看銷售訂單                                 
     北京銷售經理       察看銷售訂單         部門         北京  
     上海銷售經理       察看銷售訂單         部門         上海     
     廣州銷售經理       察看銷售訂單         部門         廣州     
     -------------------------------------------------------------------
 
    上述定義中，銷售總監只定義了功能許可權，而沒有定義資料許可權，所以銷售總監能夠察看所有的銷售訂單；而其他幾位銷售經理分別定義了這一功能的資料許可權，所以只能察看指定部門的銷售訂單。
 
     在實際應用中，往往會出現部門分組，組長能夠察看本組所有人員處理的銷售訂單的情況，以及某些情況下，某些人只能察看本人的銷售訂單的情況，這些特殊情況在上述的說明中無法解決，需要在設計和實現中進行處理。
 
 
    北京銷售代表 -- 只能察看北京銷售部的本人的所有銷售訂單；  
     北京銷售代表         察看銷售訂單           部門            北京     
                                                 個人                  
 
 
通用資料許可權管理系統設計（三）--資料庫設計
 
我們先來看看傳統的基於角色的許可權管理系統，如下圖所示，最簡單的基於角色的許可權管理由系統功能、系統角色、系統使用者、角色功能和使用者角色五部分組成。
    圖一：基於角色的資料庫結構
為實現資料許可權控制，在設計上對基於角色的許可權管理進行擴充，如下圖所示：
 
圖二：通用資料許可權管理系統資料庫設計
對比兩張圖，我們可以看到，他們之間的主要變化為：
1、 增加系統資源資訊和操作型別資訊，系統資源為樹形結構、如銷售模組、銷售訂單等；操作型別記錄可能的操作，如增加、刪除、修改、檢視、查詢等，系統功能是資源與操作型別的組合，對資源的操作就是系統功能。
2、 增加資料物件型別和資料物件兩張表，資料物件型別記錄系統中需要控制的物件型別，如部門、庫房、員工、客戶、供應商等；資料物件記錄各物件型別的物件例項，如北京銷售部、上海銷售部、張三、李四等等。（獨立儲存的好處後面會說到）
3、 增加系統資源與資料物件型別的關聯表（多對多），本表為配置表，說明某種資源可能需要的控制點，如銷售訂單與部門型別的關聯可能涉及到分部門分配許可權；銷售訂單與客戶的關聯可能涉及到按客戶分配許可權等等。
4、 增加資料物件與角色許可權的關聯，這張表是真正最終實現資料許可權管理的所在地。
 
通過這種設計，能夠最小化地減少對原有許可權系統的更改，並且可以很靈活地增加資料的控制點。在產品化軟體的設計中使用，能夠靈活滿足客戶的需要。
 

相關文章