2.2. OAuth 2.0 認証設定オプションの拡張

新しい設定オプションによって、より多くの承認サーバーとの統合が可能になりました。

OAuth 2.0 認証の適用方法や、承認サーバーのタイプによっては、追加 (任意) の設定を使用できます。

Kafka ブローカーの追加設定オプション

listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  # ...
  oauth.check.issuer=false \


  oauth.fallback.username.claim="CLIENT-ID" \


  oauth.fallback.username.prefix="CLIENT-ACCOUNT" \


  oauth.valid.token.type="bearer" \


  oauth.userinfo.endpoint.uri="https:://AUTH-SERVER-ADDRESS/userinfo" ;

1: 承認サーバーが iss クレームを提供しない場合は、発行者チェックを行うことができません。このような場合、oauth.check.issuer を false に設定し、oauth.valid.issuer.uri を指定しないようにします。デフォルトは true です。
2: 承認サーバーは、通常ユーザーとクライアントの両方を識別する単一の属性を提供しない場合があります。独自の名前を認証するクライアントによって クライアント ID が提供される場合があります。しかし、更新トークンまたはアクセストークンの取得に、ユーザー名とパスワードを使用して認証されるユーザーは、クライアント ID の他に ユーザー名 を提供する場合があります。プライマリーユーザー ID 属性が使用できない場合は、このフォールバックオプションで、使用するユーザー名クレーム (属性) を指定します。
3: oauth.fallback.username.claim が適用される場合、ユーザー名クレームの値とフォールバックユーザー名クレームの値が競合しないようにする必要もあることがあります。producer というクライアントが存在し、producer という通常ユーザーも存在する場合について考えてみましょう。この 2 つを区別するには、このプロパティーを使用してクライアントのユーザー ID に接頭辞を追加します。
4: (イントロスペクションエンドポイント URI を使用する場合のみ該当): 使用している認証サーバーによっては、イントロスペクションエンドポイントによってトークンタイプ属性が返されるかどうかは分からず、異なる値が含まれることがあります。イントロスペクションエンドポイントからの応答に含まれなければならない有効なトークンタイプ値を指定できます。
5: (イントロスペクションエンドポイント URI を使用する場合のみ該当): イントロスペクションエンドポイントの応答に識別可能な情報が含まれないように、承認サーバーが設定または実装されることがあります。ユーザー ID を取得するには、userinfo エンドポイントの URI をフォールバックとして設定します。oauth.fallback.username.claim、oauth.fallback.username.claim、および oauth.fallback.username.prefix 設定が userinfo エンドポイントの応答に適用されます。

Kafka コンポーネントの追加設定オプション

# ...
System.setProperty(ClientConfig.OAUTH_SCOPE, "SCOPE-VALUE")

1: (オプション): トークンエンドポイントからトークンを要求するための scope。認証サーバーでは、クライアントによるスコープの指定が必要になることがあります。

Kafka ブローカーの OAuth 2.0 サポートの設定および OAuth 2.0 を使用するための Kafka Java クライアントの設定を参照してください。

2.2. OAuth 2.0 認証設定オプションの拡張

詳細情報

試用、購入および販売

コミュニティー

会社概要

多様性を受け入れるオープンソースの強化

Red Hat ドキュメントについて

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links