搜索

第 10 章 SSO 协议

download PDF

本节讨论身份验证协议(Red Hat Single Sign-On 身份验证服务器),以及红帽单点登录身份验证服务器保护应用程序的方式,并与这些协议交互。

10.1. OpenID Connect

OpenID Connect (OIDC)是一个身份验证协议,它是 OAuth 2.0 的扩展。

OAuth 2.0 是用于构建授权协议的框架,不完整。但是,OIDC 是一个完整的身份验证和授权协议,它使用 Json Web Token (JWT)标准。JWT 标准定义了身份令牌 JSON 格式,以及以紧凑和 Web 友好的方式对数据进行数字签名的方法。

通常,OIDC 实施两个用例。第一个情况是请求红帽单点登录服务器验证用户的应用程序。成功登录后,应用程序会收到 身份令牌访问令牌身份令牌 包含用户信息,包括用户名、电子邮件和配置集信息。域 对访问令牌 进行数字签名,其中包含应用可用于决定用户在应用中可以访问的资源的访问信息(如用户角色映射)。

第二个用例是访问远程服务的客户端。

  • 客户端从 Red Hat Single Sign-On 请求 访问令牌,以代表用户在远程服务上调用。
  • Red Hat Single Sign-On 对用户进行身份验证,并要求用户同意授予请求客户端的访问权限。
  • 客户端接收由域数字签名的访问令牌
  • 客户端利用 访问令牌 在远程服务上发出 REST 请求。
  • 远程 REST 服务提取 访问令牌
  • 远程 REST 服务验证令牌签名。
  • 远程 REST 服务根据令牌中的访问信息(处理或拒绝请求)决定。

10.1.1. OIDC 身份验证流

OIDC 有几个方法或流,客户端或应用程序可以用来验证用户并接收 身份和 访问令牌。该方法取决于请求访问的应用或客户端的类型。

10.1.1.1. 授权代码流

授权代码流是基于浏览器的协议,适合验证和授权基于浏览器的应用程序。它使用浏览器重定向来获取身份访问令牌。

  1. 用户使用浏览器连接至应用。应用程序检测到用户没有登录到应用程序。
  2. 应用将浏览器重定向到红帽单点登录以进行身份验证。
  3. 应用通过回调 URL 作为浏览器重定向中的查询参数传递。红帽单点登录在成功身份验证后使用 参数。
  4. Red Hat Single Sign-On 对用户进行身份验证,并创建了一次性、简短的临时代码。
  5. Red Hat Single Sign-On 使用回调 URL 重定向到应用程序,并在回调 URL 中将临时代码添加为查询参数。
  6. 该应用提取临时代码,并对红帽单点登录进行后台 REST 调用,以交换 身份访问刷新访问令牌的代码。为防止重播攻击,无法多次使用临时代码。
注意

在那个令牌的生命周期中,系统会受到 stolen 令牌的影响。出于安全性和可扩展性的原因,访问令牌通常设置为快速过期,因此后续令牌请求会失败。如果令牌过期,应用程序可以使用由登录协议发送的额外 刷新令牌 获取新的访问令牌。

机密 客户端在交换令牌临时代码时提供客户端机密。不需要公共客户端来提供客户端 secret。当 HTTPS 被严格强制时,公共客户端安全,并且严格控制为客户端注册的 URI。HTML5/JavaScript 客户端必须是 公共客户端,因为无法安全地将客户端 secret 传输到 HTML5/JavaScript 客户端。如需了解更多详细信息,请参阅管理客户端 一章。

Red Hat Single Sign-On 还支持 代码交换 规范的验证密钥。

10.1.1.2. 隐式流

Implicit Flow 是基于浏览器的协议。它与授权代码流类似,但请求较少,也没有刷新令牌。

注意

当令牌 通过重定向 URI 传输时,访问令牌可能会泄漏(参见下文)。

另外,这个流不会为客户端提供刷新令牌。因此,访问令牌必须长期存在,或者用户在过期时必须重新验证。

我们不建议使用这个流程。支持这个流,因为它是 OIDC 和 OAuth 2.0 规范。

该协议如下:

  1. 用户使用浏览器连接至应用。应用程序检测到用户没有登录到应用程序。
  2. 应用将浏览器重定向到红帽单点登录以进行身份验证。
  3. 应用通过回调 URL 作为浏览器重定向中的查询参数传递。Red Hat Single Sign-On 在成功身份验证后使用查询参数。
  4. 红帽单点登录验证用户身份并创建 身份和 访问令牌。Red Hat Single Sign-On 使用回调 URL 重定向到应用程序,并 另添加身份和 访问令牌 作为回调 URL 中的查询参数。
  5. 应用从回调 URL 中提取 身份和 访问令牌

