升级指南

当 RH-SSO 从一个主要版本升级到另一个主要版本时，需要一个主要升级或迁移，例如：从 Red Hat Single Sign-On 7.2 升级到 Red Hat Single Sign-On 8.0。主要版本之间可能需要重写应用程序或服务器扩展部分的 API 更改可能会破坏。

Red Hat Single Sign-On 定期提供点发行版本，它们是包括程序错误修复、安全修复和新功能的次要更新。如果您计划从一个 Red Hat Single Sign-On point 升级到另一个红帽单点登录（例如，从 Red Hat Single Sign-On 7.3 升级到 Red Hat Single Sign-On 7.5），则不应为应用程序或自定义服务器扩展（如果没有私有、不支持或技术预览 API）升级代码更改。

Red Hat Single Sign-On 7.5 还定期提供包含错误和安全修复的微版本。微版本以最后一个数字递增次要版本，例如从 7.5.0 到 7.5.1。这些版本不需要迁移，它不会影响服务器配置文件。ZIP 安装的补丁管理系统也可以回滚补丁和服务器配置。

微版本仅包含已更改的工件。例如，如果 Red Hat Single Sign-On 7.5.1 包含对服务器和 JavaScript 适配器的更改，但不支持 EAP 适配器，则只会发布服务器和 JavaScript 适配器，需要更新。

从 7.5.3 开始，您可以使用 Red Hat Single Sign-On Operator 7.6，它与 RH-SSO 7.5 完全兼容。7.5.z 不再发布 Operator。详情请查看 服务器安装与配置指南 中的相关章节。

Red Hat Single Sign-On 现在遵循用于传出 HTTP 请求的标准 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY 环境变量。如果您定义了 HTTP_PROXY 变量，但没有在 SPI 配置中指定的显式代理映射，则这个更改可能会导致代理服务器意外使用。要防止 Red Hat Single Sign-On 使用这些环境变量，您可以明确为所有请求创建一个代理路由，作为 .*;NO_PROXY。

如需了解更多详细信息，请参阅服务器安装与配置指南中的相关章节。

Red Hat Single Sign-On 服务器已升级到使用 EAP 7.4 作为底层容器。这个更改不会直接涉及任何特定的 Red Hat Single Sign-On 服务器功能，但一些与迁移相关的变化。

<extension module="org.wildfly.extension.microprofile.config-smallrye"/>
<extension module="org.wildfly.extension.microprofile.health-smallrye"/>
<extension module="org.wildfly.extension.microprofile.metrics-smallrye"/>

<extension module="org.wildfly.extension.microprofile.config-smallrye"/>
<extension module="org.wildfly.extension.microprofile.health-smallrye"/>
<extension module="org.wildfly.extension.microprofile.metrics-smallrye"/>

<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0"/>
<subsystem xmlns="urn:wildfly:microprofile-health-smallrye:2.0" security-enabled="false" empty-liveness-checks-status="${env.MP_HEALTH_EMPTY_LIVENESS_CHECKS_STATUS:UP}" empty-readiness-checks-status="${env.MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS:UP}"/>
<subsystem xmlns="urn:wildfly:microprofile-metrics-smallrye:2.0" security-enabled="false" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}"/>

<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0"/>
<subsystem xmlns="urn:wildfly:microprofile-health-smallrye:2.0" security-enabled="false" empty-liveness-checks-status="${env.MP_HEALTH_EMPTY_LIVENESS_CHECKS_STATUS:UP}" empty-readiness-checks-status="${env.MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS:UP}"/>
<subsystem xmlns="urn:wildfly:microprofile-metrics-smallrye:2.0" security-enabled="false" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}"/>

UserModel 包括某些字段、用户名、电子邮件、firstName 和 lastName，它们现在转换为自定义属性。这个变化的目的是为在即将推出的版本中向 Red Hat Single Sign-On 添加更复杂的用户配置文件。

这种情形意味着 用户名 现在可以被 UserModel.getFirstAttribute (UserModel.USERNAME) 进行设置。其他字段存在类似的影响。直接或间接类 UserModel 的实施器应该确保 setUsername 和 setSingleAttribute (UserModel.USERNAME, …​) 之间的行为是一致的。

