View a markdown version of this page

エンドユーザーを OAuth でメモリに認証する - Amazon Bedrock AgentCore
ゲートウェイが OAuth をメモリにブリッジする方法メモリへのユーザーごとのアクセスを強制する

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

エンドユーザーを OAuth でメモリに認証する

Amazon Bedrock AgentCore Memory データプレーンは、 AWS 署名バージョン 4 (SigV4) でのみ発信者を認証します。バックエンドまたはエージェントが多くのユーザーに代わって Memory を呼び出すと、Memory はバックエンドの IAM ロールのみを表示します。特定のリクエストの対象となるエンドユーザーを検証または強制することはできません。あるユーザーのデータを別のユーザーのデータと分離することは、アプリケーションコードが各リクエストで正しい名前空間actorIdと名前空間を設定することに完全に依存します。メモリレイヤーに何もないと、ユーザー A を処理するリクエストがユーザー B のデータを読み取りできなくなります。

OAuth (CUSTOM_JWT) インバウンド認証用に設定された AgentCore Gateway で Memory をフロンティングすることで、Memory 自体にはない OAuth サポートを追加します。呼び出し元は、リクエストをエンドユーザーの JWT に提示し、ゲートウェイはそれを検証します。アクセスコントロールポリシーは、アプリケーションロジックとは無関係に、インフラストラクチャレイヤーで、トークンのクレームに基づいて分離を適用します。次に、ゲートウェイはゲートウェイ実行ロールで Memory を呼び出し、OAuth 認証発信者と Memory の IAM 認証データプレーン間のブリッジとして機能します。

注記

このページは AgentCore Memory コネクタ上に構築されています。最初にメモリコネクタターゲットを使用してゲートウェイを設定します。詳細については、「ゲートウェイ経由で AgentCore メモリにアクセスする」を参照してください。

ゲートウェイが OAuth をメモリにブリッジする方法

ゲートウェイがメモリコネクタターゲットの前でCUSTOM_JWTインバウンド認証を使用する場合:

  1. 発信者は、OpenID Connect プロバイダーによって発行された JWT ベアラートークンを使用してゲートウェイにリクエストを送信します。アプリケーションに応じて、トークンはエンドユーザーまたはエージェント自体を表し、そのクレームでエンドユーザー情報を伝達できます。

  2. ゲートウェイは、設定したプロバイダーに対してトークンを検証し、トークンのクレーム ( subや などclient_id) がゲートウェイのアクセスコントロールポリシーでプリンシパルタグとして使用可能になります。

  3. ポリシーでリクエストが許可されている場合、ゲートウェイはそれをゲートウェイ実行ロール (GATEWAY_IAM_ROLEアウトバウンド認証情報モード) のメモリデータプレーンに転送します。

ヒント

一般的なチャットボットまたはエージェントアーキテクチャでは、エンドユーザーはメモリを直接呼び出しません。エージェントまたはバックエンドサービスは HTTP 発信者であり、エンドユーザーの JWT を各メモリリクエストとともに渡します。トークンはリクエストを「 で移動します」。ゲートウェイはそのトークンを認証し、そのクレームに対してポリシーを評価するため、エージェントが呼び出しを行うエンティティであっても、トークンが表すエンドユーザーにアクセスが適用されます。

そのため、きめ細かなアクセスコントロールが重要です。これにより、エージェントを信頼して正しいactorId名前空間自体を設定するのではなく、トークンで伝送された認証されたエンドユーザーに属するメモリデータのみにリクエストを確実に到達させることができます。

エージェントアプリケーションを使用すると、エンドユーザーは Amazon Cognito や OpenID Connect プロバイダーなどの標準の OAuth ID プロバイダーを介してサインインでき、認証されたエンドユーザーの ID に基づいてユーザーごとのメモリ分離を適用できます。アプリケーションは AWS 認証情報をエンドユーザーに配布せず、Memory は OAuth をネイティブに理解する必要はありません。

CUSTOM_JWT オーソライザー (OpenID Connect 検出 URL、許可された対象者とクライアント、スコープ) の設定は、標準のゲートウェイインバウンド認可タスクであり、メモリに固有ではありません。オーソライザーの設定については、AgentCore ゲートウェイの作成」を参照してください。JWT クレームがAgentCore::OAuthUserプリンシパルとそのタグにどのようにマッピングされるかについては、「 Core concepts」を参照してください。

注記

OAuth (CUSTOM_JWT) インバウンドは、GATEWAY_IAM_ROLEアウトバウンド認証情報モードとのみ互換性があります。CALLER_IAM_CREDENTIALS モードは、JWT で認証された発信者には存在しない発信者の IAM ID を転送するため、ターゲットの作成時に拒否されます。完全な互換性マトリックスについては、「インバウンド認証モードとアウトバウンド認証モード」を参照してください。

メモリへのユーザーごとのアクセスを強制する

OAuth を使用して発信者を認証することは、アイデンティティベースの認可を可能にするものですが、認証だけでは発信者ができることを制限しません。有効なトークンを持つリクエストは、メモリリソース内のすべてのアクター、セッション、名前空間に到達できます。各リクエストが、ID が JWT で伝送される認証されたエンドユーザーに属するメモリデータにのみアクセスできるようにするには、きめ細かなアクセスコントロールを持つアクセスコントロールポリシーを追加します。これらのポリシーの記述方法については、「メモリのきめ細かなアクセスコントロール」を参照してください。