跨域身份管理系统 (SCIM) 简介-ACG漫画屋榜漫画

Cloudera 的身份团队一直在努力将跨域身份管理系统 (SCIM) 支持添加到 Cloudera 数据平台 (CDP)，我们很高兴地宣布 SCIM 在 Azure Active Directory 上的全面可用性！在第一部分中，我们讨论了：CDP SCIM 对 Active Directory 的支持，其中讨论了 CDP 对 Azure AD 的 SCIM 支持的核心元素。

SCIM（跨域身份管理系统）是用于管理 Web 上的身份（用户和组）的协议规范。SCIM 协议规范定义了 Web 产品可以实现的一系列端点、有效负载和响应，以便交换身份信息。“管理身份”仅包含管理该身份的整个生命周期的能力，身份再次是一个人或一个群体。身份的生命周期包括以下阶段： 

创建：当身份是系统的新身份并需要输入身份数据库时（例如新员工入职时），

阅读：当授权应用程序想要了解更多关于身份的信息时（例如运行查询时），

更新/修改：当身份的某个属性（例如电子邮件地址）发生更改并需要更新时，以及 

删除：当一个身份需要被删除时（例如当员工被解雇时）。  

SCIM 标准允许身份提供者通过使用 REST API 调用在 Web 应用程序中创建、检索/发现、更新和删除用户和组状态。因此，SCIM 取代了围绕身份管理的大量手动工作。

SCIM 的威力最好用一个例子来说明：

Acme Inc. 是一家公司，Alice 管理他们的身份提供者。过去，当 Acme 是一家只有几个员工并且只使用少数 Web 产品的初创公司时，Alice 会在身份提供者及其所有 Web 产品中手动进行所有用户管理。当有人加入 Acme 时，Alice 将在身份提供者中手动创建他们的帐户。然后，她会向他们发送邀请链接，以便在 Acme 使用的所有各种 Web 应用程序中创建一个帐户/密码。这是一个手动过程，Acme 几乎无法控制这些应用程序中的用户权限。 

随着 Acme 的发展，该组织需要更精细地控制员工在他们使用的 Web 应用程序中所拥有的权限——他们已经超越了公司发展的“让每个人都扎根”阶段。因此，Alice 做了大多数公司所做的事情，并将帐户管理转移到了单点登录 (SSO) 提供商。这意味着对于所有支持 SSO 的应用程序，Acme 员工不再需要记住他们特定于应用程序的用户名和密码。相反，他们可以登录到他们的 SSO 提供商并单击“使用 SSO 登录”按钮。这也简化了 Alice 的生活：每次有人单击“使用 SSO 登录”按钮时，都会将更新的用户状态（用户和组信息）发送到该应用程序。这意味着，如果 Acme 员工调动组织并需要一组新组，他们只需使用 SSO 再次登录，所有内容都会更新。

SSO 为 Alice 修复了很多手动工作，但并未涵盖所有情况。仅举几例：

当新员工加入 Acme 时，他们必须通过 SSO 手动登录才能在每个 Web 应用程序中创建帐户。

每个 Web 应用程序都有不同的会话超时，因此 Acme 员工需要了解他们必须重新登录才能将更新更新到应用程序中。这也意味着，如果某人在应用程序中获得了临时管理员访问权限，他们将继续拥有该管理员访问权限，直到 Alice 手动撤销它，或者他们再次登录并更新他们的权限。

同样，当员工被解雇时，他们仍然可以访问他们在 Web 应用程序中的帐户，直到 Alice 手动删除他们，或者他们的会话过期。

为了解决这些缺点，Alice 编写了自定义代码来更新每个产品的用户和组，并将其连接到 Acme 的身份提供程序 webhook。但是代码很脆弱；随着 API 的变化和新的 Web 产品的添加，它总是过时并不断维护。用于管理用户/组状态的内部 SLA （尤其是对于已离职员工）会不断打断她的工作。换句话说，Alice 花费了大量时间来保持自定义代码正常工作。

