精通 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 APIs 设计范围
为了有效地为 BookHarber 实现 Logto 的 RBAC 系统,我们需要设计对应于各种 REST APIs 的范围。范围是权限,定义了特定角色对每个 API 端点的访问级别。通过为每个用户角色分配适当的范围,我们可以确保用户只能访问与他们角色相关的动作和资源。
我们为以下的 REST APIs 设计范围:
- 分类 API:
创建:分类
:POST /categories编写:分类
:PUT /categories/:id删除:分类
:DELETE /categories/:id列表:分类
:GET /categories
- 图书 API:
创建:图书
:POST /books编写:图书
:PUT /books/:id删除:图书
:DELETE /books/:id列表:图书
:GET /books阅读:图书
:GET /books/:id
- 客户 API:
列表:客户
:GET /customers编写:客户
:PUT /customers/:id删除:客户
:DELETE /customers/:id阅读:客户
:GET /customers/:id
- 订单 API:
创建:订单
:POST /orders列表:订单
:GET /orders阅读:订单
:GET /orders/:id编写:订单
:PUT /orders/:id
- 事件 API:
创建:事件
:POST /events编写:事件
:PUT /events/:id列表:事件
:GET /events删除:事件
:DELETE /events/:id
- 订单追踪 API:
阅读:订单追踪
:GET /orders/:id/tracks创建:订单追踪
:POST /orders/:id/tracks编写:订单追踪
:PUT /orders/:id/tracks/:trackId
- 票证 API:
创建:票证
: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 的上下文中,这个范围可能对于需要查看系统中所有订单总览的店家管理员或其他员工有用。但是,客服代理不能访问所有的订单,因为他们的角色是帮助个别客户处理特定的订单。 - 阅读范围:"阅读"范围授予用户权限,让用户能访问具有特定 ID 的单个实体。例如,**
read:orders
**范围允许用户通过订单的 ID 查看关于特定订单的详细信息。在 BookHarber 的情况下,这个范围适合于需要接触到特定顾客订单信息的客服代理。当一个顾客开启一个支持票据,客服代理可以使用票据中提供的订单 ID 来接触和浏览那个特定订单的详情。
理解所有权:为什么客户不需要“阅读”或“列表”范围来查看他们自己的订单
在许多应用中,用户往往能访问他们自己的资源,而无需显式地授予他们相应的“阅读”或“列表”范围。这是因为用户被视为这些资源的所有者,因此应当自然得能访问这些资源。在我们的 BookHarber 示例中,客户可以创建订单,但并不具有 “read:orders” 或 “list:orders” 范围。
所有权的概念在定义 REST API 中特定资源的访问控制方面发挥了关键作用。通过承认用户总是可以接触他们自己的资源,我们可以实现更高效且安全的访问控制,无需授予不必要的权限。在 BookHarber 的情况下,这意味着客户仍然可以查看和管理他们的订单,而无需任何额外的范围。
为了说明这个工作原理,让我们考虑**GET /orders
**端点:
- 如果用户有**
list:orders
**范围(例如,商店管理员或员工),他们将能够查看系统中的所有订单。这为他们提供了需要的订单数据的全面查看。 - 如果用户没有**
list:orders
**范围(例如,普通顾客),系统只会返回属于用户的订单。这确保了用户仍然可以接触到他们的订单信息,那同时不授予不必要的权限。
通过实现这种基于所有权的访问控制,API 可以为不同的用户角色提供适当的访问级别,同时保持安全和个性化的用户体验。在 BookHarber 的情况下,所有权模型允许用户接触他们的订单信息,而不需要“实现:订单”或“列表:订单”范围,简化了访问控制的设计,并提升了整体用户体验。
在 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/
除了基本的安装,你还需要在配置中指定 "资源" 和 "范围":
以下是如何使用 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 系统提供了一个灵活且高效的解决方案来满足你的访问控制需求。