## 背景在 [前一篇文章](/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) 的第一級：扁平 RBAC。 ## 基於角色的存取控制 NIST RBAC 模型留下了許多開放性的事項，以提高靈活性和適應性以用於各種場景。Logto 現在採用第一級定義，並增加了一個 "Resource"（即 API 資源）的概念。讓我們擴展書店的例子。假設我們有很多顧客，但只有一個賣家： - 顧客可以查看和訂購書籍，以及查看自己的訂單。 - 賣家可以查看、創建和刪除書籍，並管理客戶訂單。 ### 定義資源在 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` 雖然權限名稱沒有要求，但我們有以下慣例： ``` [:] ``` 當 `` 是必需用來描述權限時，`:` 可以忽略以描述一般目標，即資源中的所有實體或項目。例如： - 權限 `read` 在資源書籍中意味著可以閱讀任意書籍的動作。 - 權限 `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 中第一級 RBAC 模型的完整關係圖： ```mermaid erDiagram User }|--|{ Role : maps Role }|--|{ Permission : maps "API Resource" ||--|{ Permission : contains ``` 在 RBAC 模型中，權限總是 "正向" 的，意味著授權判斷很簡單：如果用戶擁有權限，則接受；否則拒絕。我們假設 Alice 有角色 `seller`，Bob 和 Carol 有角色 `customer`。我們將首先用自然語言描述動作，並將它們翻譯成標準授權格式：**IDENTITY** 在 **RESOURCE** 上執行 **ACTION**，最終得出結論。 - Alice 想要添加一個新書進行銷售： - 用戶 Alice 在資源書籍（`https://api.bookstore.io/books`）上執行 `create`。 - 由於 Alice 根據她的角色 `seller` 被分配了書籍的 `create` 權限，結果是 ✅ **接受**。 - Alice 想要查看所有訂單以確定銷售是否符合預期： - 用戶 Alice 在資源訂單（`https://api.bookstore.io/orders`）上執行 `read`。 - 由於 Alice 根據她的角色 `seller` 被分配了訂單的 `read` 權限，結果是 ✅ **接受**。 - Bob 想要瀏覽書籍列表以查看是否有他想購買的書籍。 - 用戶 Bob 在資源書籍（`https://api.bookstore.io/books`）上執行 `read`。 - 由於 Bob 根據他的角色 `customer` 被分配了書籍的 `read` 權限，結果是 ✅ **接受**。 - Bob 想查看 Carol 的訂單。 - 由於這是別人的訂單，訂單的 `read:self` 權限在這裡不起作用。 - 用戶 Bob 在資源訂單（`https://api.bookstore.io/order`）上執行 `read`。 - 由於 Bob 沒有訂單的 `read` 權限，結果是 ❌ **拒絕**。 ### 其他 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 現在已有第一級實現，將根據社群反饋來進展到更高級別。如果更高級別符合你的需求，請隨時告訴我們！ ## 實踐中除了理論，我們仍然需要大量技術工作以確保模型按預期運作： - 客戶端和身份驗證服務器開發 - RBAC 的數據庫設計 - 不同服務間的驗證 - 安全性和開放標準符合性 - 角色、權限、資源的管理和分配不要驚慌。我們已考慮到這一點，並增加了開箱即用的支持來涵蓋以上所有事項。查看 [🔐 RBAC 食譜](https://docs.logto.io/docs/recipes/rbac/) 以了解如何在 Logto 中使用 RBAC。 ## 結語對於大多數案例來說，RBAC 是一種強大的存取管理模型，但並不是萬能解決方案。我們仍然有一些問題： - 我需要高級別的 RBAC 嗎？ - RBAC 與其他授權模型相比如何？ - 如何在不同的組織間定義授權模型？ 🔥 敬請期待。我們會在 CIAM 103 中見到你！