MASA Auth - 許可權設計
許可權術語
-
Subject：使用者，使用者組
-
Action：對Object的操作，如增刪改查等
-
Object：許可權作用的物件，也可以理解為資源
-
Effect：規則的作用，如允許，拒絕
-
Condition：生效條件
-
Permission：允許（拒絕）使用者（使用者組）在條件允許下對物件（資源）的動作
-
Role：許可權集合，許可權數量>=1
RBAC
RBAC (Role-Based Access Control，基於角色的訪問控制)，引入了 Role（角色）的概念，並且將許可權與角色進行關聯。使用者通過扮演某種角色，具有該角色的所有許可權。
即許可權，角色，使用者之間的關係是多對多對多
RBAC0
- 使用者
- 角色
- 許可權
- 會話
使用者和角色的關係是多對多
許可權和角色的關係是多對多
RBAC1
- 角色繼承
- 許可權擴充套件
RBAC2
-
互斥約束
使用者，角色，許可權均可互斥。不允許存在任意衝突。
-
基數約束
角色分配次數受限，比如一個公司只有一個CEO
-
先決條件角色
許可權賦予要從低到高。如：要先有XX副總許可權才能獲取XX總許可權。
-
靜態職責分離（目前先支援靜態職責分離）
使用者無法被賦予衝突的角色
-
動態職責分離
使用者會話中無法啟用衝突的角色
RBAC3
RBAC0 + RBAC1 + RBAC2
ABAC
Attribute Based Access Control，基於屬性的許可權驗證。允許更細粒度的控制X屬性的Y資源在Z條件下進行A操作。相較於RBAC，會對開發人員提出更高的要求，目前我們先只介紹到RBAC。
舉個例子
我們通過預設部落格文章場景來反推實現方式
使用者角色
一篇文章要面對兩種角色，即：讀者，管理員
[{
"Subject": "Avril",
"Roles":["ArticleReader"]
}, {
"Subject": "Dodd",
"Roles":["ArticleManager"]
}]
角色
讀者將獲得讀文章許可權，管理員則獲得管理文章許可權
[ { "Name": "ArticleReader", "Permissions": [ "ReadArticle" ] }, { "Name": "ArticleManager", "Permissions": [ "ManageArticle" ] } ]
許可權
角色有了，依賴的許可權也有了，接下來我們需要繼續把許可權明細確認一下
[
{
"Name": "ReadArticle",
"Effect": "Allow",
"Action": ["Read"],
"Object": ["Article"]
}, {
"Name": "ManageArticle",
"Effect": "Allow",
"Action": ["Create", "Read", "Update", "Delete"],
"Object": ["Article"]
}
]
依賴模型
基於RBAC3的依賴模型
使用者管理
簡單的引入一個RBAC無法滿足一個工程化的專案，比如批量操作，前後端整合等
團隊
單個使用者的管理已經出來了，但日常中我們很少會對單個使用者進行授權。更多的是針對一組（批）人進行操作。
前端整合
到目前為止，我們設計的都還在後端。而前端關心的是頁面展示相關的，比如選單，頁面元素等
等一下！
這裡要設計什麼？或許可以偷個懶，在Objects裡增加一個ObjectType用來區分選單還是頁面元素即可？
ObjectType被修改的可能性很小，所以我們將在SDK中提供列舉來支援
總結
至此，我們把RBAC與使用者管理的部分已經設計完了。或許它缺少了傳統意義上的組織架構樹，但它帶來了更加鬆散的，扁平化的團隊管理。
（本文章不代表最終設計）
開源地址
MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks
MASA.Contrib：https://github.com/masastack/MASA.Contrib
MASA.Utils：https://github.com/masastack/MASA.Utils
MASA.EShop：https://github.com/masalabs/MASA.EShop
MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor
如果你對我們的 MASA Framework 感興趣，無論是程式碼貢獻、使用、提 Issue，歡迎聯絡我們