跳到主要内容

基于角色的访问控制

基于角色的访问控制 (Role-based access control) 是一种根据用户角色分配权限的方法。在以下场景中可以考虑使用 RBAC：

  • 你有多个用户具有不同的访问需求：当用户需要根据角色（如管理员、编辑者或查看者）获得不同权限时，RBAC 是理想的选择。
  • 你需要简化权限管理：通过分配角色而不是单独设置权限来管理大量用户是高效的。
  • 你的应用服务于不同的部门或团队：在不同的群体需要对资源有不同的访问级别时，这很有用。

理解基于角色的访问控制如何工作​

权限 (Scopes)​

权限 (Permission) 是指访问 [API 资源] 的授权。在现实世界中，订单、产品和文档等实体可以被指定为资源，并可以分配各种操作。

权限示例，包括编辑订单、读取文档和删除产品的能力，如下所示：

  • write:orders
  • read:documents
  • delete:products
Permissions

上图显示了资源 https://api-1.store.io 中的权限 read:item 与资源 https://api-2.store.io 中的权限 read:item 是不同的。

如果没有提供 API 资源，权限将被视为“用于 OIDC”。通常这不是你在 RBAC 中想要的。

角色 (Roles)​

角色 (Roles) 是 权限的分组，可以分配给用户。它们还提供了一种聚合为不同 API 定义的权限的方法，使得添加、删除或调整权限比单独分配给用户更为高效。

以下是一个 order_admin 角色的示例，它具有两个资源的多个权限：

Order Admin Role

角色之间的权限重叠是可以的。

示例：一个在线书店​

假设你有一个在线书店需要管理。在这里，我们大大简化了访问控制模型以便演示。

该模型分为两个主要的 API 资源：订单和产品。它们有不同的资源指示器如下：

  • 订单：https://api.store.io/orders
  • 产品：https://api.store.io/products

对于每个资源，你希望将权限分为读取、写入和删除。因此，你总共定义了六个权限：

  • https://api.store.io/orders
    • 权限 read:order
    • 权限 write:order
    • 权限 delete:order
  • https://api.store.io/products
    • 权限 read:product
    • 权限 write:product
    • 权限 delete:product

以下是该模型的示意图：

Bookstore API and Permissions

你希望有两种类型的管理员，订单管理员和产品管理员：

  • 订单管理员 可以管理订单并查看产品（因为订单由产品组成），但不能管理产品。
  • 产品管理员 可以管理产品，他们不应该知道任何订单。

因此，你创建了两个角色，order_admin 和 product_admin，具有以下权限：

  • order_admin
    • https://api.store.io/orders
      • read:order, write:order, delete:order
    • https://api.store.io/products
      • read:product
  • product_admin
    • https://api.store.io/products
      • read:product, write:product, delete:product

以下是这两个角色的示意图：

Bookstore Roles

可以将 order_admin 和 product_admin 都分配给一个用户，那么他们将拥有你刚刚定义的所有六个权限。

注意订单管理员与产品管理员共享权限 read:product，用户最终持有的权限是他们被分配的所有角色的权限的并集。