通过使用 SCIM（以及支持 SCIM 的身份提供者），所有这些令人头疼的问题都消失了，或者至少对 Alice 来说大大减轻了。她需要做的就是为每个支持它的 Acme 网络产品设置 SCIM，她不再需要担心这些应用程序中的用户/组状态。她仍然需要手动管理不支持 SCIM 的 Web 产品中的用户/组状态（这就是为什么仍然有点头疼的原因），但总的来说，这对她来说仍然是一个巨大的净利好。 

在幕后，Acme 的身份提供者将遵循 SCIM 规范，只要有用户/组更改，就会向每个 Web 应用程序发送有效负载。有人被添加到身份提供者的新组中？身份提供者启动了一系列“将用户 X 添加到组 Y”，SCIM 调用所有 Web 应用程序，用户无需重新登录即可更新。有人被解雇了吗？身份提供者启动“删除用户 X”，SCIM 调用这些应用程序。只需几分钟的配置，Alice 就将所有支持 SCIM 的应用程序的工作量减少到接近于零。 

然而，SCIM 并不是灵丹妙药。最大的限制是许多 Web 应用程序不支持它。对于支持它的 Web 应用程序，SCIM 非常有用。

本节有点技术性，并引导读者完成：

从身份提供者的角度来看的 SCIM。

从网络产品的角度来看的 SCIM。

限制。

公司的身份提供者是用户和群体的真实来源。对于这种情况，同样重要的是要注意并非所有身份提供者都支持 SCIM，因此如果您想将 SCIM 与 Cloudera 数据平台一起使用（支持 SCIM 的两个常见身份提供者是 Azure AD 和 Okta），请记住这一点。

SCIM 协议规范的核心分为两部分：用户创建、读取、更新和删除（CRUD）操作和组 CRUD 操作。在大多数情况下，这是您对 RESTful 规范的期望：身份提供者可以发送到 Web 产品的一系列端点和有效负载，以及对这些请求的一系列响应，让身份提供者知道它们是否是成功与否。当 Web 产品对 SCIM 调用做出错误响应时，身份提供者有两个选择：重试（使用一些退避策略）和提醒（电子邮件）可以尝试修复它的人。正因为如此，Web 产品使用人类可操作的消息来响应错误非常重要。

SCIM 用户 CRUD 操作：

创建用户 (POST)

检索用户 (GET)

检索特定用户 (GET)

更新用户（PUT/PATCH）

删除用户 (DELETE)

SCIM 组 CRUD 操作：

创建组 (POST)

检索组 (GET)

检索特定组 (GET)

更新特定组名（PUT/PATCH）

更新特定组成员身份（PUT/PATCH）

删除组 (DELETE)

SCIM 还定义了一些超出基本 CRUD 操作的批处理式操作（例如“从组中删除所有用户”和“替换组中的所有用户”），以及可以发送以缩小结果范围的不同查询参数. 还有一些大多数身份提供者（和大多数 Web 产品）选择不实现的额外端点（/Me、/Schemas、/ServiceProviderConfig、/ResourceTypes）。

用户数据以及如何对其进行切片有很多细微差别。例如，一个是应该将哪些字段发送到 Web 产品（例如，CDP 需要电子邮件，但不需要街道地址）。发送的字段还确定身份提供者可以使用哪些查询参数来尝试缩小搜索结果的范围。查询参数本身也有细微差别，因为并非所有网络产品都支持这些垂直领域的缩小结果。例如，一个网络产品可能会存储最后修改时间，但它可能不支持通过它过滤用户。