如果策略评估功能的用户使用评估中的属性数量，则应调整其策略。每个用户现在默认有 4 个新属性。

UserModel 的公共 API 不会更改。不需要更改 frontend 资源或 SPI 访问用户数据。另外，数据库还没有改变。

Red Hat Single Sign-On 登录主题组件已升级到 PatternFly 4。旧的 PatternFly 3 与新同时运行，因此可以保持 PF3 组件。

但是，执行对登录主题设计的一些变化。请将您的自定义登录方案升级到新版本。有关必要更改 的示例，请参考 example/themes/theme/sunrise 目录。不需要额外的设置。

Instagram IdP 现在使用新的 API。旧的旧的 API 已被弃用。这个更改需要新的 API 凭证。详情请参阅" 服务器管理指南 "。

对于使用 Instagram IdP 登录 Instagram 的用户，这些用户需要不同的身份验证方法，如密码。它们可以手动更新其 Instagram 社交链接，或在 Red Hat Single Sign-On 中创建新帐户。这个限制存在，因为前面 API 中的 Instagram 用户 ID 与新的 API 不兼容。但是，新的 API 会临时返回新的和旧用户 ID 以允许迁移。Red Hat Single Sign-On 用户在用户登录时自动迁移 ID。

如果您使用 OpenID Connect 参数 request_uri，您的客户端需要将 Valid Request URIs 配置为防止 SSRF 攻击

您可以通过客户端详情页面上的 Admin Console 或 admin REST API 或客户端注册 API 来配置此功能。有效的 Request URI 需要包含特定客户端允许的 Request URI 值列表。

您可以使用通配符或相对路径，如 Valid Redirect URIs 选项。但是，在安全起见，我们推荐使用特定值。

只读用户属性现在可用。使用 REST API 更新用户或使用 Red Hat Single Sign-On 用户界面时，用户或管理员不会编辑这些用户属性。特别是，在使用以下任一变化时：

如需了解更多详细信息，请参阅 Threat 模型缓解章节。

使用 Docker 协议成功身份验证后，不会创建用户会话。详情请参阅" 服务器管理指南 "。

对于这个 Red Hat Single Sign-On 版本，OAuth2 客户端凭证 Grant 端点在默认情况下不发出刷新令牌。此行为与 OAuth2 规格一致。

因此，在成功客户端凭证身份验证后，Red Hat Single Sign-On 服务器上不会在 Red Hat Single Sign-On 服务器上创建用户会话。其结果提高了性能和内存消耗。我们鼓励使用 Client Credentials Grant 的客户端停止使用刷新令牌，而是在每次使用 grant_type=client_credentials 的请求进行身份验证，而不使用 refresh_token 作为授权类型。

为此，Red Hat Single Sign-On 支持撤销 OAuth2 Revocation 端点中的访问令牌。因此，如果需要，客户端被允许撤销单独的访问令牌。

为向后兼容，您可以保持在以前的版本中的行为。使用此方法时，在通过 Client Credentials Grant 成功身份验证后，仍然会发布刷新令牌，同时创建了用户会话。对于特定的客户端，您可以按照如下所示在管理控制台中启用之前的行为：

在以前的版本中，Red Hat Single Sign-On 会公告两个内省端点： token_introspection_endpoint 和 introspection_endpoint。后者是 RFC-8414 定义的。前者已弃用，现在已被删除。

在以前的 Red Hat Single Sign-On 版本中，当 LDAP 供应商配置了 Import Users OFF 时，即使在一些非 LDAP 映射的属性被改变时，也可以更新该用户。这种情况会导致行为混淆。属性似乎被更新，但没有更新。

例如，如果您试图使用 admin REST API 更新用户，且用户有一些不正确的属性，则相应的更新是可能的。对于当前版本，无法更新，您就原因立即通知您。

Red Hat Single Sign-On 服务器已升级到使用 EAP 7.3 作为底层容器。这个更改不会直接涉及任何特定的 Red Hat Single Sign-On 服务器功能，但一些与迁移相关的变化。

