当 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 7.3 升级到 Red Hat Single Sign-On 7.6），只要没有使用私有、不支持或技术预览 API，则应用程序或自定义服务器扩展不需要代码更改。

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

微版本仅包含更改的工件。例如，如果 Red Hat Single Sign-On 7.6.1 包含对服务器和 JavaScript 适配器的更改，则仅发布服务器和 JavaScript 适配器，需要更新。

分步身份验证是一项新功能。此功能提供了 cr 客户端范围，它包含应当在令牌中添加 cr 声明的协议映射程序。现在，这个声明会被自动添加，而是使用这个客户端范围和协议映射程序。

客户端范围被添加为域"默认"客户端范围，因此将添加到所有新创建的客户端。出于性能考虑，在迁移期间，客户端范围不会自动添加到所有现有客户端。迁移后，客户端默认不会 具有cr 声明。考虑以下可能的操作：

insert into CLIENT_SCOPE_CLIENT (CLIENT_ID, SCOPE_ID, DEFAULT_SCOPE) select CLIENT.ID as CLIENT_ID, CLIENT_SCOPE.ID as SCOPE_ID, true as DEFAULT_SCOPE
from CLIENT_SCOPE, CLIENT where CLIENT_SCOPE.REALM_ID='test' and CLIENT_SCOPE.NAME='acr' and CLIENT.REALM_ID='test' and CLIENT.PROTOCOL='openid-connect';

以前版本的 Red Hat Single Sign-On 支持自动注销用户，并通过打开注销端点 URL（如 http(s)://example-host/auth/realms/my-realm-name/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri ）来重定向到应用程序。虽然这种实施非常容易使用，但可能会对性能和安全性造成负面影响。根据 OpenID Connect RP-Initiated Logout 规格，新版本可以更好地支持注销。参数 redirect_uri 不再被支持；此外，新版本中，用户需要确认注销。当包含参数 post_logout_redirect_uri 和用于登录的 ID Token 时，可以省略确认并自动重定向到应用程序。

现有部署会受到以下方法影响：

有一个后向兼容选项，它允许您的应用程序仍然使用 redirect_uri 参数的旧格式。

您可以通过在 standalone-*.xml 文件中包括以下配置来启用这个参数

<spi name="login-protocol">
    <provider name="openid-connect" enabled="true">
        <properties>
            <property name="legacy-logout-redirect-uri" value="true"/>
        </properties>
    </provider>
</spi>

使用这个配置，您仍然可以将格式与 redirect_uri 参数搭配使用。请注意，如果省略 id_token_hint，则需要确认屏幕。

以前版本的 Red Hat Single Sign-On 支持通过管理控制台和 REST API 等管理界面来管理 JavaScript 代码。从此版本开始，您现在应该将脚本部署到服务器，以配置以下供应商：

有关如何将脚本部署到服务器的详细信息，请参阅文档。请注意，要使用脚本，您仍需要启用 脚本 技术预览功能。

./standalone.sh -Dkeycloak.profile=preview

在部署脚本时，服务器将自动创建对应的供应商，以便您可以配置身份验证流程、映射程序和授权策略时选择它们。

通常，更新您的域的步骤如下：

Patternfly(PF)React 库已被更新，@patternfly/react-core 从 v3.153.3 升级到 v4.147.0, @patternfly/react-icons from v3.15.16，将 @patternfly/react-styles 从 v3.7.14 变为 v4.11.8。进行了几个 UI 更新，使帐户控制台与 PF 设计标准一致。

自定义开发的帐户 UI 可能会因为 PF 中的破坏更改而与这些更新不兼容。大多数有问题的更改应该通过更新 PF 组件来改变。

resources:

已知有破坏更改的组件：

如果您使用了策略，包括客户端范围条件并直接编辑的 JSON 文档，则需要在 JSON 文档中将 "scope" 字段名称更改为"scopes"。

Liquibase 从 3.5.5 版本更新至 4.6.2，其中包括一些程序错误、一些程序错误修复以及使用 ServiceLoader 注册自定义扩展的新方法。

遵循 升级指南，特别是在升级前备份现有数据库。虽然我们最好测试 Liquibase 升级的结果，但有些安装可能会对我们使用特定的设置未知。

在这个版本中，我们已在 Red Hat Single Sign-On Operator 的 Keycloak CR 中弃用了 podDisruptionBudget 字段。当 Operator 部署到 OCP 4.12 及更高版本中时，此可选字段将被忽略。

