7.12. 从较早的用户联合 SPI 迁移
本章仅在您已使用先前（及现已删除）用户 Federation SPI 实施的供应商时才适用。
在 Keycloak 版本 2.4.0 及更高版本中有一个用户 Federation SPI。虽然不被支持，但 Red Hat Single Sign-On 版本 7.0 也具有之前的 SPI 可用。这个较早的用户 Federation SPI 已从 Keycloak 版本 2.5.0 和 Red Hat Single Sign-On 版本 7.1 中删除。但是，如果您已经编写了这个早期的 SPI 的供应商，本章将讨论一些可以使用的策略来移植它。
7.12.1. 导入和非导入
较早的用户 Federation SPI 需要您在 Red Hat Single Sign-On 的数据库中创建用户的本地副本，并将信息从外部存储导入到本地副本。然而，这不再是一个要求。您仍然可以将之前的供应商的端口，但应考虑一个非导入策略是否为更好的方法。
导入策略的优点：
- 红帽单点登录基本上成为外部存储的持久性用户缓存。导入用户后，您将不再点击外部存储，从而减少负载。
- 如果您要作为您的官方用户商店使用 Red Hat Single Sign-On 并弃用较早的外部存储，您可以慢慢地迁移应用程序以使用 Red Hat Single Sign-On。迁移完所有应用程序后，取消链接导入的用户，并停用之前的传统外部存储。
使用导入策略有一些明显的缺点：
- 第一次查找用户时，需要多个更新红帽单点登录数据库。这可能会给负载带来巨大性能损失，并给红帽单点登录数据库带来大量负担。用户联合存储方法仅根据需要存储额外的数据，且可能永远不会根据外部存储的功能使用。
- 通过导入方法，您必须保持本地红帽单点登录存储和外部存储同步。User Storage SPI 有功能接口来支持同步，但这可能会很快变得困难和我。
7.12.2. UserFederationProvider 与 UserStorageProvider
需要注意的是，UserFederationProvider 是一个完整的界面。您在这个接口中实施了每种方法。但是，UserStorageProvider 已将此接口划分为多个您根据需要实施的功能接口。
UserFederationProvider.getUserByUsername （） 和 getUserByEmail （） 在新的 SPI 中具有确切的等效点。两者之间的差别在于您如何导入。如果您要继续使用导入策略，您不再调用 KeycloakSession.userStorage （）.addUser （） 在本地创建用户。而是调用 KeycloakSession.userLocalStorage （）.addUser （）。userStorage （） 方法不再存在。
UserFederationProvider.validateAndProxy （） 方法已移至可选的功能接口 ImportedUserValidation。如果您正移植之前的供应商，您需要实施此界面。另请注意，在之前的 SPI 中，每次访问用户时都会调用此方法，即使本地用户位于缓存中。在后面的 SPI 中，只有从本地存储加载本地用户时，才会调用此方法。如果本地用户被缓存，则 ImportedUserValidation.validate （） 方法不会被调用。
之后的 SPI 中不再存在 UserFederationProvider.isValid （） 方法。
UserFederationProvider 方法 synchronizeRegistrations （）、registerUser （） 和 removeUser （） 已移至 UserRegistrationProvider 能力接口。这个新界面是可选的，因此如果您的供应商不支持创建和删除用户，则不必实施它。如果您的供应商有切换支持注册新用户，则在新的 SPI 中支持此操作，如果供应商不支持添加用户，则返回 null from UserRegistrationProvider.addUser （）。
现在，在 CredentialInputValidator 和 CredentialInputUpdater 接口中封装了相关的 UserFederationProvider 方法，这也是可选的，具体取决于您支持验证或更新凭证。用于 UserModel 方法中的凭证管理。它们也被移到 CredentialInputValidator 和 CredentialInputUpdater 接口。请注意，如果没有实现 CredentialInputUpdater 接口，则您的供应商提供的任何凭证都可以在 Red Hat Single Sign-On 存储中本地覆盖。因此，如果您希望您的凭据为只读，实施 CredentialInputUpdater.updateCredential （） 方法并返回 ReadOnlyException。
UserFederationProvider 查询方法，如 searchByAttributes （） 和 getGroupMembers （） 现在封装在一个可选接口 UserQueryProvider 中。如果不实施此接口，则在管理控制台中无法查看用户。您仍然能够登录。
7.12.3. UserFederationProvidery 与 UserStorageProviderFactory 相比
之前 SPI 中的同步方法现在封装在一个可选的 ImportSynchronization 接口中。如果您实施了同步逻辑，则您的新 UserStorageProviderFactory 实施 ImportSynchronization 接口。
7.12.4. 升级到新模型
User Storage SPI 实例存储在一组不同的关系表中。Red Hat Single Sign-On 会自动运行迁移脚本。如果为某个域部署任何较早的用户 Federation 提供程序，则它们将转换为更新的存储模型，包括数据的 ID。只有用户存储供应商 ID （例如，"ldap"，"kerberos"）作为先前的用户 Federation 提供程序存在时，才会进行此迁移。
因此，了解这种方法可以采用不同的方法。
- 您可以在之前的 Red Hat Single Sign-On 部署中删除之前的供应商。这将删除您导入的所有用户的本地链接副本。然后，当您升级 Red Hat Single Sign-On 时，只需为域部署和配置新提供程序。
-
第二个选项用于编写您的新提供程序，确保它具有相同的提供程序 ID：
UserStorageProviderFactory.getId （）。确保此提供程序已部署到服务器。引导服务器，并内置迁移脚本从以前的数据模型转换到更新的数据模型。在这种情况下，所有之前导入的用户都可以正常工作。
如果您决定解决导入策略并重写您的 User Storage 提供程序，我们建议您在升级 Red Hat Single Sign-On 前删除之前的供应商。这将删除您导入的任何用户的本地导入副本。