我们进行了一些与身份验证流程有关的重构和改进，这需要在迁移过程中注意。

此发行版本解决了在 realm 中创建重复的顶层组的问题。但是，存在以前的重复组会导致升级过程失败。如果 Red Hat Single Sign-On 服务器使用 H2、MariaDB、MySQL 或 PostgreSQL 数据库，则 Red Hat Single Sign-On 服务器可能会受到此问题的影响。在启动升级前，检查服务器是否包含重复的顶层组。例如，可以在数据库级别执行以下 SQL 查询来列出它们：

SELECT REALM_ID, NAME, COUNT(*) FROM KEYCLOAK_GROUP WHERE PARENT_GROUP is NULL GROUP BY REALM_ID, NAME HAVING COUNT(*) > 1;

SELECT REALM_ID, NAME, COUNT(*) FROM KEYCLOAK_GROUP WHERE PARENT_GROUP is NULL GROUP BY REALM_ID, NAME HAVING COUNT(*) > 1;

每个域中只能有一个顶级组的名称相同。升级前，应检查并删除重复操作。升级中的错误包括消息 Change META-INF/jpa-changelog-9.0.1.xml::9.0.1- KEYCLOAK-12579-add-not-null-constraint::keycloak 失败。

我们在存储用户凭证方面增加了更大的灵活性。另外，每个用户都可以拥有同一类型的多个凭证，如多个 OTP 凭证。与数据库模式的关系存在一些变化，但之前版本中的凭证会更新为新的格式。用户仍可使用之前版本中定义的密码或 OTP 凭证登录。

我们已经添加了一个 microprofile-jwt 可选客户端范围，以处理 MicroProfile/JWT Auth 规范中定义的声明。这个新客户端范围定义了协议映射程序，将经过身份验证的用户的用户名设置为 upn 声明，并将 realm 角色设置为组声明。

已进行了一些改进，可以如何选择登录页面的区域，以及为用户更新区域设置。详情请查看 服务器管理指南。

您不再需要在 JavaScript 适配器中设置 promiseType，且两者同时可用。建议您尽可能更新应用来使用原生承诺 API (then 和 catch)，因为旧 API （成功和错误）将在某个时候被删除。

到目前为止，管理员可通过红帽单点登录管理控制台和 RESTful Admin API 将脚本上传到服务器。现在禁用这个功能。用户应该将脚本直接部署到服务器。如需更多详细信息，请查看 JavaScript Providers。

在以前的版本中，开发人员被允许为 JavaScript 适配器提供客户端凭证。现在，这个能力已被移除，因为客户端应用程序无法安全保护 secret。将 prompt=none 传播到默认 IDP 的功能

我们在名为 Accepts prompt=none 转发的 OIDC 身份提供程序配置中添加了一个切换，以找出能够处理包含 prompt=none 查询参数的转发请求的 IDP。

到目前为止，当收到带有 prompt=none 的 auth 请求时，如果域没有在 realm 中进行身份验证，则域会返回 login_required 错误，而无需检查用户是否由 IDP 进行身份验证。现在，如果可以为 auth 请求确定了一个默认 IDP （使用 kc_idp_hint 查询 param，或通过设置域的默认 IDP）以及 Accepts 提示=none 转发（来自 IDP），则 auth 请求将转发到 IDP，以检查用户是否已通过身份验证。

请注意，只有指定默认 IDP 时，此切换才会考虑。在这种情况下，我们知道在什么位置转发 auth 请求而无需提示用户选择 IDP。如果无法确定默认 IDP，我们不能假定将用于实现身份验证请求，因此不会执行请求转发。

请求和固定主机名供应商已被新的默认主机名供应商替代。请求和固定主机名供应商现已弃用，我们建议您尽快切换到默认主机名供应商。

某些功能的状态发生了变化。

Authorization Services Drools 策略已被删除。

添加了对 UMA 2.0 的支持。这个 UMA 规范版本引进了一些有关从服务器获取权限的方式的重要变化。

以下是 UMA 2.0 支持的主要变化。详情请查看授权服务指南。

我们添加了对客户端范围的支持，这需要在迁移过程中需要注意。