10.1.1.3. 资源所有者密码凭证授予(Direct Access Grants)

REST 客户端使用 直接访问 Grants 来代表用户获取令牌。这是一个 HTTP POST 请求,包含以下内容:

  • 用户的凭据。凭据以表格参数形式发送。
  • 客户端的 ID。
  • 客户端机密(如果是一个机密客户端)。

HTTP 响应包含 身份访问 和刷新令牌

10.1.1.4. 客户端凭证授权

Client Credentials Grant 根据与客户端关联的服务帐户的元数据和权限来创建令牌,而不是获取代表外部用户有效的令牌。REST 客户端使用客户端 凭据

如需更多信息,请参阅服务帐户章节。

10.1.1.5. 设备授权

这供在具有有限输入功能或缺少合适的浏览器的互联网连接设备上运行的客户端使用。以下是协议的简单概述:

  1. 应用程序请求 Red Hat Single Sign-On a device code and user code。Red Hat Single Sign-On 创建了设备代码和用户代码。Red Hat Single Sign-On 将包括设备代码和用户代码返回响应。
  2. 该应用为用户代码和验证 URI 提供用户。用户使用其他浏览器访问验证 URI 进行验证。
  3. 应用程序重复轮询 Red Hat Single Sign-On 来查找用户是否完成了用户授权。如果完成了用户身份验证,应用程序会交换 身份访问刷新令牌的设备代码。

10.1.1.6. 发起的后向通道身份验证授权的客户端

想要直接与 OpenID 提供商通信的客户端使用此功能,而无需通过 OAuth 2.0 的授权代码授权等用户浏览器重定向。以下是协议的简单概述:

  1. 客户端请求 Red Hat Single Sign-On a auth_req_id,用于标识客户端发出的身份验证请求。红帽单点登录创建 auth_req_id。
  2. 在收到这个 auth_req_id 后,这个客户端需要重复轮询 Red Hat Single Sign-On 以获取 Access Token、Refresh Token 和 ID Token,以返回 auth_req_id,直到用户通过身份验证为止。

管理员可以将客户端初始后端身份验证(CIBA)相关操作配置为每个域的 CIBA Policy

另请参阅 Red Hat Single Sign-On 文档的其他位置,如安全应用程序与服务指南中的 后端身份验证端点部分,以及 安全应用程序和服务指南的客户端初始身份验证评测部分

10.1.1.6.1. CIBA 策略

管理员在 Admin Console 上执行以下操作:

  • 打开 Authentication CIBA Policy 选项卡。
  • 配置项目,再单击保存

可配置项及其描述如下。

Configuration描述

Backchannel Token Delivery Mode

指定 CD (交换设备)如何获得验证结果和相关令牌。有三种模式,即 "poll" 和 "push"。Red Hat Single Sign-On 只支持 "poll"。默认设置为 "poll"。这个配置是必需的。如需了解更多详细信息,请参阅 CIBA 规格

过期时间

自收到身份验证请求时,"auth_req_id"的过期时间(以秒为单位)。默认设置为 120。这个配置是必需的。如需了解更多详细信息,请参阅 CIBA 规格

Interval(间隔)

CD (Consumption Device)需要等待轮询请求到令牌端点的时间间隔(以秒为单位)。默认设置为 5。此配置是可选的。如需了解更多详细信息,请参阅 CIBA 规格

请求的身份验证用户 Hint

识别最终用户请求谁进行身份验证的方法。默认设置为 "login_hint"。有三种模式:"login_hint"、"login_hint_token" 和 "id_token_hint"。Red Hat Single Sign-On only supports "login_hint".这个配置是必需的。如需了解更多详细信息,请参阅 CIBA 规格

10.1.1.6.2. 供应商设置

CIBA 授权使用以下两个供应商。

  1. 身份验证频道提供程序:提供 Red Hat Single Sign-On 和实际通过 AD 验证用户身份的实体(验证设备)之间的通信。
  2. 用户 Resolver Provider:从客户端提供的信息中获得 Red Hat Single Sign-On 的 UserModel,以标识该用户。

Red Hat Single Sign-On 兼具默认提供程序。但是,管理员需要设置身份验证频道供应商,如下所示:

<spi name="ciba-auth-channel">
    <default-provider>ciba-http-auth-channel</default-provider>
    <provider name="ciba-http-auth-channel" enabled="true">
        <properties>
            <property name="httpAuthenticationChannelUri" value="https://backend.internal.example.com/auth"/>
        </properties>
    </provider>
</spi>

可配置项及其描述如下。

Configuration描述

httpAuthenticationChannelUri

指定实际通过 AD 验证用户身份的实体的 URI (身份验证设备)。

10.1.1.6.3. 身份验证频道供应商