支持 SCIM 的身份提供者必须维护每个 SCIM 连接的 Web 产品的单独状态，此外还要维护组织的所有用户和组的真实来源。每个 SCIM 的单独状态–连接的网络产品既重要又复杂：假设 Acme 使用三个产品，A、B 和 C。如果产品 C 出现故障，身份提供者需要能够跟踪它认为 C 中的真相来源是什么，并在 C 重新联机时同步它，无论中断多长时间以及发生了多少用户/组更改。或者，如果 B 不支持完整的 SCIM 规范，则身份提供者需要对出错的操作进行回退重试（以防 B 决定在将来添加对规范的该部分的支持）同时仍然同步同时所有其他用户/组更改。身份提供者还需要处理网络产品中并非源自身份提供者的用户/组更改（即，当有人仅在网络产品中更新用户/组信息时）。这些只是几个例子。

网络产品（如 CDP）必须具有 

一种对 SCIM 调用进行身份验证/授权的机制。

SCIM 端点。

与 SCIM 兼容的内部用户/组 CRUD 操作。

身份验证机制通常是某种类型的访问令牌或访问令牌秘密，由 Web 产品生成并在设置阶段提供给身份提供者。这些通常是长期存在的、可撤销的，并且包含足够的信息来执行授权。一些网络产品使用用户访问令牌进行双重 SCIM 身份验证/授权，但是如果用户被删除（即用户离开公司），令牌将停止工作的缺点，以及有时该用户被管理的双重缺点通过 SCIM，因此 SCIM 更新可能会删除用户，这会删除他们的令牌，这会中断 SCIM 同步，直到建立新的信任。对于 CDP，我们将身份验证/授权实现为访问令牌：

有一个自定义的生命周期。

是可撤销的。

不属于创建它们的用户（因此它们存在于系统中任何单个用户的生命周期之外）。

范围为 SCIM 端点。

Web 提供者的 SCIM 端点需要能够解析身份提供者发送的有效负载，然后将它们映射到内部操作。但是，SCIM 端点和内部端点之间可能没有 1:1 的映射，因此需要将它们从 SCIM 规范转换为内部 API。例如，SCIM 定义了“替换组中的所有用户”的操作。这可能需要由网络产品转换为一系列内部 API 调用，例如：

列出组中的所有用户。

从组中删除所有这些用户。

将所有新用户添加到组中。

获取组信息并在响应中返回。

有时 SCIM 规范定义了 Web 产品中不可能的事情。一个常见的例子是大多数网络产品认为组名是不可变的，但 SCIM 规范定义了一个应该更新组名的有效负载。在这种情况下，网络产品唯一能做的就是返回一个人类可操作的错误，并希望身份提供者会通知人类事情现在不同步了。

SCIM 规范的一个显着用户体验是缺乏用户/组数据的双向同步。也就是说，真相的来源永远在身份提供者那里，所有的网络产品都是“下游”。因此，对于您开始使用 SCIM 的任何 Web 产品，您都应该停止管理这些产品中的用户信息，因为您将与身份提供者中的真实来源不同步。

身份提供者通常不会实时将更改同步到 Web 应用程序，它们以“同步周期”运行。这意味着用户/组更改可能需要一点时间来传播（通常这可能需要一个小时）。因此，如果您的内部 SLA 小于同步周期之间的时间，则 SCIM 可能不适合您。或者，如果您的 SLA 是针对特定场景（例如，被解雇的员工），您可以将 SCIM 用于其他所有事情，并且只需少量代码即可涵盖这些特定场景。

我希望这是对 SCIM 的有用概述。如果您想阅读更多内容，跳转点是：http://www.simplecloud.info/。

如果您的组织使用 Azure AD，并且您希望将 SCIM 与 Cloudera 数据平台一起使用，请参阅我们的文档以开始使用。

如果您的组织使用 Okta，并且您想开始将 SCIM 与 CDP 一起使用，请联系您的 Cloudera 代表以将其添加到候补名单中— Okta 支持即将推出。

原文作者：Jason Wang

原文链接：https://blog.cloudera.com/scim-system-for-cross-domain-identity-management/

本文使用 文章同步助手 同步