我们已经添加了新的域默认客户端范围 角色和 web-origins。这些客户端范围包含协议映射程序，用于将用户的角色添加并允许的 web origins 到令牌。在迁移过程中，这些客户端范围应自动添加到所有 OpenID Connect 客户端中，作为默认的客户端范围。因此，数据库迁移完成后不需要设置。

Red Hat Single Sign-On 服务器已升级到使用 EAP 7.2 作为底层容器。这不会直接涉及任何特定的 Red Hat Single Sign-On 服务器功能，但有一些与迁移相关的更改，值得提到。

在以前的版本中，建议您使用过滤器指定允许的主机名。现在，可以设置固定的主机名，这有助于确保使用有效主机名，并允许内部应用程序通过替代 URL 调用 Red Hat Single Sign-On，例如内部 IP 地址。建议您在生产环境中切换到此方法。

要将原生 JavaScript promise与 JavaScript 适配器搭配使用，现在需要在 init 选项中将 promiseType 设置为 native。

过去，如果原生承诺提供一个打包程序，它同时提供了传统 Keycloak 承诺和原生承诺。这会导致因为错误处理程序总是在原生错误事件前设置问题，这会导致 Uncaught （承诺） 错误。

Red Hat Single Sign-On 中的 Microsoft Identity Provider 实施，用于依赖 Live SDK 端点授权并获取用户配置集。从 2018 年 11 月，Microsoft 不再使用对 Live SDK API 的支持，而是使用新的 Microsoft Graph API。Red Hat Single Sign-On 身份提供程序已更新为使用新的端点，因此如果此集成正在使用，请确保升级到最新的 Red Hat Single Sign-On 版本。

因为应用程序以 id 格式更改，在"Live SDK 应用程序"下注册的传统客户端应用程序将无法与 Microsoft Graph 端点一起工作。如果您遇到错误，说明 目录中找不到应用程序标识符，则必须在 Microsoft 应用程序注册门户中再次注册客户端应用程序 来获取新的应用程序 ID。

Red Hat Single Sign-On 中的 Google Identity Provider 实施，用于依赖 Google+ API 端点进行授权并获取用户配置集。从 2019 年 3 月，Google 删除了对 Google+ API 的支持，而是使用新的 Google Sign-in 身份验证系统。Red Hat Single Sign-On 身份提供程序已更新为使用新的端点，因此如果此集成正在使用，请确保升级到最新的 Red Hat Single Sign-On 版本。

如果您遇到错误，说明 目录中找不到应用程序标识符，则必须在 Google API 控制台 门户中再次注册客户端应用程序来获取新的应用程序 ID 和 secret。

可能需要调整 Google+ 用户信息端点提供的非标准声明的自定义映射程序，并且由 Google Sign-in API 在不同的名称下提供。有关可用声明的最新信息，请参阅 Google 文档。

使用 LinkedIn 进行相应操作，所有开发人员都需要迁移到其 API 和 OAuth 2.0 的版本 2.0。因此，我们更新了 LinkedIn Social Broker。

使用此代理的现有部署可能会在使用 LinkedIn API 版本 2 获取用户配置集时遇到错误。此错误可能与缺少授予用来配置代理的客户端应用程序的权限有关，这些代理可能无法在身份验证过程中访问 Profile API 或请求特定的 OAuth2 范围。

即使新创建的 LinkedIn 客户端应用程序，您需要确保客户端能够请求 r_liteprofile 和 r_emailaddress OAuth2 范围，并且客户端应用程序可以从 https://api.linkedin.com/v2/me 端点获取当前的成员配置集。

由于 LinkedIn 所实施的隐私限制可以访问成员信息以及当前成员的配置文件 API 返回的有限声明集合，LinkedIn Social Broker 现在使用成员的电子邮件地址作为默认用户名。这意味着，在身份验证期间发送授权请求时，始终设置 r_emailaddress。

我们已经添加了两个新的密码哈希算法(pbkdf2-sha256 和 pbkdf2-sha512)。新域将使用 pbkdf2-sha256 哈希算法，带 27500 哈希迭代。由于 pbkdf2-sha256 比 pbkdf2 的迭代速度比 20000 增加到 27500。

