搜索

4.4. 使用基于 OAuth 2.0 令牌的身份验证

download PDF

AMQ Streams 支持使用 SASL OAUTHBEARER 机制进行 OAuth 2.0 身份验证。

OAuth 2.0 支持应用之间基于令牌的标准化身份验证和授权,使用中央授权服务器发布对资源的有限访问权限的令牌。

您可以配置 OAuth 2.0 身份验证,然后配置 OAuth 2.0 授权

OAuth 2.0 身份验证也可与 简单 或基于 OPA 的 Kafka 授权 一起使用。

通过使用基于 OAuth 2.0 令牌的身份验证,应用客户端可以访问应用服务器(称为 资源服务器)上的资源,而无需公开帐户凭据。

应用客户端通过访问令牌来进行身份验证,应用服务器也可以使用该令牌来确定要授予的访问权限级别。授权服务器处理关于访问权限的访问和咨询。

在 AMQ Streams 中:

  • Kafka 代理充当 OAuth 2.0 资源服务器
  • Kafka 客户端充当 OAuth 2.0 应用程序客户端

Kafka 客户端向 Kafka 代理进行身份验证。代理和客户端根据需要与 OAuth 2.0 授权服务器通信,以获取或验证访问令牌。

对于 AMQ Streams 的部署,OAuth 2.0 集成提供:

  • 对 Kafka 代理的服务器端 OAuth 2.0 支持
  • 客户端 OAuth 2.0 支持 Kafka MirrorMaker、Kafka Connect 和 Kafka Bridge

其它资源

4.4.1. OAuth 2.0 身份验证机制

AMQ Streams 支持 OAUTHBEARER 和 PLAIN 机制进行 OAuth 2.0 身份验证。这两种机制都允许 Kafka 客户端通过 Kafka 代理建立经过身份验证的会话。客户端、授权服务器和 Kafka 代理之间的身份验证流程因每种机制而异。

建议您将客户端配置为尽可能使用 OAUTHBEARER。OAUTHBEARER 提供比 PLAIN 更高的安全级别,因为客户端凭证 永远不会 与 Kafka 代理共享。只考虑在不支持 OAUTHBEARER 的 Kafka 客户端中使用 PLAIN。

如果需要,可以在同一个 oauth 侦听器上同时启用 OAUTHBEARER 和 PLAIN。

OAUTHBEARER 概述

Kafka 支持 OAUTHBEARER 身份验证机制,但必须明确配置它。另外,很多 Kafka 客户端工具在协议级别使用为 OAUTHBEARER 提供基本支持的库。

为简化应用程序开发,AMQ Streams 为上游 Kafka 客户端 Java 库(但不为其他库)提供 OAuth 回调处理程序。因此,您不需要为此类客户端自行编写回调处理程序。应用客户端可以使用回调处理程序来提供访问令牌。以其他语言编写的客户端(如 Go)必须使用自定义代码连接到授权服务器并获取访问令牌。

使用 OAUTHBEARER 时,客户端会启动与 Kafka 代理的会话进行凭证交换,其中凭证采用回调处理程序提供的 bearer 令牌的形式。通过使用回调,您可以通过以下三种方法之一配置令牌置备:

  • 客户端 ID 和 Secret(使用 OAuth 2.0 客户端凭证机制)
  • 长期访问令牌,在配置时手动获得
  • 长期存在的刷新令牌,在配置时手动获取

OAUTHBEARER 在 Kafka 代理的 oauth 监听程序配置中自动启用。您可以将 enableOauthBearer 属性设置为 true,但这不是强制要求。

  # ...
  authentication:
    type: oauth
    # ...
    enableOauthBearer: true
注意

OAUTHBEARER 身份验证只能由支持协议级别的 OAUTHBEARER 机制的 Kafka 客户端使用。

PLAIN 概述

PLAIN 是供所有 Kafka 客户端工具(包括 kafkacat 等开发人员工具)使用的简单身份验证机制。为了启用 PLAIN 与 OAuth 2.0 身份验证一同使用,AMQ Streams 包含服务器端回调,并通过 PLAIN 调用这个 OAuth 2.0

随着 PLAIN 的 AMQ Streams 实施,客户端凭据不会存储在 ZooKeeper 中。相反,客户端凭证在兼容授权服务器后面集中处理,这与使用 OAUTHBEARER 身份验证时类似。

当与 OAuth 2.0 over PLAIN 回调搭配使用时,Kafka 客户端使用以下方法之一向 Kafka 代理进行身份验证:

  • 客户端 ID 和 secret(使用 OAuth 2.0 客户端凭证机制)
  • 长期访问令牌,在配置时手动获得

客户端必须启用才能使用 PLAIN 身份验证,并提供 用户名和密码 。如果密码的前缀为 $accessToken:,后跟访问令牌的值,Kafka 代理会将密码解析为访问令牌。否则,Kafka 代理会将 用户名 解释为客户端 ID,密码 将解释为客户端 secret。

如果将 密码 设置为访问令牌,用户名 必须设置为 Kafka 代理从访问令牌获取的相同主体名称。这个过程取决于您如何使用 userNameClaim、fallbackUserNameClaimfallbackUser namePrefixuserInfoEndpointUri 配置用户名提取。它还取决于您的授权服务器;特别是,如何将客户端 ID 映射到帐户名称。

要使用 PLAIN,您必须在 Kafka 代理的 oauth 监听程序配置中启用它。

在以下示例中,除了默认启用的 OAUTHBEARER 外,还启用了 PLAIN。如果只使用 PLAIN,可以通过将 enableOauthBearer 设置为 false 来禁用 OAUTHB EARER。

  # ...
  authentication:
    type: oauth
    # ...
    enablePlain: true
    tokenEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/token
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.