CIAM 102: 授權 & 基於角色的訪問控制

背景#

在上一篇文章中，我們介紹了身份驗證 (AuthN) 和授權 (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 模型 第1級：平面RBAC。

基於角色的訪問控制#

讓我們擴展書店示例。假設我們有很多顧客，只有一個賣家：

• 顧客可以查看和訂購書籍，並查看他們自己的訂單。
• 賣家可以查看、創建和刪除書籍，並管理客戶訂單。

定義資源#

在 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

雖然對許可權的名稱沒有要求，但我們有如下約定：

雖然 <action> 是描述許可權所需的，但 :<target> 可以被忽略來描述一般目標，即資源中的所有實體或項目。例如：

• 資源 Books 中的許可權 read 意味著閱讀任意圖書的操作。
• 資源 Orders 中的許可權 create:self 意味著創建屬於當前用戶的訂單的操作。

定義角色#

簡而言之，角色就是一組許可權。讓我們創建兩個角色 customer 和 seller，並為其分配如下許可權：

你可能注意到許可權-角色分配是多對多的關係。

將角色賦予用戶#

就像角色-許可權分配一樣，用戶-角色分配也是多對多的關係。因此，你可以將多個角色分配給單個用戶，也可以將單個角色分配給多個用戶。

連接點#

這是 Logto 中第1級RBAC模型的完整關係圖：

在 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

如果你感興趣，請查看論文以獲取詳細信息。

Logto 現在擁有第 1 級的實施，將根據社區反饋逐步升級到更高級別。如果更高級別適合你的需求，請隨時告訴我們！

實踐中#

除理論之外，我們仍有大量技術工作需要完成，以便使模型按預期運行：

• 客戶端和身份驗證服務器的開發
• RBAC的數據庫設計
• 不同服務之間的驗證
• 安全性和開放標準合規性
• 角色、許可權、資源管理和分配

不要驚慌。我們已經考慮到這一點，並添加了開箱即用的支持來涵蓋以上所有內容。查看 🔐 RBAC 配方 以了解如何在 Logto 中使用 RBAC。

結尾筆記#

RBAC 是大多數情況下的一個強大的訪問管理模型，但它並不是萬能的。我們仍然有一些問題：

• 我需要高等級的RBAC嗎？
• RBAC與其他授權模型相比如何？
• 如何在不同的組織之間定義授權模型？