作为临时解决方案，您可以在集群中创建 Pod Disruption Budget，例如：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  labels:
    app: keycloak
  name: keycloak
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      component: keycloak

另请参阅 Kubernetes 文档。

由于之前版本的 Operator 中存在一个关键错误，RH-SSO StatefulSet 上的 Selector 字段配置错误。错误配置可能会破坏升级过程从 7.5 到 7.6，从而会阻止成功进行 RH-SSO 部署。

随着 Operator 补丁发行版本，我们引入了一个修复程序。请注意，作为修复 Operator 的一部分，在从 7.5 升级到 7.6 的过程中可能会 删除并重新创建 RH-SSO StatefulSet。要使修复正常工作，请确定您使用 重新创建 的升级策略。请参阅 服务器安装和配置指南中的相关章节。

为了与 7.6.2 中引入的 Red Hat Single Sign-On OpenShift 镜像中的更改一致，Operator 现在利用镜像中默认的存活度和就绪度探测，而不是使用自定义探测。对于现有的 Red Hat Single Sign-On 部署，Operator 将在升级过程中尝试自动更新探测。但是，如果您通过手动更改 keycloak-probes ConfigMap 来自定义探测，Operator 不会更新探测以避免覆盖用户修改。在这种情况下，您必须手动更新探测（或删除 ConfigMap 以便 Operator 重新创建它）；否则升级的 Red Hat Single Sign-On 7.6.2 部署将显示为未就绪。

为了允许在启用了 FIPS 的环境中运行，探测验证哈希算法已改变。对于探测的默认超时为 1 秒的基于模板的安装，并且指定了小于 1 的 CPU 限值，这可能会导致持续探测失败。如果这些失败会导致重启，您应该通过更改 DeploymentConfig 或实际到新发布的模板来增加探测超时，这与 Operator 中使用的内容有更大的超时值。

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

<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}"/>

UserModel 包括某些字段、用户名、电子邮件、firstName 和 lastName，这些字段现在转换为自定义属性。进行了此更改，准备将更复杂的用户配置文件添加到 Red Hat Single Sign-On。

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

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

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 URI，以防止 SSRF 攻击

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

您可以使用通配符或相对路径，如 Valid Redirect URIs 选项。但是，我们建议在安全中使用 作为具体值。

现在，只读用户属性可用。在使用 REST API 更新用户或红帽单点登录用户界面时，用户或管理员不会编辑其中的一些用户属性。特别是，在使用以下任一时，这个更改很重要：

详情请查看 Threat model 缓解方案。

在使用 Docker 协议成功进行身份验证后，不会创建用户会话。有关详细信息，请参阅《 服务器管理指南》。

对于此 Red Hat Single Sign-On 版本，OAuth2 客户端凭证Grant 端点默认不会发布刷新令牌。此行为与 OAuth2 规范一致。

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

因此，红帽单点登录支持在 OAuth2 Revocation 端点中撤销访问令牌。因此，如果需要，允许客户端撤销单独的访问令牌。

为了向后兼容，您可以继续使用之前的版本的行为。采用这种方法时，刷新令牌在成功与客户端凭证授予身份验证后，也会被创建用户会话。对于特定客户端，您可以在管理控制台中启用之前的行为，如下所示：

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

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

例如，如果您试图使用 admin REST API 更新用户，并且用户有一些不正确的属性更改，则更新可能会发生。对于当前版本，无法更新，因此会立即通知您。

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

我们对身份验证流程进行了一些重构并改进，在迁移过程中需要注意它们。

此发行版本解决了在域中创建重复的顶层组的问题。存在之前重复的组会使升级过程失败。如果使用 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;

每个域中只能有一个顶层组名称。在升级前，应检查和删除重复项。升级中的错误包含消息 Change Set 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 规范中定义的声明。这个新客户端范围定义了 protocol 映射程序，将经过身份验证的用户的用户名设置为 upn 声明，并将 realm 角色设置为组声明。

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

您不再需要在 JavaScript 适配器中设置 promiseType，且两者同时可用。建议尽可能立即更新应用程序以使用原生保证 API（then 和 catch），因为旧 API（成功和错误）将在某个点上被删除。

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

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

我们已在名为 Accepts prompt=none forward from client 的 OIDC 身份提供程序配置中添加了一个切换，以标识可以处理包含 prompt=none 查询参数的 IDP。

