## 背景在[上一篇文章](/ciam-101-intro-authn-sso/)中，我們介紹了身份驗證 (AuthN) 和授權 (AuthZ) 的概念，以及一些令人頭疼的術語：身份、組織、租戶等。組織和租戶對於分組身份來說很不錯，但它們導致了一個絕對的民主：每個人在這個系統中都可以做任何事情。當烏托邦仍然是一個謎時，我們來看看訪問的治理：授權 (AuthZ)。 ### 我們為什麼需要授權？授權 (AuthZ) 回答了“你能做什麼？”這個問題 Notion 是一個很好的例子。對於每個你擁有的頁面，你可以選擇將其設為私有，僅你可訪問，或者與朋友甚至公眾分享。或者，對於一個在線書店，你希望每個人都能查看所有書籍，但客戶只能查看他們自己的訂單，賣家只能管理他們商店中的書籍。 AuthZ 和 AuthN 是複雜業務模型的基本組成部分。它們通常齊頭並進；AuthZ 驗證用戶的訪問，而 AuthN 驗證身份。兩者都是安全系統所必需的。 ## 基本授權模型這是最常見的 AuthZ 模型之一：如果 **IDENTITY** 對 **RESOURCE** 執行 **ACTION**，則 **ACCEPT** 或 **DENY**。在 Notion 示例中，模型是 **PERSON** 對 **PAGE** 執行 **VIEW**。如果該頁面是私有的： - 當你對你的 **PAGE** 執行 **VIEW** 時，你會收到 **ACCEPT**。 - 其他人進行對你的 **PAGE** 執行 **VIEW** 時應收到 **DENY**。基於共識，行業發展出了各種授權技術，例如基於角色的訪問控制 (RBAC)，基於屬性的訪問控制 (ABAC)。今天，我們將關注 [NIST RBAC 模型](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) 第1級：平面RBAC。 ## 基於角色的訪問控制 NIST RBAC 模型留下了許多開放的地方，以便為各種情境提供靈活性和適應性。Logto 現在採用了第 1 級定義，並增加了 "Resource" 的概念（即 API Resource）。讓我們擴展書店示例。假設我們有很多顧客，只有一個賣家： - 顧客可以查看和訂購書籍，並查看他們自己的訂單。 - 賣家可以查看、創建和刪除書籍，並管理客戶訂單。 ### 定義資源在 Logto 中，資源（即API資源）通常代表一組實體或項目，因為它要求使用有效的URL作為指示器。因此，我們定義了兩個資源： - 圖書：`https://api.bookstore.io/books` - 訂單：`https://api.bookstore.io/orders` 強制執行URL格式的一個優勢是它可以映射到你的API服務的真實地址，這可以改善與系統中其他組件集成時的可讀性和可識別性。 🤔 資源應根據業務需求劃分。沒有一刀切的方法；決策應根據具體情況做出。本文章中將圖書和訂單分開的示例可能適合於微服務，但不適合單體架構。 ### 定義許可權由於我們引入了資源的概念，在 Logto 中，我們也強調許可權必須屬於資源，相反，資源可以擁有許可權。讓我們為資源添加一些許可權： - 圖書：`read`, `create`, `delete` - 訂單：`read`, `read:self`, `create:self`, `delete` 雖然對許可權的名稱沒有要求，但我們有如下約定： ``` [:] ``` 雖然 `` 是描述許可權所需的，但 `:` 可以被忽略來描述一般目標，即資源中的所有實體或項目。例如： - 資源 Books 中的許可權 `read` 意味著閱讀任意圖書的操作。 - 資源 Orders 中的許可權 `create:self` 意味著創建屬於當前用戶的訂單的操作。 ### 定義角色簡而言之，角色就是一組許可權。讓我們創建兩個角色 `customer` 和 `seller`，並為其分配如下許可權： ```mermaid erDiagram Role-Customer { permission Books "read" permission Orders "read:self" permission Orders "create:self" } Role-Seller { permission Books "read" permission Books "create" permission Books "delete" permission Orders "read" permission Orders "delete" } ``` 你可能注意到許可權-角色分配是多對多的關係。 ### 將角色賦予用戶就像角色-許可權分配一樣，用戶-角色分配也是多對多的關係。因此，你可以將多個角色分配給單個用戶，也可以將單個角色分配給多個用戶。 ### 連接點這是 Logto 中第1級RBAC模型的完整關係圖： ```mermaid erDiagram User }|--|{ Role : maps Role }|--|{ Permission : maps "API Resource" ||--|{ Permission : contains ``` 在 RBAC 模型中，許可權總是“肯定的”，這意味著授權判斷很簡單：如果用戶擁有許可權，則接受；否則，拒絕。假設 Alice 擁有 `seller` 角色，Bob 和 Carol 擁有 `customer` 角色。我們將先用自然語言描述操作，然後將它們轉譯為標準授權格式：**IDENTITY** 對 **RESOURCE** 執行 **ACTION**，最終得出結論。 - Alice 想要新增一本出售的書： - 用戶 Alice 對資源 Books（`https://api.bookstore.io/books`）執行 `create`。 - 由於 Alice 根據他們的 `seller` 角色被分配了 Books 的 `create` 許可權，結果是 ✅ **ACCEPT**。 - Alice 想查看所有訂單以查看銷售是否達到預期： - 用戶 Alice 對資源 Orders（`https://api.bookstore.io/orders`）執行 `read`。 - 由於 Alice 根據他們的 `seller` 角色被分配了 Orders 的 `read` 許可權，結果是 ✅ **ACCEPT**。 - Bob 想瀏覽書單以查看是否有他想購買的書。 - 用戶 Bob 對資源 Books（`https://api.bookstore.io/books`）執行 `read`。 - 由於 Bob 根據他們的 `customer` 角色被分配了 Books 的 `read` 許可權，結果是 ✅ **ACCEPT**。 - Bob 想查看 Carol 的訂單。 - 由於這是別人的訂單，`Orders` 的 `read:self` 許可權在這裡不起作用。 - 用戶 Bob 對資源 Orders（`https://api.bookstore.io/order`）執行 `read`。 - 由於 Bob 沒有 Orders 的 `read` 許可權，結果是 ❌ **DENY**。 ### 其他RBAC級別 NIST RBAC模型共有四個級別： - 平面RBAC - 分層RBAC - 約束RBAC - 對稱RBAC 如果你感興趣，請查看[論文](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf)以獲取詳細信息。 Logto 現在擁有第 1 級的實施，將根據社區反饋逐步升級到更高級別。如果更高級別適合你的需求，請隨時告訴我們！ ## 實踐中除理論之外，我們仍有大量技術工作需要完成，以便使模型按預期運行： - 客戶端和身份驗證服務器的開發 - RBAC的數據庫設計 - 不同服務之間的驗證 - 安全性和開放標準合規性 - 角色、許可權、資源管理和分配不要驚慌。我們已經考慮到這一點，並添加了開箱即用的支持來涵蓋以上所有內容。查看 [🔐 RBAC 配方](https://docs.logto.io/docs/recipes/rbac/) 以了解如何在 Logto 中使用 RBAC。 ## 結尾筆記 RBAC 是大多數情況下的一個強大的訪問管理模型，但它並不是萬能的。我們仍然有一些問題： - 我需要高等級的RBAC嗎？ - RBAC與其他授權模型相比如何？ - 如何在不同的組織之間定義授權模型？ 🔥 敬請關注。我們將在CIAM 103中見！