如果密码策略包含哈希算法（没有指定）和迭代（未指定）和迭代的默认值，则会升级现有的域。如果您更改了哈希迭代，则需要手动更改为 pbkdf2-sha256 （如果使用更为安全的哈希算法）。

在 RH-SSO 7.0 中，如果授权请求中存在 scope=openid 查询参数，则返回 ID 令牌。根据 OpenID Connect 规格，这不正确。

在 RH-SSO 7.1 中，在适配器中添加了此查询参数，但保留了旧行为来容纳迁移。

在 RH-SSO 7.2 中，这个行为已更改，现在需要 scope=openid 查询参数来将请求标记为 OpenID Connect 请求。如果省略了这个查询参数，则不会生成 ID Token。

Microsoft JDBC Driver 6.0 需要向 JDBC 驱动程序模块添加其他依赖项。如果您在使用 Microsoft SQL Server 时观察 NoClassDefFoundError 错误，请在 JDBC driver module.xml 文件中添加以下依赖项：

<module name="javax.xml.bind.api"/>

<module name="javax.xml.bind.api"/>

OpenID Connect Session Management 规格要求 OpenID Connect Authentication 响应中存在参数 session_state。

在 RH-SSO 7.1 中，我们没有这个参数，但现在，Red Hat Single Sign-On 会默认添加此参数，如规格要求。

但是，一些 OpenID Connect / OAuth2 适配器，尤其是旧的 Red Hat Single Sign-On 适配器（如 RH-SSO 7.1 和更早版本），可能对此新参数出现问题。

例如，在客户端应用身份验证后，浏览器 URL 中将始终存在该参数。如果您使用 RH-SSO 7.1 或传统的 OAuth2 / OpenID Connect 适配器，在身份验证响应中添加 session_state 参数可能会很有用。这可以在 Red Hat Single Sign-On admin 控制台中的特定客户端完成，在使用 OpenID Connect 兼容性模式 一节中的客户端详情，如 第 4.1 节 “与旧的适配器兼容” 所述。存在 Exclude Session State From Authentication Response 开关，可打开 以防止将 session_state 参数添加到身份验证响应中。

Red Hat Single Sign-On 中的 Microsoft Identity Provider 实施版本 7.2.4 依赖于 Live SDK 端点来授权并获取用户配置集。从 2018 年 11 月，Microsoft 不再使用对 Live SDK API 的支持，而是使用新的 Microsoft Graph API。Red Hat Single Sign-On 身份提供程序已更新为使用新的端点，因此如果此集成在使用中，请确保升级到 Red Hat Single Sign-On 版本 7.2.5 或更高版本。

因为应用程序以 id 格式更改，在"Live SDK 应用程序"下注册的传统客户端应用程序将无法与 Microsoft Graph 端点一起工作。如果您遇到错误，说明 目录中找不到应用程序标识符，则必须在 Microsoft 应用程序注册门户中再次注册客户端应用程序 来获取新的应用程序 ID。

Red Hat Single Sign-On 中的 Google Identity Provider 实施最多版本 7.2.5 依赖于 Google+ API 端点进行授权并获取用户配置集。从 2019 年 3 月，Google 删除了对 Google+ API 的支持，而是使用新的 Google Sign-in 身份验证系统。Red Hat Single Sign-On 身份提供程序已更新为使用新的端点，因此如果此集成在使用中，请确保升级到 Red Hat Single Sign-On 版本 7.2.6 或更高版本。

如果您遇到错误，说明 目录中找不到应用程序标识符，则必须在 Google API 控制台 门户中再次注册客户端应用程序来获取新的应用程序 ID 和 secret。

可能需要调整 Google+ 用户信息端点提供的非标准声明的自定义映射程序，并且由 Google Sign-in API 在不同的名称下提供。有关可用声明的最新信息，请参阅 Google 文档。

使用 LinkedIn 进行相应操作，所有开发人员都需要迁移到其 API 和 OAuth 2.0 的版本 2.0。因此，我们更新了 LinkedIn Social Broker，因此如果此集成在使用中，请确保升级到 Red Hat Single Sign-On 版本 7.2.6 或更高版本。

