构建可靠（且快速）的目录同步

“谁是你的用户？” — 主控制程序，TRON (1982) 如果用户身份对您的应用程序很重要，您需要一种方法来管理它。通常这意味着用户帐户，您在有人注册时创建它们。但允许员工注册他们喜欢的任何 SaaS 应用程序是管理的噩梦。因此，组织喜欢控制应用程序中存在（或不存在）哪些用户的方法。这控制了谁可以登录，但是他们可以做什么呢？为此，您需要角色或组，它们与用户一样来自组织的身份提供商 - Entra、Google、Okta 等。组构成了 Firezone 访问模型的基础。他们决定谁可以访问什么。让用户和组进入您的应用程序的过程称为目录同步，要做好它是非常棘手的。在这篇文章中，我们将介绍目录同步到底是什么、实现它的领先标准，以及为什么我们选择完全放弃它并从头开始构建我们自己的引擎。组织的目录是在那里工作的人员以及他们被允许访问的内容的列表。它存在于身份提供者中，由三部分组成： 用户：组织中的人员。每个人都有一个姓名、电子邮件和状态（例如活动或暂停）。组：命名的用户集合，例如 Engineering 或 Product 。通过群组，您可以同时向许多人授予访问权限。成员：谁属于什么。组的成员可以是用户，也可以是另一个组。用户的访问权限来自他们所属的每个组，直接或通过其他组。目录同步是将目录复制到您的应用程序中并使其保持最新的过程。身份提供者是事实的来源，因此您的应用程序保存的是副本。随着时间的推移，该副本必须进行三种更改：新用户和组、名称更改等更新以及删除。当有人加入、离开或更换团队时，您的应用程序最好能够快速发现。值得澄清一下目录同步不是什么：单点登录 (SSO)。这似乎是显而易见的，但许多人将两者混为一谈。 OpenID Connect 等领先的身份验证标准没有提及如何将用户带入应用程序。在目录同步中，我们指的是引入用户（和组）的机制，而不是他们的身份验证方式（为此，请参阅这篇文章）。假设您的组织有以下目录： 在您的数据库中，它可能看起来像这样： 作为数据库表的示例目录 三个表。用户列出了 Alice 和 Bob。组列出了产品和工程。成员有一个用户列、一个组列和一个父组列。 Alice 是产品中的用户。 Bob 是工程领域的用户。工程组属于产品组。每行将前两列中的一列留空，回答 Bob 是否在 Product 中意味着通过递归查询来跟踪父组。用户名 Alice Bob 组名称 产品工程成员 用户组 Parent_group Alice - 产品 Bob - 工程 - 工程产品 要回答应用程序中的常见访问问题（例如“Bob 是产品的成员吗？”），您必须查看产品的成员，然后查看其中任何组的成员，依此类推，直到找到 Bob。为了避免这种情况，我们可以展平 groups ，直接或间接为每个用户所属的每个组提供一行： 具有展平成员资格的示例目录 三个表。用户列出了 Alice 和 Bob。组列出了产品和工程。成员有一个用户列和一个组列，用户直接或间接所属的每个组都有一行：Alice 属于产品，Bob 属于产品，Bob 属于工程。鲍勃在产品中，因为工程嵌套在产品中。嵌套组不再显示为行，因此询问 Bob 是否在 Product 中只需一次查找。用户名 Alice Bob 组名称 Product Engineering 成员用户组 Alice Product Bob Product Bob Engineering 现在，相同的问题是一个简单的查找。好的，这就是数据模型。现在我们需要将其从身份提供商处获取到我们的数据库中，并保持最新。当然，您不必自己发明所有这些。执行此目录同步操作有一个标准。它被称为 SCIM，其自我描述如下：跨域身份管理系统 (SCIM) 规范是一种基于 HTTP 的协议，通过标准化服务可以更轻松地支持多域场景中的身份管理。实际上，这意味着您在应用程序中构建 REST 端点列表，例如： GET /Users GET /Users/{id} POST /Users PUT /Users/{id} PATCH /Users/{id} DELETE /Users/{id} GET /Groups GET /Groups/{id} POST /Groups PUT /Groups/{id} PATCH /Groups/{id} DELETE /Groups/{id} 以及身份提供者调用它们来保持目录同步。 SCIM 的承诺：用单个 API 同步多个提供程序 SCIM 的好处是身份提供程序将更改推送到您的应用程序，因此提供程序发生更新和更新到达您的应用程序之间的延迟时间可能会很短