基于角色的访问控制（RBAC）

在前面的章节中，我们以 GitClub 为例介绍一个典型的 Web 应用以及如何为其添加授权。 我们证明了授权可以被看作两个部分： 执行 和 决定 。

决策 指 “是否允许此用户在这一资源上执行此操作？这一问题” 通常情况下，结果是 “是” 或 “否”。

执行 是指我们做出决定后采取的行动。 如果决定是“拒绝”，我们是重定向他们，还是像他们展示一个“Permission Denied”的页面？

在本章中，我们聚焦在 决策 上。 特别是，我们会问这样一个问题：“谁可以在应用程序中做什么？” 另外，我们还需要讨论数据 —— 当我们问“谁可以做什么”时，我们正在检查那些数据结构？

为了防止这成为一个完全开放的问题，我们使用授权模型来指导我们的实现。 模型是指导我们实现和组织授权代码结构的方式。

在本章节中，我们将讨论如何使用基于角色的访问控制（RBAC） 我们将围绕几个不同类型的 B2B 应用，介绍几个不同的变体。 对每个模型我们将讨论：

其授权模型是什么样的 。 选择正确的授权模型取决于所需的用户体验。 我们将从较高的层次讨论模型所表示的内容，展示其在真实世界的示例， 展示什么时候使用它是有意义的，并描述什么让他非常适合该用例。

怎样实现此模型 。 正如我们在上一章谈到的，授权决策由两部分信息构成：数据和逻辑。 授权逻辑决定谁可以做什么的抽象规则集合。 例如，允许一个组织的成员访问属于该组织的仓库。 这些规则通过授权数据进行表示。

我们将另外描述如何构建授权数据来支持我们的逻辑，包括如何将其存储在关系型数据库（例如，PostgreSQL）中的模式图。

在多数情况下，我们将使用上一章介绍的 GitClub 示例应用。 友情提示：GitClub 是一个用于源代码托管、写作以及版本控制的网站，和现实生活中的 GitLab 和 GitHub 类似。 GitClub 提供了一个纯粹的例子来说明最初是什么催生了授权 —— 保护对资源的访问。 在 GitClub 中，一个资源的例子是仓库。 用户可以或不可对仓库进行访问或更改。

角色是广泛使用的授权模型。 又被称为“基于角色的访问控制” 角色是对实现和用户简化授权逻辑的有效方式。

角色 只是一种对权限进行分组的方式，以便将他们分配给用户。

当一个用户被分配了一个权限，用户将被授予此角色所包含的所有权限。

权限 指定用户可以对资源执行的动作。 例如，组织中的用户有 权 读取仓库。 一个角色的权限不是随意挑选的。 通常，角色应该与用户是谁、他们现在应用中做什么、甚至他们在组织中的角色或头衔保持一致。

例如，在 GitClub 中主要的用户是开发者 —— 这将会是我们系统中的一个 “角色”。 当然也有其他角色：我们可能有负责配置组织的 IT 管理员或负责计费的财务用户。 所有这些用户都有在使用我们的应用时所需要的的不同权限集合。 这些每一个都将和我们 GitClub 授权模型中的一个角色相对应。

分配到“记账”角色的人自然会期望可以为组织配置计费 —— 新会员付费，更新付款信息等。

通过使用角色，我们减少了需要向终端用户暴露的权限信息的表面积。 与其要求用户配置大量权限来使用该应用程序，不如从少数选项中进行选择。

角色非常灵活 —— 我们将在本章中看到几种不同的方式来使用他们来实现不同的功能 —— 并且可以在任何 B2B 应用中使用。