使用此代理的现有部署可能会在使用 LinkedIn API 版本 2 获取用户配置集时遇到错误。此错误可能与缺少授予用来配置代理的客户端应用程序的权限有关，这些代理可能无法在身份验证过程中访问 Profile API 或请求特定的 OAuth2 范围。

即使新创建的 LinkedIn 客户端应用程序，您需要确保客户端能够请求 r_liteprofile 和 r_emailaddress OAuth2 范围，并且客户端应用程序可以从 https://api.linkedin.com/v2/me 端点获取当前的成员配置集。

由于 LinkedIn 所实施的隐私限制可以访问成员信息以及当前成员的配置文件 API 返回的有限声明集合，LinkedIn Social Broker 现在使用成员的电子邮件地址作为默认用户名。这意味着，在身份验证期间发送授权请求时，始终设置 r_emailaddress。

对于 RH-SSO 7.0，只有一组密钥可以与一个域相关联。这意味着，在更改密钥时，所有当前 Cookie 和令牌都将被无效，并且所有用户都必须重新验证。对于 RH-SSO 7.1，增加了对一个域的多个密钥的支持。在任何给定时间，一组用于创建签名的活动密钥是活跃的集合，但可以使用多个密钥来验证签名。这意味着可以验证旧的 Cookie 和令牌，然后使用新签名刷新，允许用户在密钥更改时保持身份验证。还有一些更改是通过管理控制台和管理 REST API 管理密钥；如需更多详情，请参阅服务器管理指南中的 Realm Keys 部分。

要允许无缝密钥轮转，您必须从客户端适配器中删除硬编码的密钥。只要未指定域密钥，客户端适配器将自动从服务器检索密钥。客户端适配器也会在密钥轮转时自动检索新密钥。

对于 RH-SSO 7.0，当与客户端的有效重定向 URI 匹配时，会忽略查询参数。对于 RH-SSO 7.1，不再忽略查询参数。如果您需要在重定向 URI 中包含查询参数，则必须指定客户端的有效重定向 URI 中的查询参数（例如 https://hostname/app/login?foo=bar），或使用通配符（如 https://hostname/app/login/*）。Valid Redirect URI （即 https://hostname/app#fragment）中也不再允许片段。

对于 RH-SSO 7.1，身份提供程序不能设置为默认身份验证提供程序。要自动重定向到 RH-SSO 7.1 的身份供应商，现在您必须配置身份提供程序重定向器。有关更多信息，请参阅 《 服务器管理指南》 中的默认身份提供商。如果您之前设置了默认身份验证提供程序选项，则该值会在服务器升级到 RH-SSO 7.1 时自动用作身份提供程序重定向的值。

对于 RH-SSO 7.0，如果没有指定 maxResults 查询参数，在 Admin REST API 中分页端点会返回所有结果。这可能会导致临时高负载和请求在返回大量结果时出现的问题（例如，用户）。对于 RH-SSO 7.1，如果没有指定 maxResults 的值，则返回最多 100 个结果。您可以通过将 maxResults 指定为 -1 来返回所有结果。

对于 RH-SSO 7.0，服务器配置在 keycloak-server.json 文件和 standalone/domain.xml 或 domain.xml 文件之间进行分割。对于 RH-SSO 7.1，keycloak-server.json 文件已被删除，并且所有服务器配置都通过 standalone.xml 或 domain.xml 文件来完成。RH-SSO 7.1 的升级步骤会自动将服务器配置从 keycloak-server.json 文件迁移到 standalone.xml 或 domain.xml 文件。

对于 RH-SSO 7.1，SAML 断言和文档中的密钥现在使用 RSA-OAEP 加密方案进行加密。要使用加密的断言，请确保您的服务提供商支持这个加密方案。如果您的服务提供商不支持 RSA-OAEP，则 RH-SSO 可以配置为使用旧的 RSA-v1.5 加密方案，方法是使用系统属性 "keycloak.saml.saml.key_trans.rsa_v1.5"设置为 true。如果这样做，应该尽快升级您的服务提供商，以便可以恢复到更安全的 RSA-OAEP 加密方案。

