精通 Logto 中的 RBAC:一个全面的实例
本文详细介绍了如何在 Logto 中掌握基于角色的访问控制 (RBAC),并通过一个在线书店的实例探讨了关键的用户角色、范围,以及在前端和后端应用中集成 Logto 的 RBAC 功能以增强安全性和访问控制。
本文详细介绍了如何在 Logto 中掌握基于角色的访问控制 (RBAC),并通过一个在线书店的实例探讨了关键的用户角色、范围,以及在前端和后端应用中集成 Logto 的 RBAC 功能以增强安全性和访问控制。
访问控制和安全是现代应用的重要方面,确保用户具有访问资源的适当权限。Logto 的基于角色的访问控制 (RBAC) 为开发者提供了一种有效的方法来管理他们应用中的访问控制和安全性。在本文中,我们将使用一个实际的示例来探索 Logto RBAC 实现中的强大功能,帮助你理解并将这些概念应用到你的项目中。
通过考察前端和后端的代码片段,你将从全局角度了解如何将 Logto 的 RBAC 集成到你的应用程序堆栈中。在本文结束时,你将做好准备,利用 Logto 的 RBAC 功能来增强你项目的安全性和访问控制。
为了有效地展示 Logto 的 RBAC 功能,我们将使用一个实际的示例:BookHarber,一个在线书店。BookHarber 为客户和员工提供了广泛的功能,确保了无缝且安全的购物体验。
BookHarber 的关键功能包括:
在 BookHarber 的生态系统中,我们可以识别出几个关键的用户角色,例如:
为了有效地为 BookHarber 实现 Logto 的 RBAC 系统,我们需要设计对应于各种 REST APIs 的范围。范围是权限,定义了特定角色对每个 API 端点的访问级别。通过为每个用户角色分配适当的范围,我们可以确保用户只能访问与他们角色相关的动作和资源。
我们为以下的 REST APIs 设计范围:
创建:分类:POST /categories编写:分类:PUT /categories/:id删除:分类:DELETE /categories/:id列表:分类:GET /categories创建:图书:POST /books编写:图书:PUT /books/:id删除:图书:DELETE /books/:id列表:图书:GET /books阅读:图书:GET /books/:id列表:客户:GET /customers编写:客户:PUT /customers/:id删除:客户:DELETE /customers/:id阅读:客户:GET /customers/:id创建:订单:POST /orders列表:订单:GET /orders阅读:订单:GET /orders/:id编写:订单:PUT /orders/:id创建:事件:POST /events编写:事件:PUT /events/:id列表:事件:GET /events删除:事件:DELETE /events/:id阅读:订单追踪:GET /orders/:id/tracks创建:订单追踪:POST /orders/:id/tracks编写:订单追踪:PUT /orders/:id/tracks/:trackId创建:票证:POST /tickets列表:票证:GET /tickets阅读:票证:GET /tickets/:id编写:票证:PUT /tickets/:id现在我们已经为每个 REST API 定义了适当的范围,我们可以将这些范围分配给 BookHarber 生态系统中的相关用户角色:
| 范围 | 游客 | 客户 | 店铺管理员 | 图书管理员 | 客服代理 | 第三方物流提供商 | 营销人员 |
|---|---|---|---|---|---|---|---|
| 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 | ✓ | ✓ |
为了进一步揭示“列表”和“阅读”范围在 REST API 设计和 RBAC 上下文中的差别,我们以一个在线书店 BookHarber 的实例来考虑。
假设 BookHarber 有两种用户:客户和客服代理。客户可以创建订单,而客服代理负责帮助客户处理他们的订单。让我们看一下“列表”和“阅读”范围如何适用于这种场景中的 订单 API 资源。
list:orders**范围允许用户取回所有可用订单的列表。在 BookHarber 的上下文中,这个范围可能对于需要查看系统中所有订单总览的店家管理员或其他员工有用。但是,客服代理不能访问所有的订单,因为他们的角色是帮助个别客户处理特定的订单。read:orders**范围允许用户通过订单的 ID 查看关于特定订单的详细信息。在 BookHarber 的情况下,这个范围适合于需要接触到特定顾客订单信息的客服代理。当一个顾客开启一个支持票据,客服代理可以使用票据中提供的订单 ID 来接触和浏览那个特定订单的详情。在许多应用中,用户往往能访问他们自己的资源,而无需显式地授予他们相应的“阅读”或“列表”范围。这是因为用户被视为这些资源的所有者,因此应当自然得能访问这些资源。在我们的 BookHarber 示例中,客户可以创建订单,但并不具有 “read:orders” 或 “list:orders” 范围。
所有权的概念在定义 REST API 中特定资源的访问控制方面发挥了关键作用。通过承认用户总是可以接触他们自己的资源,我们可以实现更高效且安全的访问控制,无需授予不必要的权限。在 BookHarber 的情况下,这意味着客户仍然可以查看和管理他们的订单,而无需任何额外的范围。
为了说明这个工作原理,让我们考虑**GET /orders**端点:
list:orders**范围(例如,商店管理员或员工),他们将能够查看系统中的所有订单。这为他们提供了需要的订单数据的全面查看。list:orders**范围(例如,普通顾客),系统只会返回属于用户的订单。这确保了用户仍然可以接触到他们的订单信息,那同时不授予不必要的权限。通过实现这种基于所有权的访问控制,API 可以为不同的用户角色提供适当的访问级别,同时保持安全和个性化的用户体验。在 BookHarber 的情况下,所有权模型允许用户接触他们的订单信息,而不需要“实现:订单”或“列表:订单”范围,简化了访问控制的设计,并提升了整体用户体验。
要在 Logto 的控制台完成配置,请按照以下步骤操作:
https://api.bookharber.com**的新 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/
除了基本的安装,你还需要在配置中指定 "资源" 和 "范围":
以下是如何使用 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 系统提供了一个灵活且高效的解决方案来满足你的访问控制需求。