精通 Logto 中的 RBAC:一個全面的實際範例
本文提供了一個關於掌握 Logto 中基於角色的訪問控制 (RBAC) 的全面指南,使用一家線上書店的實際範例來探索主要的用戶角色、範圍,以及在前端和後端應用中整合 Logto 的 RBAC 功能以增強安全性和訪問控制。
介紹
訪問控制和安全性是現代應用程式的關鍵要素,確保用戶擁有適當的資源訪問權限。Logto 的基於角色的訪問控制 (RBAC) 提供給開發者一種高效管理應用程式中訪問控制和安全性的方法。在本文中,我們將通過一個實際的範例來探索 Logto 的 RBAC 實現的強大功能,幫助你理解和應用這些概念到你的專案中。
通過檢查前端和後端的程式碼片段,你將獲得整合 Logto 的 RBAC 到你的應用程式堆栈的全面視角。到本文結束時,你將能夠利用 Logto 的 RBAC 功能來增強你專案的安全性和訪問控制。
介紹 BookHarber:一個線上書店的用例
為了有效展示 Logto 的 RBAC 功能,我們將使用一個實際的範例:BookHarber,一家線上書店。BookHarber 為顧客和員工提供了廣泛的功能,確保無縫且安全的購物體驗。
BookHarber 的主要功能包括:
- 瀏覽和購買圖書:用戶可以輕鬆搜尋和購買來自不同類型和作者的廣泛書籍收藏。
- 訂單管理和物流跟踪:註冊用戶可以管理他們的訂單,追踪運送,並收到他們購買的更新。
- 特別優惠和假日活動:BookHarber 在特殊事件和假日期間提供獨家折扣和促銷活動,以吸引和獎勵其顧客群。
- 客戶支援:顧客可以開啟支援票據來解決他們可能遇到的任何問題或疑慮,並從 BookHarber 員工獲得迅速的協助。
- 客戶管理:具備不同角色的員工可以管理平台的各個方面,例如客戶賬戶,訂單處理和問題解決。
角色
在 BookHarber 生態系統中,我們可以識別出幾個主要的用戶角色,例如:
- 訪客:未註冊用戶,可以瀏覽網站、搜尋書籍和查看特別優惠。
- 顧客:註冊用戶,可以購買書籍、管理訂單、追踪物流及開啟支援票據。
- 商店管理員:負責監督平台整體管理與運營的員工。擁有完全的訪問權。
- 書籍管理員:負責書籍和類別管理的員工。
- 客戶服務代理:負責回應支援票據的員工。
- 第三方物流供應商:負責管理和跟踪訂單運送和交付的外部合作夥伴。
- 市場行銷人員:負責推廣 BookHarber,負責管理特別優惠和活動的員工。
設計 BookHarber REST API 的範圍
為了有效實現 Logto 的 RBAC 系統,我們需要設計與各個 REST API 對應的範圍。範圍是定義特定角色對每個 API 端點的訪問級別的權限。通過將適當的範圍分配給每個用戶角色,我們可以確保用戶只訪問與其角色相關的操作和資源。
讓我們為以下 REST API 設計範圍:
- Categories API:
create:categories
: POST /categorieswrite:categories
: PUT /categories/:iddelete:categories
: DELETE /categories/:idlist:categories
: GET /categories
- Books API:
create:books
: POST /bookswrite:books
: PUT /books/:iddelete:books
: DELETE /books/:idlist:books
: GET /booksread:books
: GET /books/:id
- Customers API:
list:customers
: GET /customerswrite:customers
: PUT /customers/:iddelete:customers
: DELETE /customers/:idread:customers
: GET /customers/:id
- Orders API:
create:orders
: POST /orderslist:orders
: GET /ordersread:orders
: GET /orders/:idwrite:orders
: PUT /orders/:id
- Events API:
create:events
: POST /eventswrite:events
: PUT /events/:idlist:events
: GET /eventsdelete:events
: DELETE /events/:id
- Order Tracks API:
read:orderTracks
: GET /orders/:id/trackscreate:orderTracks
: POST /orders/:id/trackswrite:orderTracks
: PUT /orders/:id/tracks/:trackId
- Tickets API:
create:tickets
: POST /ticketslist:tickets
: GET /ticketsread:tickets
: GET /tickets/:idwrite:tickets
: PUT /tickets/:id
為角色分配範圍
現在我們已經為每個 REST API 定義了適當的範圍,我們可以將這些範圍分配給 BookHarber 生態系統中的相應用戶角色:
Scopes | Guest | Customer | Store Admin | Books Manager | Customer Service Agent | Third-Party Logistics Provider | Marketing Staff |
---|---|---|---|---|---|---|---|
create:categories | ✓ | ✓ | |||||
write:categories | ✓ | ✓ | |||||
delete:categories | ✓ | ✓ | |||||
list:categories | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
create:books | ✓ | ✓ | |||||
write:books | ✓ | ✓ | |||||
delete:books | ✓ | ✓ | |||||
list:books | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
read:books | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
list:customers | ✓ | ✓ | |||||
write:customers | ✓ | ||||||
delete:customers | ✓ | ||||||
read:customers | ✓ | ✓ | |||||
create:orders | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
list:orders | ✓ | ||||||
read:orders | ✓ | ✓ | |||||
write:orders | ✓ | ||||||
create:events | ✓ | ✓ | |||||
write:events | ✓ | ✓ | |||||
list:events | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
delete:events | ✓ | ✓ | |||||
read:orderTracks | ✓ | ✓ | ✓ | ||||
create:orderTracks | ✓ | ✓ | |||||
write:orderTracks | ✓ | ✓ | |||||
create:tickets | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
list:tickets | ✓ | ✓ | |||||
read:tickets | ✓ | ✓ | |||||
write:tickets | ✓ | ✓ |
理解 "list" 和 "read" 範圍之間的區別
為了進一步說明在 REST API 設計和 RBAC 中 "list" 和 "read" 範圍之間的區別,讓我們考慮一個涉及線上書店 BookHarber 的實際範例。
假設 BookHarber 有兩種類型的用戶:顧客和客戶服務代理。顧客可以創建訂單,而客戶服務代理負責幫助顧客處理訂單。讓我們看看 "list" 和 "read" 範圍如何應用於 orders
API 資源中的這種情況。
- List 範圍:"list" 範圍允許用戶訪問系統中的實體集合。例如,
list:orders
範圍允許用戶檢索所有可用訂單的列表。在 BookHarber 的情境中,這個範圍可以對於需要了解系統中所有訂單概覽的商店管理員或其他員工有用。然而,客戶服務代理不應該能夠訪問所有訂單,因為他們的角色是 協助個別顧客工作。 - Read 範圍:"read" 範圍授予用戶許可權以訪問具有特定 ID 的單個實體。例如,
read:orders
範圍允許用戶根據其 ID 查看特定訂單的詳細信息。在 BookHarber 的情境中,這個範圍對需要訪問特定顧客訂單信息的客戶服務代理非常理想。當顧客開啟一個支援票據時,客戶服務代理可以使用票據中提供的訂單 ID 來訪問和查看該特定訂單的詳細信息。
理解所有權:為什麼顧客不需要他們自己訂單的 "read" 或 "list" 範圍
在許多應用中,通常用戶可以訪問自己的資源而無需明確授予相應的 "read" 或 "list" 範圍。這是因為用戶被認為是這些資源的所有者,應自然擁有它們的訪問權。在我們的 BookHarber 範例中,顧客可以創建訂單,但不需要 "read:orders" 或 "list:orders" 範圍。
所有權的概念在為 REST API 的特定資源定義訪問控制中發揮關鍵作用。通過承認用戶可以始終訪問他們的資源,我們可以實施更高效和安全的訪問控件,無需授予不必要的權限。在 BookHarber 的情況中,這意味著顧客可以查看和管理他們的訂單而不需要任何額外的範圍。
為了演示這是如何運作的,讓我們考慮 GET /orders
端點:
- 如果用戶擁有
list:orders
範圍(例如,商店管理員或員工),他們將能夠查看系統中的所有訂單。這提供了他們角色所需的訂單數據的全面視圖。 - 如果用戶沒有
list:orders
範圍(例如,普通顧客),系統將僅返回屬於用戶的訂單。這確保顧客可以依然訪問他們的訂單信息,而無需授予不必要的權限。
通過實施這種基於所有權的訪問控件,API 可以根據不同用戶角色提供適當的訪問水平,同時保持安全性和量身定制的用戶體驗。在 BookHarber 的場景中,所有權模型允許顧客訪問他們的訂單信息,而不需要 "read:orders" 或 "list:orders" 範圍,簡化訪問控制設計並增強整體用戶體驗。
配置 Logto 控制台中的設置
要在 Logto 的控制台中完成配置,請按照以下步驟:
- 創建 React 單頁應用 (SPA):在 Logto 控制台中為你的 React 應用創建一個 SPA。
- 創建 API 資源:添加一個標識為
https://api.bookharber.com
的新的 API 資源。 - 為資源定義範圍:在新創建的 API 資源下創建必要的範圍。
- 創建角色並分配範圍:定義你的應用的用戶角色,並將每個角色分配適當的範圍。
- 為用戶分配角色:為應用中的用戶(尤其是員工)分配相關角色,確保每個用戶的角色擁有正確的權限。
使用範圍保護 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 系統都提供了一個靈活且高效的解決方案,以滿足你的訪問控制需求。