許可權系統設計
許可權系統(1)--基本模式
在系統中發生的事情,抽象的說都是某個主體(subject)在某個資源(resource)上執行了某個操作(operation)。
subject --[operation]--> resource
所謂許可權管理,就是在這條資訊傳遞路徑中加上一些限制性控制。
主體試圖去做的 limited by 系統允許主體去做的 = 主體實際做的。
可以看到,許可權控制基本對應於filter模式。subject試圖去做的事情應該由業務邏輯決定,因而應該編碼在業務系統中。
先考慮最粗粒度的控制策略,控制點加在subject處,即無論從事何種操作,針對何種資源,我們首先需要確認subject是受控的。只有通過認證的使用者才能使用系統功能,這就是authentication。boolean isAllowed subject)
稍微複雜一些,控制可以施加在subject和operation的邊界處(此時並不知道具體進行何種操作),稱為模組訪問控制,即只有某些使用者才能訪問特定模組。isAllowed(subject, operation set)
第三級控制直接施加在operation上,即操作訪問控制。operation知道resource和subject(但它尚沒有關於resource的細節知識),我們能夠採取的許可權機制是bool isAllowed(subject, operation, resource), 返回true允許操作,返回false則不允許操作。
最簡單的情況下,subject與resource之間的訪問控制關係是靜態的,可以直接寫成一個許可權控制矩陣
for operationA:
resourceA resourceB
subjectA 1 0
subjectB 0 1
isAllowed(subjectA, resourceA)恆等於true
如果多個operation的許可權控制都可以通過這種方式來表示,則多個許可權控制矩陣可以疊加在一起
for operationA, operationB:
resourceA resourceB
subjectA 10 01
subjectB 01 11
當subject和resource的種類很多時,許可權控制矩陣急劇膨脹,它的條目數是N*M。很顯然,我們需要進行矩陣分解。這也是最基本的控制手段之一: 在系統中增加一個瓶頸,或者說尋找到隱含的結構。
subject_resource = subject_role * role_resource
這樣系統許可權配置條目的數量為 N*R + R*M, 如果R的數目遠小於subject和resource,則實現簡化。這稱為RBAC(role based access control),它的一個額外好處是許可權系統的部分描述可以獨立於subject存在,即在系統中沒有任何使用者的時候,通過角色仍然可以表達部分許可權資訊。可以說角色是subject在許可權系統中的代理(分解)。
有時候引入一個瓶頸還不過癮,有人引入組的概念,與role串聯,
subject_resource = subject_group_role * role_resource
或著group與role並聯,
subject_resource = subject_group * group_resource
與role稍有不同,一般情況下group的業務含義更加明顯,可能對應於組織結構等。將組織機構明確引入許可權體系,有的時候比較方便,但對於許可權系統自身的穩定性而言,未見得有什麼太大的好處。並聯模式有些多餘,串聯模式又過於複雜,細節調整困難,特別是多條控制路徑造成的衝突情況。一般情況下,我不提倡將group引入許可權控制中。
比操作控制更加深入的控制就是資料控制了,此時需要對於resource的比較全面的知識。雖然表面上,仍然是
boolean isAllowed(subject, operation, resource),但控制函式需要知道resource的細節。例如行級控制(row-level)或者列級控制(column-level)的實現。因為我們一般情況下不可能將每一個條目都建模為獨立的resource,而只能是存在一個整體描述,例如所有密級為絕密的文件。在witrix平臺中,資料控制主要通過資料來源的filter來實現,因為查詢條件(資料的定位條件)已經被物件化為Query類,所以我們可以在合適的地方自由的追加許可權控制條件。
以上的討論中,許可權控制都是根據某些靜態描述資訊來進行的,但現實世界是多變的。最簡單的,當subject從事不同業務時,對應於同一組資源,也可能對應的許可權控制並不同(在witrix平臺中,對應於IDataSource的模式切換)。更復雜一些, 在不同的時刻, 我們需要根據其他附加資訊來作出是否允許操作的判斷, 即此時我們許可權設定的不僅僅是一些靜態的描述資訊, 而是一個完整的控制函式, 這就是所謂的工作流許可權控制,一種動態許可權控制.
相關文章
- 許可權系統:許可權應用服務設計
- 許可權系統:6個許可權概念模型設計模型
- 許可權系統:許可權應用服務設計Tu
- 許可權系統設計(2)--operation
- 許可權系統設計(3)-- subject
- 許可權系統設計(4)--resource
- 許可權系統設計--概論
- 使用者許可權設計(三)——通用資料許可權管理系統設計
- 關於許可權系統的設計
- Oracle的物件許可權、角色許可權、系統許可權Oracle物件
- 續:關於許可權系統的設計
- 許可權系統設計(1)--基本模式模式
- 許可權系統設計(5)--動態性
- 系統許可權資料庫設計方案資料庫
- 分散式系統中,許可權設計實踐分散式
- 關於系統許可權的設計-位操作
- Android系統許可權和root許可權Android
- 許可權系統:一文搞懂功能許可權、資料許可權
- 適配懸浮窗許可權與系統設定修改許可權
- MySQL許可權系統MySql
- Oracle系統許可權Oracle
- 手把手擼套框架-許可權系統設計框架
- learun通用許可權系統框架功能實現設計框架
- 管理系統之許可權的設計和實現
- Spring Security + jwt 許可權系統設計,包含SQLSpringJWTSQL
- ASP.NET系統使用者許可權設計ASP.NET
- 許可權系統設計的理論基礎--RBAC
- Linux系統程式設計(七)檔案許可權系統呼叫Linux程式設計
- Oracle 使用者、物件許可權、系統許可權Oracle物件
- 最近對就有系統人員許可權升級計劃――也談人員許可權的設計。
- 許可權管理系統的設計案例 -- 需求定義(2)
- 許可權管理系統的設計案例 -- 需求定義(3)
- 許可權管理系統的設計案例 -- 需求定義(4)
- 如何設計應用系統的資料許可權管理
- mongodb 的許可權系統MongoDB
- 【JavaWeb】許可權管理系統JavaWeb
- 有贊許可權系統
- Android系統許可權Android