CIBA 标准文档没有指定如何验证 AD 用户。因此,它可能会自行决定实施。红帽单点登录将该身份验证委派给外部身份验证实体。要与身份验证实体通信,Red Hat Single Sign-On 提供身份验证频道提供程序。

其 Red Hat Single Sign-On 的实施假定身份验证实体由红帽单点登录管理员控制,以便红帽单点登录信任身份验证实体。不建议使用 Red Hat Single Sign-On 管理员无法控制的身份验证实体。

身份验证频道提供程序作为 SPI 供应商提供,以便 Red Hat Single Sign-On 的用户可以实施自己的供应商以满足其环境。Red Hat Single Sign-On 提供其默认供应商 HTTP Authentication Channel Provider,它使用 HTTP 与身份验证实体通信。

如果红帽单点登录用户希望使用 HTTP 身份验证频道提供商,他们需要知道其在红帽单点登录和由以下两部分组成的身份验证实体之间的合同。

身份验证委派请求/响应
红帽单点登录将身份验证请求发送到身份验证实体。
身份验证结果通知/ACK
身份验证实体通知 Red Hat Single Sign-On 的身份验证结果。

身份验证委派请求/响应由以下消息传递组成:

身份验证委派请求
请求从 Red Hat Single Sign-On 发送到身份验证实体,以要求它通过 AD 进行用户身份验证。
POST [delegation_reception]
  • Headers
Name描述

Content-Type

application/json

消息正文为 json 格式。

授权

bearer [token]

当身份验证实体通知 Red Hat Single Sign-On 后,会使用 [token]。

  • 参数
类型Name描述

路径

delegation_reception

身份验证实体提供的端点来接收委派请求

  • Body
Name描述

login_hint

它告知身份验证由 AD 验证的实体。
默认情况下,它是用户的"用户名"。
此字段是必需的,由 CIBA 标准文档定义。

scope

它告知身份验证实体从经过身份验证的用户获得同意的范围。
此字段是必需的,由 CIBA 标准文档定义。

is_consent_required

它显示身份验证实体是否需要获得关于范围经过身份验证的用户的同意。
此字段是必需的。

binding_message

它的值应该在 CD 和 AD 的 UI 中显示,以便用户识别 AD 的身份验证是由 CD 触发的。
这个字段是可选的,由 CIBA 标准文档定义。

acr_values

它告诉从 CD 请求身份验证上下文参考。
这个字段是可选的,由 CIBA 标准文档定义。

身份验证委派响应

响应从身份验证实体返回到 Red Hat Single Sign-On,以通知身份验证实体从 Red Hat Single Sign-On 收到身份验证请求。

  • 响应
HTTP 状态代码描述

201

它通知红帽单点登录以接收身份验证委派请求。

身份验证结果通知/ACK 包括以下消息传递:

身份验证结果通知
身份验证实体将身份验证请求的结果发送到 Red Hat Single Sign-On。
POST /auth/realms/[realm]/protocol/openid-connect/ext/ciba/auth/callback
  • Headers
Name描述

Content-Type

application/json

消息正文为 json 格式。

授权

bearer [token]

[token] 必须是从红帽单点登录请求中接收的身份验证实体的一个身份。

  • 参数
类型Name描述

路径

realm

realm 名称

  • Body
Name描述

status

它告知 AD 进行用户身份验证的结果。
它必须是以下状态之一:
SUCCEED: AD 的身份验证已成功完成。
UNAUTHORIZED: AD 的身份验证尚未完成。
CANCELLED: AD 的身份验证已被用户取消。

身份验证结果 ACK

从 Red Hat Single Sign-On 返回响应到身份验证实体,通知 Red Hat Single Sign-On 接收来自身份验证实体的结果。

  • 响应
HTTP 状态代码描述

200

它通知了接收验证结果通知的身份验证实体。

10.1.1.6.4. 用户解析器供应商

即使同一用户,其表示在每个 CD 中可能有所不同,Red Hat Single Sign-On 和身份验证实体也会不同。

对于 CD,Red Hat Single Sign-On 和身份验证实体可识别同一用户,这个用户解析器提供者会在其中转换自己的用户表示法。

用户 Resolver Provider 作为 SPI 提供程序提供,以便 Red Hat Single Sign-On 的用户可以实施自己的供应商以满足其环境。红帽单点登录提供名为 Default User Resolver Provider 的默认提供程序,它具有以下特征:

  • 仅支持 login_hint 参数,默认使用。
  • Red Hat Single Sign-On 中的 UserModel 用户名用于代表 CD 中的用户、Red Hat Sign-On 和身份验证实体。

10.1.2. OIDC Logout

OIDC 有四个与注销机制相关的规格。这些规格采用草案状态:

由于在 OIDC 规格中描述了所有这些操作,因此我们只在此处给出一个简略概述。

10.1.2.1. 会话管理

这是基于浏览器的注销。该应用定期从 Red Hat Single Sign-On 获取会话状态信息。当会话在 Red Hat Single Sign-On 中终止时,应用程序将注意到并触发它自己的注销。

10.1.2.2. RP-Initiated Logout

这也是一个基于浏览器的注销,从该注销开始,首先将用户重定向到 Red Hat Single Sign-On 的特定端点。当用户点击部分应用程序页面上的 Log Out 链接时,通常使用 Red Hat Single Sign-On 来验证用户时,通常会进行此重定向。

用户重新定向到注销端点后,Red Hat Single Sign-On 将向客户端发送注销请求,以便他们使他们无法使本地用户会话无效,并可能会在注销过程完成后将用户重定向到一些 URL。用户可能会被选择请求,在不使用 id_token_hint 参数时确认注销。注销后,只要它作为参数提供,用户会自动重定向到指定的 post_logout_redirect_uri。请注意,在包含 post_logout_redirect_uri 时,您需要包含 client_idid_token_hint 参数。另外,post_logout_redirect_uri 参数需要匹配客户端 配置中指定的 Valid Post Logout Redirect URI 之一。

根据客户端配置,注销请求可以通过前端频道或通过后端通道发送到客户端。对于 frontend 浏览器客户端(依赖于上一节中所述的 Session Management),Red Hat Single Sign-On 不需要向它们发送任何注销请求;这些客户端会自动检测到浏览器中的 SSO 会话。

10.1.2.3. Frontchannel Logout

要将客户端配置为通过前端通道接收登出请求,请查看 Front-Channel Logout 客户端设置。使用此方法时,请考虑以下事项:

  • 由 Red Hat Single Sign-On 发送至客户端的登出请求依赖于浏览器,内嵌的 iframes 被呈现为登出页。
  • 通过基于 iframes,前端注销可能会受到内容安全策略(CSP)和注销请求的影响。
  • 如果用户在呈现注销页面或注销请求实际发送到客户端之前关闭浏览器,则客户端的会话可能无效。
注意

考虑使用 Back-Channel Logout,因为它提供了一个更加可靠且安全的方法来注销用户并终止其在客户端的会话。

如果没有通过前端注销启用客户端,则红帽单点登录将首先尝试使用 Back-Channel Logout URL 通过 back-Channel Logout URL 发送注销请求。如果没有定义,服务器将回退到使用 Admin URL

10.1.2.4. Backchannel Logout

这是一个非基于浏览器的注销,使用 Red Hat Single Sign-On 和客户端之间的直接后端通信。Red Hat Single Sign-On 发送包含注销令牌的 HTTP POST 请求到登录到 Red Hat Single Sign-On 的所有客户端。这些请求发送到 Red Hat Single Sign-On 中的注册的 backchannel logout URL,并在客户端一侧触发注销。

10.1.3. Red Hat Single Sign-On 服务器 OIDC URI 端点

以下是 Red Hat Single Sign-On 发布的 OIDC 端点列表。当非 Red Hat Single Sign-On 客户端适配器使用这些端点来与身份验证服务器通信时,可以使用这些端点。它们都是相对的 URL。URL 根由 HTTP (S)协议、主机名和可选的路径组成:例如

https://localhost:8080/auth
/realms/{realm-name}/protocol/openid-connect/auth
用于获取授权代码流中的临时代码,或使用 Implicit Flow、Direct Grants 或 Client Grants 获取令牌。
/realms/{realm-name}/protocol/openid-connect/token
授权代码流用于将临时代码转换为令牌。
/realms/{realm-name}/protocol/openid-connect/logout
用于执行注销。
/realms/{realm-name}/protocol/openid-connect/userinfo
用于 OIDC 规格中描述的 User Info 服务。
/realms/{realm-name}/protocol/openid-connect/revoke
用于 OAuth 2.0 令牌吊销( RFC7009 所述)。
/realms/{realm-name}/protocol/openid-connect/certs
用于 JSON Web Key Set (JWKS),包含用于验证任何 JSON Web Token (jwks_uri)的公钥。
/realms/{realm-name}/protocol/openid-connect/auth/device
用于设备授权授权来获取设备代码和用户代码。
/realms/{realm-name}/protocol/openid-connect/ext/ciba/auth
这是 Client Initiated Backchannel Authentication Grant 的 URL 端点,以获取 auth_req_id,用于标识客户端发出的身份验证请求。
/realms/{realm-name}/protocol/openid-connect/logout/backchannel-logout
这是执行后端的 URL 端点,在 OIDC 规格中描述。

在所有这些情况下,将 {realm-name} 替换为域的名称。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.