在现在之前，在收到带有 prompt=none 的 auth 请求时，如果用户没有通过 IDP 进行身份验证，则域将返回 login_required 错误。现在，如果可以从现在确定默认 IDP（可以使用 kc_idp_hint 查询 param，或者为域设置默认 IDP）以及是否已为 IDP 启用了 Accepts prompt=none，则验证请求将转发到 IDP，检查用户是否已通过身份验证。

务必要注意，只有在指定了默认 IDP 时，这个切换才被考虑。在这种情况下，我们知道在不需要提示用户选择 IDP 的情况下转发 auth 请求。如果无法确定默认的 IDP，我们不能假设将使用哪个 IDP 来实现 auth 请求，因此不会执行请求转发。

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

某些功能在状态有变化。

Authorization Services Drools Policy 已被删除。

我们添加了对 UMA 2.0 的支持。此版本的 UMA 规范中引入了一些重要的更改，它是如何从服务器获得权限的方式。

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

添加了对客户端范围的支持，这需要在迁移期间进行一些关注。

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

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

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

要将原生 JavaScript 适配器用于 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 版本。

在 "Live SDK 应用程序" 下注册的传统客户端应用程序不会因为应用程序的 id 格式更改而用于 Microsoft Graph 端点。如果遇到错误，表示 目录中未找到应用程序标识符，则必须在 Microsoft Application Registration Portal 中再次注册客户端应用程序以获取新的应用程序 ID。

红帽单点登录中的 Google 身份提供程序实施，用于依赖 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 对这些隐私限制导致对成员的信息的访问以及当前成员的 Profile API 返回的一组有限声明集，LinkedInSocial Broker 现在使用成员的电子邮件地址作为默认用户名。这意味着，在身份验证过程中发送授权请求时，r_emailaddress 会始终设置。

我们添加了两个新的密码哈希算法（pbkdf2-sha256 和 pbkdf2-sha512）。新域将使用 pbkdf2-sha256 哈希算法，并带有 27500 哈希迭代。由于 pbkdf2-sha256 比 pbkdf2 快于 pbkdf2，因此迭代从 20000 增加到 27500。

如果密码策略包含哈希算法（未指定）和迭代(20000)的默认值，则会升级现有 realm。如果您更改了散列迭代，如果您需要使用更安全的哈希算法，则需要手动更改为 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 驱动程序 module.xml 文件中添加以下依赖项：

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

OpenID Connect Session Management 规格要求参数 session_state 存在于 OpenID Connect 身份验证响应中。

在 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 管理控制台中为特定的客户端完成，在带有 OpenID Connect Compatibility Modes 部分的客户端详情中，如 第 4.1 节 “与旧的适配器兼容” 所述。还有 Exclude Session State From Authentication Response 开关，它可以被打开，以防止将 session_state 参数添加到身份验证响应中。

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

在 "Live SDK 应用程序" 下注册的传统客户端应用程序不会因为应用程序的 id 格式更改而用于 Microsoft Graph 端点。如果遇到错误，表示 目录中未找到应用程序标识符，则必须在 Microsoft Application Registration Portal 中再次注册客户端应用程序以获取新的应用程序 ID。

Red Hat Single Sign-On up to version 7.2.5 中的 Google Identity Provider 实现依赖于 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 对这些隐私限制导致对成员的信息的访问以及当前成员的 Profile API 返回的一组有限声明集，LinkedInSocial Broker 现在使用成员的电子邮件地址作为默认用户名。这意味着，在身份验证过程中发送授权请求时，r_emailaddress 会始终设置。

对于 RH-SSO 7.0，只有一组键可以与一个域关联。这意味着，在更改密钥时，所有当前的 cookie 和令牌都会无效，所有用户都必须重新验证。对于 RH-SSO 7.1，增加了对一个域的多个密钥的支持。在任何给定时间，一个密钥集就是用于创建签名的有效集，但可使用多个密钥来验证签名。这意味着可以验证旧的 cookie 和令牌，然后使用新的签名刷新，从而允许用户在更改密钥时保持身份验证。另外，还有一些更改如何通过 Admin Console 和 Admin 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/*）。在有效的重定向 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.key_trans.rsa_v1.5" 的服务器。如果您这样做，应该尽快升级您的服务提供商，以便可以恢复到更安全的 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>

/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>

/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>

/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

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

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

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

/core-service=patching:ageout-history

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

yum update