第 12 章 管理 OpenID Connect 和 SAML 客户端

为了保护使用 OpenID 连接协议的应用程序，您可以创建一个客户端。

此操作会创建客户端，并将您带到 Settings 选项卡。

当您创建 OIDC 客户端时，您可以在 Settings 标签页中看到以下字段。

徽标 URL

引用客户端应用程序徽标的 URL。

策略 URL

Relying 客户端向 End-User 提供相关 URL 来阅读如何使用配置集数据。

服务 URL 条款

重复客户端为最终用户提供的 URL，可阅读有关相应服务条款的 URL。

当您点 Advanced Settings 时，会显示其他字段。

OAuth 2.0 Mutual TLS Certificate Bound Access Tokens Enabled

Mutual TLS 将访问令牌和刷新令牌与客户端证书绑定，后者在 TLS 握手期间交换。这个绑定可防止攻击者使用 stolen 令牌。

这种类型的令牌是持有密钥令牌的拥有者。与 bearer 令牌不同的是，持有者令牌的接收者是否可以验证令牌的发件人是否合法。

如果这个设置位于，则工作流为：

如果验证失败，红帽单点登录会拒绝令牌。

在以下情形中，Red Hat Single Sign-On 将验证客户端发送访问令牌或刷新令牌：

如需了解更多详细信息，请参阅 OAuth 2.0 Mutual TLS 客户端身份验证和证书 Bound Access Tokens 中的 Mutual TLS Client Certificate Bound Access Tokens。

OIDC 的高级配置

OpenID Connect 的 Advanced Settings 允许您在客户端级别上配置 会话和令牌超时的覆盖。

代码交换代码挑战方法验证密钥

如果攻击者破坏合法客户端的授权代码，则代码交换的概念验证密钥(PKCE)可防止攻击者获得应用到代码的令牌。

管理员可以选择以下选项之一：

如需了解更多详细信息，请参阅 OAuth 公共客户端代码交换的 RFC 7636 证明密钥。

已签名和加密 ID 令牌支持

红帽单点登录可以根据 Json Web 加密(JWE)规范加密 ID 令牌。管理员决定是否为每个客户端配置了 ID 令牌。

用于加密 ID 令牌的密钥是内容加密密钥(CEK)。Red Hat Single Sign-On 和客户端必须协商使用 CEK 以及它的交付方式。用于确定 CEK 的方法是密钥管理模式。Red Hat Single Sign-On 支持的密钥管理模式是密钥加密。

在密钥加密中：

除客户端外，没有方可以解密 ID 令牌。

客户端必须将其公钥用于加密 CEK 到 Red Hat Single Sign-On。Red Hat Single Sign-On 支持从客户端提供的 URL 下载公钥。客户端必须根据 Json Web Keys (JWK) 规范提供公钥。

此过程是：

密钥加密算法在 Json Web Algorithm (JWA) 规范中定义。Red Hat Single Sign-On 支持：

选择算法的步骤是：

ACR 到身份验证级别(LoA)映射

在客户端的高级设置中，您可以定义哪个 身份验证上下文类参考(ACR) 值映射到哪些 级别的身份验证(LoA )。此映射也可以在 ACR 到 LoA Mapping 所述的域中指定。最佳实践是在 realm 级别配置此映射，它允许在多个客户端间共享相同的设置。

Default ACR Values 可用于指定在从此客户端发送到 Red Hat Single Sign-On 时的默认值，而无需 acr_values 参数，且没有附加了 acr claim 的声明参数。请参阅 不使用 OIDC 动态客户端注册规格。

详情请查看 Step-up Authentication 和 the offical OIDC specification。

如果客户端的 访问类型设为 机密，必须在 Credentials 选项卡下配置客户端的凭据。

Client Authenticator 下拉列表指定要用于客户端的凭证类型。

客户端 ID 和机密

这个选择是默认设置。为您自动生成 secret，点 Regenerate Secret 会根据需要重新创建 secret。

签名的 JWT "Signed Json Web 令牌"。

在选择此凭证类型时，您还需要在标签 键中为客户端生成私钥和证书 。私钥将用于为 JWT 签名，而证书则供服务器用于验证签名。

点击 Generate new key and certificate 按钮启动此过程。

生成密钥时，Red Hat Single Sign-On 将存储证书并下载您的客户端的私钥和证书。

您还可以使用外部工具生成密钥，然后点 Import Certificate 导入客户端证书。

如果点击 Use JWKS URL，则不需要导入证书。在这种情况下，您可以提供以 JWK 格式发布公钥的 URL。使用此选项时，如果密钥被改变，Red Hat Single Sign-On 会重新导入密钥。

