## 背景在[前一篇文章](/ciam-101-intro-authn-sso/)中，我们介绍了认证（AuthN）和授权（AuthZ）的概念，以及一些令人头痛的术语：身份，组织，租户等。组织和租户非常适合对身份进行分组，但它们通向绝对的民主：在这个系统中，每个人都可以做任何事情。虽然乌托邦仍是一个谜，让我们看一下访问的治理：授权（AuthZ）。 ### 为什么我们需要授权？授权（AuthZ）回答了“你能做什么？”这个问题。 Notion 是一个很好的例子。对于你拥有的每一个页面，你可以选择让它私有，只有你可以访问，或者与朋友分享，甚至公开。或者，对于一个在线书店，你希望每个人都能看到所有的书，但是客户只看他们自己的订单，和卖家只管理他们商店里的书。 AuthZ 和 AuthN 是复杂业务模型的必要组成部分。它们通常并肩作战；AuthZ 验证用户的访问，而 AuthN 对身份进行认证。两者对于一个安全的系统都是必要的。 ## 基本的授权模型这是最常见的 AuthZ 模型之一：如果**身份**对**资源**执行**动作**，那么**接受**或**被拒**。在 Notion 的例子中，模型是**个人**对**页面**执行**查看**。如果页面是私有的： - 当你对你的**页面**执行**查看**时，你将收到**接受**。 - 所有其他人当对你的**页面**执行**查看**时，应该收到**被拒**。基于共识，业界开发了各种授权技术，如基于角色的访问控制（RBAC），基于属性的访问控制（ABAC）。今天，我们将关注[NIST RBAC 模型](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf)级别1：Flat RBAC。 ## 基于角色的访问控制 NIST RBAC 模型留下了许多开放的事物，以提供灵活性和适应性以适应各种场景。Logto 现在采用第一级定义，并增加了"资源"（即 API 资源）的额外概念。让我们扩展书店的例子。假设我们有很多客户，但只有一个卖家： - 客户可以查看和订购书籍，以及查看他们自己的订单。 - 卖家可以查看，创建和删除书籍，并管理客户订单。 ### 定义资源在 Logto 中，资源（即 API 资源）通常代表一组实体或项目，因为需要使用有效的 URL 作为指示器。因此我们定义了两个资源： - 书籍：`https://api.bookstore.io/books` - 订单：`https://api.bookstore.io/orders` 强制使用 URL 格式的一个优点是它可以映射到你 API 服务的实际地址，当与系统中的其他组件集成时，可以提高可读性和可识别性。 🤔 应根据业务需求对资源进行划分。没有一揽子的做法；该决议应该是根据具体情况来做。此文中将书籍和订单进行划分的例子可能适合微服务，但不适用于单体架构。 ### 定义权限由于我们引入了资源的概念，在 Logto 中，我们还强制要求权限必须属于资源，反之，资源可以拥有权限。让我们为资源添加一些权限： - 书籍：`read`，`create`，`delete` - 订单：`read`，`read:self`，`create:self`，`delete` 尽管没有权限名称的要求，我们有以下约定： ``` [:] ``` `` 要求描述一个权限，`:` 可以忽略描述一个通用目标，即对资源中的所有实体或项目。例如： - 书籍资源中的权限 `read` 表示读取任意书籍的动作。 - 订单资源中的权限 `create:self` 表示创建属于当前用户的订单的动作。 ### 定义角色简单来说，一个角色就是一组权限。让我们创建两个角色 `customer` 和 `seller` 并把权限分配给它们如下： ```mermaid erDiagram Role-Customer { permission Books "read" permission Orders "read:self" permission Orders "create:self" } Role-Seller { permission Books "read" permission Books "create" permission Books "delete" permission Orders "read" permission Orders "delete" } ``` 你可能注意到，权限和角色的赋予是多对多的关系。 ### 把角色分配给用户就像角色权限赋值一样，用户角色赋值也是一种多对多的关系。因此，你可以把多个角色分配给一个用户，一个角色可以分配给多个用户。 ### 连接各个点下面是 Logto 中的级别1 RBAC 模型的完整关系图： ```mermaid erDiagram User }|--|{ Role : maps Role }|--|{ Permission : maps "API Resource" ||--|{ Permission : contains ``` 在 RBAC 模型中，权限总是 "positive" ，意味着授权判断很简单：如果用户有权限，那么接受；否则，拒绝。假设 Alice 有 `seller` 角色，Bob 和 Carol 有 `customer` 角色。我们首先用自然语言描述动作，然后把它们编译到标准的授权格式：**IDENTITY** performs **ACTION** on **RESOURCE**，最后给出结论。 - Alice 想添加一本新书出售： - 用户 Alice 对资源 Books （`https://api.bookstore.io/books`）执行 `create`。 - 由于 Alice 根据他们的 `seller` 角色被赋予了 Books 的 `create` 权限，结果是 ✅ **接受**。 - Alice 想查看所有订单以看看销售是否符合他们的期望： - 用户 Alice 在 Orders 资源（`https://api.bookstore.io/orders`）上执行 `read`。 - 由于 Alice 根据他们的 `seller` 角色被赋予了 Orders 的 `read` 权限，结果是 ✅ **接受**。 - Bob 想浏览书籍列表，看看有没有他们想购买的书。 - 用户 Bob 在 Books 资源（`https://api.bookstore.io/books`）上执行 `read`。 - 由于 Bob 根据他们的 `custome` 角色被赋予了 Books 的 `read` 权限，结果是 ✅ **接受**。 - Bob 想查看 Carol 的订单。 - 由于这是别人的订单，所以 Orders 的 `read:self` 权限在此不起作用。 - 用户 Bob 对 Orders 资源（`https://api.bookstore.io/order`）执行 `read`。 - 由于 Bob 没有 Orders 的 `read` 权限，结果是 ❌ **拒绝**。 ### 其他 RBAC 等级 NIST RBAC 模型有四个级别： - Flat RBAC - Hierarchical RBAC - Constrained RBAC - Symmetric RBAC 如果你对此感兴趣，可以查看[论文](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf)获取详细信息。 Logto 现在有 Level 1 的实现，将根据社区反馈进行更高级别的进展。如果更高级别适合你的需求，不要犹豫，告诉我们！ ## 实践中除了理论，我们还有大量技术工作要完成，以期模型能按预期工作： - 客户端和 auth 服务器开发 - RBAC 数据库设计 - 在不同服务之间的验证 - 安全和开放标准合规 - 角色，权限，资源管理和赋值不要恐慌。我们考虑到这一点，并为所有上述内容增加了开箱即用的支持。查看 [🔐 RBAC 菜谱](https://docs.logto.io/docs/recipes/rbac/)，学习如何在 Logto 中使用 RBAC。 ## 结束语 RBAC 对于大部分情况是一个强大的访问管理模型，但没有银弹。我们仍然有一些问题： - 我需要高级别的 RBAC 吗？ - RBAC 与其他授权模型相比如何？ - 如何定义不同组织之间的授权模型？ 🔥 保持关注。在 CIAM 103 中我们会见到你！