ACL、RBAC、ABAC
你好開發者。授權是我們構建的每個系統的關鍵部分，而 Casbin 是我們在每種語言中聽到的授權的通用名稱。
Casbin 目前支持 Golang、Java、C/C++、Node.js、Javascript、PHP、Laravel、Python、.NET (C#)、Delphi、Rust、Ruby、Swift (Objective-C)、Lua (OpenResty)、 Dart（Flutter）和 Elixir。
在本文中，我的目標是以簡單易懂的流程演示 casbin 的工作原理及其不同的可用模型配置。
Casbin的工作流程
在進行不同的模型配置之前，讓我們嘗試通過一個簡單的概覽圖來理解 casbin 的工作流程，如下所示。
我已將整個工作流程分爲兩個階段，即配置和實施。
配置階段
這個階段是關於配置的。
第一步（模型）
在這裏，我們根據我們的要求配置模型。我們使用CONF文件（.conf 文件擴展名）來抽象我們的模型配置。此配置基於 PERM 元模型（Policy、Effect、Request、Matchers）（將在下面通過示例進行詳細說明）。
在上圖中，我取了Casbin中最基本最簡單的模型即ACL（後面會講到）
Step2（政策）
在這裏，我們定義了像who can do what和這樣的政策who has what permissions
政策的基本語法是
p= sub, obj, act, eft
此語法可以理解爲 who( sub ) can/cannot( allow / deny ) do what( act ) on some resource( obj )
這裏eft可以是allow或deny。如果不包含，則默認值爲allow。
在上圖中，根據定義的策略
- John 有權讀取 RECORD1
- John 沒有寫入 RECORD1 的權限
- Harry 有權讀取 RECORD1
- Harry 有權寫入 RECORD1
實施階段
此階段是關於根據模型配置[第 1 步] 和列出的策略 [第 2 步] 實施
Step3（請求）
這是用戶嘗試訪問某些資源或對其執行所需操作的實時場景。
在上圖中，根據傳入請求
- 約翰想讀 RECORD1
- 約翰想在 RECORD1 上寫
執行結果
這是在決定是否允許用戶訪問給定資源或對給定資源執行他想要的操作時的實時場景。
Step4（匹配器）
執行結果的第一步是將請求與策略列表相匹配。在上面的示例中，我們有以下匹配器表達式，它只是保證請求中的主題、對象和操作應該與策略規則中的相匹配。
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act
Step5（政策效果）
使用匹配器表達式從策略列表中找到策略後，執行結果的另一個步驟是應用策略效果。在上面的示例中，我們有以下策略效果，這意味着用戶只要有一個匹配的策略允許他這樣做就具有權限
e = some(where (p.eft == allow))
在這兩個步驟之後，casbin 執行結果爲
- John 可以閱讀 RECORD1 ✔️
- John 被拒絕在 RECORD1 上寫文章 ❌
更深入
我希望上面的簡單概述能在一定程度上幫助可視化 Casbin 的工作流程。現在我們將看到配置模型的不同方法[根據上圖的第 1 步]
訪問控制的類型
訪問控制列表 (ACL)
這是最基本的訪問控制機制。這列出了每個用戶對給定資源的權限的 1–1 映射。
If there are total three users;user1,user2,user3. There is a permissions defined for each users individually.
user1 can only read record1
user2 can only write record1
user3 can read and write record1
Casbin模型配置
# Request definition
[request_definition]
r = sub, obj, act
# Policy definition
[policy_definition]
p = sub, obj, act
# Policy effect
[policy_effect]
e = some(where (p.eft == allow))
# Matchers
[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act
r = sub, obj, act提供有關誰（ sub ）想要對某些資源（ obj ）做什麼（ act ）的信息p = sub, obj, act提供有關誰（ sub ）可以對某些資源（ obj ）做什麼（ act ）的信息
政策效應
e = some(where (p.eft == allow))意味着用戶只要有一個匹配策略允許他這樣做就具有權限。
其他一些變化
e = !some(where (p.eft == deny))意味着只要沒有拒絕他這樣做的匹配策略，用戶就有權限e = some(where (p.eft == allow)) && !some(where (p.eft == deny))表示只要有一個匹配策略，沒有匹配的拒絕策略，用戶就有權限。
匹配器
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act 定義授權的工作流程。它檢查用戶是否可以在給定資源上執行給定操作（他正在嘗試執行）。換句話說，根據請求評估策略規則。在上面的匹配器中，請求中的主題、對象和操作應該與策略規則中的相匹配，以便向用戶授予訪問權限。
基於角色的訪問控制 (RBAC)
這解決了之前需要的上述 1-1 映射。現在我們將用戶分配到角色中，並將權限分配給角色而不是單個用戶。
If there are total three users;user1,user2,user3 and two role;admin and user. In this case we define permission to the role not to the individual user.
user1,user2 has role user
user3 has role admin
user can only read record1 (user1,user2)
admin can read and write write record1 (user3)
Casbin模型配置
[request_definition]
r = sub, obj, act
[policy_definition]
p = sub, obj, act
[role_definition]
g = _, _
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
與之前相同，但我們g在此處添加了參數
g = _, _定義用戶的角色。
// user1 is a admin and admin can write record1 which means user1 can write record1
p, admin, record1, write
g, user1, admin
具有資源角色的 RBAC
就像我們將用戶分組到角色中一樣，我們也可以將資源分組並分配它們，而不是一次分配一個資源。
[request_definition]
r = sub, obj, act
[policy_definition]
p = sub, obj, act
[role_definition]
g = _, _
g2 = _, _
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = g(r.sub, p.sub) && g2(r.obj, p.obj) && r.act == p.act
這裏我們在g2這裏添加了參數
g2 = _, _定義資源的角色。
// record1 and record2 is grouped to record and user1 can write record which means user1 can write record1 and record2 both
p, user1, record, write
g2, record1, record
g2, record2, record
帶域的 RBAC（租戶）
這是 RBAC 的另一個版本，當系統中有多個租戶並且用戶在不同的租戶中具有不同的角色時，它可能是必不可少的。
[request_definition]
r = sub, dom, obj, act
[policy_definition]
p = sub, dom, obj, act
[role_definition]
g = _, _, _
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = g(r.sub, p.sub, r.dom) && r.dom == p.dom && r.obj == p.obj && r.act == p.act
//user1 is admin in tenant1 and user2 is admin in tenant2. Admin in tenant1(which means user1) can read and write data1. Similarly Admin in tenant2(which means user2) can read and write data2. This also means user1 has no permission to read/write data2 and viceversa.
p, admin, tenant1, data1, read
p, admin, tenant1, data1, write
p, admin, tenant2, data2, read
p, admin, tenant2, data2, write
g, user1, admin, tenant1
g, user2, admin, tenant2
基於屬性的訪問控制 (ABAC)
如果您的用例無法通過上述任何模型解決，還有另一種模型可以提供更精細的搜索/匹配器。評估是基於特定屬性（如用戶屬性）完成的。在 casbin 的情況下，屬性可以是主題、對象或操作的屬性。
例如，RBAC 系統向所有經理授予訪問權限，但 ABAC 策略將僅向財務部門的經理授予訪問權限
[request_definition]
r = sub, obj, act
[policy_definition]
p = sub, obj, act
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = r.sub == r.obj.Owner
此模態配置僅檢查請求的用戶是否是該請求對象的所有者。
//If Following Request
user1, {Owner:"user1"}
user1, {Owner:"user2"}
//Mapping the request to sub,obj,act
sub= user1
obj= {Owner:"user1"}
//Matchers we have
r.sub == r.obj.Owner
user1 == user1 // 1st Request is given access
user1 == user2 // 2nd Request is not given access as he is not the owner of that resource
同樣，還有更多模型可用於不同的用例。我的目標是讓您開始使用 casbin。現在我希望您可以繼續通過本文檔學習更深入的知識，或者在casbin 在線編輯器中練習模型和策略。
結論
對casbin的理解就到此爲止了。我們將在下一篇文章中繼續這段從理解 casbin 到在 golang 中實現 casbin 的旅程。希望這篇文章對我的讀者有所幫助。任何類型的建議都將不勝感激。快樂編碼。
如果你喜歡我的文章，點贊，關注，轉發！