在升级前，请了解执行升级步骤所需的顺序。特别是，在升级适配器前，请务必升级 Red Hat Single Sign-On 服务器。

按照以下步骤确保服务器升级成功：

根据您用于安装的方法从 ZIP 文件或 RPM 升级服务器。

根据您的之前安装，运行适用于您的情况的适当升级脚本：

Red Hat Single Sign-On 可以自动迁移数据库模式，也可以选择手动进行。默认情况下，当您第一次启动新安装时，数据库会被自动迁移。

 <spi name="connectionsJpa">
    <provider name="default" enabled="true">
        <properties>
            ...
            <property name="migrationStrategy" value="update"/>
        </properties>
    </provider>
</spi>

 <spi name="connectionsJpa">
    <provider name="default" enabled="true">
        <properties>
            ...
            <property name="migrationStrategy" value="update"/>
        </properties>
    </provider>
</spi>

/subsystem=keycloak-server/spi=connectionsJpa/provider=default/:map-put(name=properties,key=migrationStrategy,value=update)

/subsystem=keycloak-server/spi=connectionsJpa/provider=default/:map-put(name=properties,key=migrationStrategy,value=update)

<spi name="connectionsLiquibase">
    <provider name="default" enabled="true">
        <properties>
            <property name="indexCreationThreshold" value="300000"/>
        </properties>
    </provider>
</spi>

<spi name="connectionsLiquibase">
    <provider name="default" enabled="true">
        <properties>
            <property name="indexCreationThreshold" value="300000"/>
        </properties>
    </provider>
</spi>

/subsystem=keycloak-server/spi=connectionsLiquibase/:add(default-provider=default)
/subsystem=keycloak-server/spi=connectionsLiquibase/provider=default/:add(properties={indexCreationThreshold => "300000"},enabled=true)

/subsystem=keycloak-server/spi=connectionsLiquibase/:add(default-provider=default)
/subsystem=keycloak-server/spi=connectionsLiquibase/provider=default/:add(properties={indexCreationThreshold => "300000"},enabled=true)

 <spi name="connectionsJpa">
    <provider name="default" enabled="true">
        <properties>
            ...
            <property name="migrationStrategy" value="manual"/>
        </properties>
    </provider>
</spi>

 <spi name="connectionsJpa">
    <provider name="default" enabled="true">
        <properties>
            ...
            <property name="migrationStrategy" value="manual"/>
        </properties>
    </provider>
</spi>

/subsystem=keycloak-server/spi=connectionsJpa/provider=default/:map-put(name=properties,key=migrationStrategy,value=manual)

/subsystem=keycloak-server/spi=connectionsJpa/provider=default/:map-put(name=properties,key=migrationStrategy,value=manual)

如果您创建了任何自定义主题，则必须将其迁移到新服务器。根据您的已定制的功能，对内置主题的任何更改都可能需要反映在您的自定义主题中。

您必须将自己的自定义主题从旧服务器 复制到新的 服务器 主题 目录。在您需要查看以下更改之后，考虑更改是否需要应用到您的自定义主题。

总结：

每个步骤都会在更改列表的下面详细阐述。

diff RHSSO_HOME_OLD/themes/keycloak/login/resources/css/login.css \
RHSSO_HOME_NEW/themes/keycloak/login/resources/css/login.css

$ diff RHSSO_HOME_OLD/themes/keycloak/login/resources/css/login.css \
RHSSO_HOME_NEW/themes/keycloak/login/resources/css/login.css

可以从红帽客户门户下载 RH-SSO 的 ZIP 安装补丁。

对于受管域环境中的多个 RH-SSO 主机，可以从您的 RH-SSO 域控制器中修补各个主机。

除了应用补丁程序外，您还可以回滚补丁应用程序。

/core-service=patching:ageout-history

/core-service=patching:ageout-history

要通过 RPM 从订阅的存储库安装 RH-SSO 补丁，请使用以下命令更新您的 Red Hat Enterprise Linux 系统：

yum update

yum update