2.4. RH-SSO 7.3

以下更改已从 RH-SSO 7.2 变为 RH-SSO 7.3。

2.4.1. 授权服务更改

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

删除了授权 API

在 UMA 2.0(UMA 1.0)之前，客户端应用程序使用 Authorization API 从服务器获取权限，格式为 RPT。新版本的 UMA 规格已删除了从 Red Hat Single Sign-On 中删除的 Authorization API。在 UMA 2.0 中，现在可使用特定授权类型从令牌端点获取 RPT。详情请参阅授权服务指南。

删除授权 API

随着 UMA 2.0 的推出，我们决定利用令牌端点和 UMA 授权类型，以允许从红帽单点登录中获取 RPT，并避免具有不同 API。Entitlement API 提供的功能相同，仍然有可能获取一个或多个资源和范围的权限，如果没有提供资源或范围，则仍有可能获得一个或多个资源和范围的权限。详情请参阅授权服务指南。

UMA 发现端点的更改

UMA Discovery 文档已更改，请参阅授权服务指南。

Red Hat Single Sign-On Authorization JavaScript adapter 的更改

Red Hat Single Sign-On Authorization JavaScript adapter(keycloak-authz.js)已更改，以符合 UMA 2.0 引入的变化，同时保持之前的行为相同。主要变化在于如何调用 授权和授权 方法，它们现在期望一个代表授权请求的特定对象类型。这个新对象类型提供了更多灵活性，它通过支持 UMA 授权类型支持从服务器获取权限的方式获得权限。详情请参阅授权服务指南。

One of the main changes introduced by this release is that you are no longer required to exchange access tokens with RPTs in
order to access resources protected by a resource server (when not using UMA). Depending on how the policy enforcer is configured on the resource server side, you can just send regular
access tokens as a bearer token and permissions will still be enforced.

Red Hat Single Sign-On Authorization Client Java API 的更改

当升级到 Red Hat Single Sign-On Authorization Client Java API 的新版本时，您会注意到某些表示类被移到 org.keycloak:keycloak:keycloak-core 的不同软件包中。

2.4.2. 客户端模板更改为客户端范围

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

客户端模板更改为客户端范围: 客户端模板已更改为客户端范围。如果您有任何客户端模板，则会保留其协议映射程序和角色范围映射。
空格替换为名称: 使用名称中的空格替换空格来重命名了名称中的客户端模板，因为客户端范围名称中不允许有空格。例如，我的 模板将更改为客户端范围 my_template。
将客户端范围链接到客户端: 对于具有客户端模板的客户端，对应的客户端范围现在被添加为 客户端的默认客户端范围。因此，客户端上会保留协议映射程序和角色范围映射。
与现有客户端没有关联的域默认客户端范围: 在迁移过程中，内置客户端范围列表添加到每个域，以及 Realm Default Client Scopes 列表。但是，现有客户端不会被升级，新的客户端范围不会被自动添加到它们。另外，所有协议映射程序和角色范围映射都保存在现有客户端上。在新版本中，当您创建新客户端时，它会自动附加 Realm Default Client Scopes，它没有附加任何协议映射程序。我们在迁移过程中不会更改现有客户端，因为无法正确地检测到自定义，例如，客户端具有协议映射程序。如果要更新现有客户端（删除协议映射程序），并使用客户端范围链接它们，您需要手动操作。
需要再次确认同意: 客户端范围更改需要重构为同意。现在同意会指向客户端范围，而不是角色或协议映射程序。由于这一更改，之前确认用户的永久同意已经有效，用户需要在迁移后再次确认同意页面。
一些配置切换已删除: 从角色详情中删除了交换机 范围范围（必需 ）。交换机 Consent Required 和 Consent 文本 已从协议映射程序详情中删除。这些交换机由 Client Scope 功能替代。

2.4.3. 新的默认客户端范围

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

2.4.3.1. 协议映射程序 SPI 添加了

与这一点相关，在（不支持）协议映射程序中会有一个小的补充。只有在您实施了自定义 ProtocolMapper 时，才能受到影响。ProtocolMapper 接口中有一个新的 getPriority（） 方法。该方法将默认实施设置为返回 0。如果您的协议映射程序实施依赖于访问令牌 realmAccess 或 resourceAccess 属性中的角色，您可能需要增加映射程序的优先级。

2.4.3.2. 受众解决

所有经过身份验证的用户在令牌中有至少一个客户端角色的客户端现在会自动添加到访问令牌中的声明中。另一方面，访问令牌不会自动包含发布该前端客户端的读者。详情请查看服务器管理指南。

2.4.4. 升级到 EAP 7.2

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

依赖项更新

依赖项已更新至 EAP 7.2 服务器使用的版本。例如，Inftables 现在是 9.3.1.Final。

配置更改

standalone（-ha.xml 和 domain.xml 文件中有一些配置更改。您应该遵循第 3.1.2 节 “升级 Red Hat Single Sign-On 服务器” 部分自动处理配置文件迁移。

跨数据中心复制更改

您需要将 RHDG 服务器升级到 7.3 版本。旧版本可能仍然可以正常工作，但无法保证，我们再无法对其进行测试。
需要使用在 Red Hat Single Sign- On 配置中将 protocolVersion 属性添加到 remote-store 元素的配置中。需要这个功能，因为需要降级 HotRod 协议的版本与 RHDG 7.3 使用的版本兼容。

2.4.5. 主机名配置

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

2.4.6. JavaScript 适配器承诺

要将原生 JavaScript 适配器用于 JavaScript 适配器，需要在 init 选项中将 promiseType 设置为 native。

过去，如果本地承诺提供的打包程序已被返回，为旧的 Keycloak 承诺和原生承诺提供。这是因为错误处理器在原生错误事件之前没有始终设置问题，从而导致 Uncaught（承诺） 错误。

2.4.7. Microsoft Identity Provider 更新为使用 Microsoft Graph API

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。

2.4.8. Google Identity Provider 更新为使用 Google Sign-in 身份验证系统

红帽单点登录中的 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 文档。

2.4.9. LinkedIn social Broker 更新至 LinkedIn API 版本 2

使用 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 会始终设置。