掌握 Logto 中的 RBAC：一個全面的實際例子

簡介#

訪問控制和安全性是現代應用程序的重要方面，確保用戶獲得適當的資源訪問權限。Logto 的基於角色的訪問控制（RBAC）為開發人員提供了一種有效的方式來管理應用程序中的訪問控制和安全性。在本文中，我們將通過一個現實世界的例子探索 Logto RBAC 的強大功能，幫助你理解並將這些概念應用到你的項目中。

通過分析前端和後端代碼片段，你將獲得將 Logto 的 RBAC 集成到你的應用程序堆棧中的全面視角。到本文結尾，你將能夠充分利用 Logto 的 RBAC 功能來增強你的項目的安全性和訪問控制。

引入 BookHarber：一個線上書店的使用案例#

為了有效展示 Logto 的 RBAC 功能，我們將使用一個線上書店的實例：BookHarber。BookHarber 為客戶和員工提供了一系列功能，確保流暢且安全的購物體驗。

BookHarber 的主要功能包括：

1. 瀏覽和購買書籍：用戶可以輕鬆搜索和購買來自不同類型和作者的書籍。
2. 訂單管理和物流跟蹤：註冊客戶可以管理訂單、跟蹤配送並獲得購買更新。
3. 特別優惠和節日活動：BookHarber 在特別活動和節日期間提供獨家折扣和促銷活動，以吸引並回饋其客戶群。
4. 客戶支持：客戶可以開啟支持票據以解決任何問題，並獲得 BookHarber 員工的及時協助。
5. 客戶管理：擁有不同角色的員工可以管理平台的各個方面，例如客戶帳戶、訂單處理和問題解決。

角色#

在 BookHarber 生態系統中，我們可以識別幾個關鍵用戶角色，例如：

1. 訪客：未註冊的用戶可以瀏覽網站、搜索書籍和查看特別優惠。
2. 客戶：已註冊的用戶可以購買書籍、管理訂單、跟蹤物流和開啟支持票據。
3. 店鋪管理員：負責監督平台整體管理和運營的員工，擁有完整访问權限。
4. 圖書管理員：負責書籍和類別管理的員工。
5. 客戶服務專員：負責回复支持票據的員工。
6. 第三方物流供應商：負責管理和跟蹤訂單配送的外部合作夥伴。
7. 市場營銷員：負責推廣 BookHarber，負責管理特別優惠和活動的員工。

設計 BookHarber REST API 的範疇#

為了有效實施 Logto 的 RBAC 系統，我們需要設計與各種 REST API 對應的範疇。範疇是定義特定角色對每個 API 接口的訪問級別的許可。通過將適當的範疇分配給每個用戶角色，我們可以確保用戶僅能訪問與其角色相關的操作和資源。

讓我們為以下 REST API 設計範疇：

1. 類別 API：

• create:categories: POST /categories
• write:categories: PUT /categories/:id
• delete:categories: DELETE /categories/:id
• list:categories: GET /categories

2. 書籍 API：

• create:books: POST /books
• write:books: PUT /books/:id
• delete:books: DELETE /books/:id
• list:books: GET /books
• read:books: GET /books/:id

3. 客戶 API：

• list:customers: GET /customers
• write:customers: PUT /customers/:id
• delete:customers: DELETE /customers/:id
• read:customers: GET /customers/:id

4. 訂單 API：

• create:orders: POST /orders
• list:orders: GET /orders
• read:orders: GET /orders/:id
• write:orders: PUT /orders/:id

5. 活動 API：

• create:events: POST /events
• write:events: PUT /events/:id
• list:events: GET /events
• delete:events: DELETE /events/:id

6. 訂單跟蹤 API：

• read:orderTracks: GET /orders/:id/tracks
• create:orderTracks: POST /orders/:id/tracks
• write:orderTracks: PUT /orders/:id/tracks/:trackId

7. 票據 API：

• create:tickets: POST /tickets
• list:tickets: GET /tickets
• read:tickets: GET /tickets/:id
• write:tickets: PUT /tickets/:id

將範疇分配給角色#

現在我們已經為每個 REST API 定義了適當的範疇，我們可以將這些範疇分配給 BookHarber 生態系統中的相關用戶角色：

理解 "list" 和 "read" 範疇之間的區別#

為了進一步說明在 REST API 設計和 RBAC 中的 "list" 和 "read" 範疇之間的差異，讓我們考慮一個涉及線上書店 BookHarber 的實際示例。

假設 BookHarber 有兩類用戶：客戶和客戶服務專員。客戶可以創建訂單，而客戶服務專員則負責幫助客戶處理他們的訂單。讓我們看看在此場景中如何應用 orders API 資源的 "list" 和 "read" 範疇。