如果您使用由 Red Hat Single Sign-On 适配器保护的客户端，您可以使用以下格式配置 JWKS URL，假设 https://myhost.com/myapp 是客户端应用程序的根 URL：

https://myhost.com/myapp/k_jwks

如需了解更多详细信息，请参阅 服务器开发人员指南。

使用客户端 Secret 签名 JWT

如果选择此选项，您可以使用由客户端 secret 签名的 JWT，而不使用私钥。

客户端机密将用于由客户端为 JWT 签名。

X509 证书

Red Hat Single Sign-On 在 TLS Handshake 中验证客户端是否使用正确的 X509 证书。

验证器还使用配置的 regexp 验证表达式检查证书的 Subject DN 字段。对于某些用例，就可以接受所有证书。在这种情况下，您可以使用 (.*?) (?:$) 表达式。

Red Hat Single Sign-On 有两种方法以从请求获取客户端 ID：

对于具有 机密 访问类型的客户端，红帽单点登录支持通过客户端 策略 轮转客户端 secret 的功能。???

客户端 secret 轮转策略提供了更大的安全性，以缓解 secret 泄漏等问题。启用后，Red Hat Single Sign-On 支持每个客户端最多两个并发活跃 secret。策略会根据以下设置管理轮转：

当出现客户端 secret 轮转时，会生成新的主 secret，而旧客户端主 secret 就会使用新的过期日期成为二级 secret。

以下是定义 secret 轮转策略的示例：

每个 OIDC 客户端都有一个内置 服务帐户。使用 此服务帐户 获取访问令牌。

访问令牌的角色是以下的交集：

要调用的 REST URL 是 /auth/realms/{realm-name}/protocol/openid-connect/token。这个 URL 必须以 POST 请求形式调用，并要求您使用请求发布客户端凭证。

默认情况下，客户端凭证由 Authorization: Basic 标头中的客户端的 clientId 和 clientSecret 表示，但您也可以使用签名的 JWT 断言或客户端身份验证的其他自定义机制验证客户端。

您还需要根据 OAuth2 规格将 grant_type 参数设置为 "client_credentials"。

例如，POST 调用以检索服务帐户，如下所示：

    POST /auth/realms/demo/protocol/openid-connect/token
    Authorization: Basic cHJvZHVjdC1zYS1jbGllbnQ6cGFzc3dvcmQ=
    Content-Type: application/x-www-form-urlencoded

    grant_type=client_credentials

从 OAuth 2.0 规范中，响应与此 Access Token 响应 类似。

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":60
}

默认情况下，仅返回访问令牌。默认情况下，不会返回刷新令牌，在 Red Hat Single Sign-On side 上不创建用户会话。由于缺少刷新令牌，在访问令牌过期时需要重新身份验证。但是，这种情形并不意味着红帽单点登录服务器的额外开销，因为默认不会创建会话。

在这种情况下，注销是不必要的。但是，通过将请求发送到 OAuth2 Revocation Endpoints 部分所述，可以撤销颁发的访问令牌。

通常，部署红帽单点登录的环境由一组使用 Red Hat Single Sign-On 进行身份验证的 保密 或 公共客户端 应用程序组成。

服务 ( OAuth 2 规范中的资源服务器 )还可以为来自客户端应用程序的请求提供服务，并为这些应用程序提供资源。这些服务需要向它们发送访问令牌(Bearer 令牌)来验证请求。此令牌在登录 Red Hat Single Sign-On 后由 frontend 应用获取。

在服务间信任较低的环境中，您可能会遇到这种情况：

这种情境在服务间有高信任但并不是信任较低的环境的环境中不太可能出现。在某些环境中，这个工作流可能正确，因为不受信任的服务可能需要从可信服务检索数据，以将数据返回到原始客户端应用。

在服务之间存在高度信任时，一个无限制的受众很有用。否则，受众应限制。您可以限制使用者和同时，允许不受信任的服务从可信服务检索数据。在这种情况下，请确保将不受信任的服务和可信服务添加为令牌的受众。

为防止访问令牌的任何滥用，请限制令牌上的使用者，并配置您的服务来验证令牌上的使用者。流会按如下方式改变：

如果客户端想要稍后调用可信服务，它必须通过使用 范围 =<受信任的服务>重新运行 SSO 登录来获取另一个令牌。然后，返回的令牌会将可信服务作为受众包含在内：

"audience": [ "<trusted service>" ]

使用这个值调用 < trusted service>。