1. List 範疇："list" 範疇允許用戶訪問系統中的實體集合。例如，list:orders 範疇允許用戶檢索所有可用訂單的列表。在 BookHarber 中，這個範疇對於需要系統中所有訂單概覽的店鋪管理員或其他員工很有用。然而，客戶服務專員不應能夠訪問整個訂單列表，因為他們的角色是幫助個別客戶處理具體的訂單。
2. Read 範疇："read" 範疇為用戶提供訪問具有給定 ID 的單一實體的權限。例如，read:orders 範疇允許用戶通過其 ID 查看特定訂單的詳細信息。對於 BookHarber 的情況，這個範疇非常適合需要訪問特定客戶訂單信息的客戶服務專員。當客戶開啟支持票據時，客戶服務專員可以使用票據中提供的訂單 ID 訪問並查看該特定訂單的詳情。

理解所有權：為什麼客戶不需要 "read" 或 "list" 範疇來查看自己的訂單#

在很多應用程序中，用戶通常能夠在未獲得相應的 "read" 或 "list" 範疇的情況下訪問自己的資源。這是因為用戶被視為這些資源的所有者，應自然能夠訪問它們。在我們的 BookHarber 例子中，客戶可以創建訂單但沒有 "read:orders" 或 "list:orders" 範疇。

所有權的概念在定義 REST API 特定資源的訪問控制中起著關鍵作用。通過承認用戶始終可以訪問自己的資源，我們可以實施更高效且安全的訪問控制，而無需授予不必要的許可。在 BookHarber 的情況中，這意味著客戶仍然可以查看和管理他們的訂單，而不需要任何附加的範疇。

為了演示這種工作原理，讓我們考慮 GET /orders Endpoint：

1. 如果用戶擁有 list:orders 範疇（例如，店鋪管理員或員工），他們將能夠查看系統中的所有訂單。這為他們提供了根據其角色所需的訂單數據全景。
2. 如果用戶沒有 list:orders 範疇（例如，普通客戶），系統將僅返回屬於該用戶的訂單。這確保客戶能夠訪問他們的訂單信息，而不被授予不必要的許可。

通過實施基於所有權的訪問控制，API 能夠向不同用戶角色提供合適的訪問級別，同時維持安全性和量身定制的用戶體驗。在 BookHarber 的情景中，所有權模型允許客戶訪問他們的訂單信息，而無需 "read:orders" 或 "list:orders" 範疇，簡化了訪問控制設計，並增強了整體用戶體驗。

在 Logto Console 中配置設置#

要在 Logto 的 Console 完成配置，請按照以下步驟進行：

1. 為 React 創建一個單頁應用（SPA）：在 Logto Console 中為你的 React 應用設置一個 SPA。
2. 創建 API 資源：添加一個新的 API 資源，標識符為 https://api.bookharber.com。
3. 為資源定義範疇：在新創建的 API 資源下創建必要的範疇。
4. 創建角色並分配範疇：為你的應用定義用戶角色，並將適當的範疇分配給每個角色。
5. 將角色分配給用戶：將相關角色分配給應用中的用戶，確保每個用戶（特別是員工）都擁有根據其角色所需的正確許可。

使用範疇保護 API#

在我們的示例項目 BookHarber 中，我們使用 Express 作為後端服務，React 作為前端網頁。本節將簡要介紹如何將 Logto 的 RBAC 功能集成到這些流行技術中，以保護我們的應用程序。

完整文檔：https://docs.logto.io/docs/recipes/rbac/protect-resource

前端#

要在你的 React 應用程序中初始化 Logto，請參考此處提供的文檔：https://docs.logto.io/docs/recipes/integrate-logto/react/

除了基本設置，你還需要在配置中指定 "resource" 和 "scopes"：

以下是如何使用 Logto 發送 API 請求的示例：

後端#

要保護 API，請參考：https://docs.logto.io/docs/recipes/protect-your-api/

除了示例代碼（https://docs.logto.io/docs/recipes/protect-your-api/node），我們需要添加範疇驗證：

結論#

Logto 的 RBAC 系統是現代應用程序中管理訪問控制和安全性的強大工具。通過利用 Logto 的 RBAC 功能，你可以確保用戶根據其角色獲得適當的資源訪問權限，從而保護敏感數據和功能免受未授權訪問。

在本文中，我們探索了一個線上書店 BookHarber 的真實案例，並演示了如何設計範疇、將其分配給用戶角色，以及在應用程序的前端和後端實施 Logto 的 RBAC 功能。

通過將這些概念和技術應用到你的項目中，你可以增強應用程序的安全性和訪問控制，提供流暢且安全的用戶體驗。無論你正在開發一個電子商務平台、內容管理系統，或任何其他需要角色訪問控制的項目，Logto 的 RBAC 系統都提供了一種靈活而高效的解決方案，以滿足你的訪問控制需求。