リクエストの取得での userContext の使用 ACLs による取得動作トラブルシューティング

マネージドナレッジベースでの ACL 対応の取得

マネージドナレッジベースのデータソースで ACL 対応が有効になっている場合、Retrieve リクエストでユーザーコンテキストを渡してクエリ結果をフィルタリングします。Bedrock Managed Knowledge Base は、指定されたユーザーがアクセスできるドキュメントのみを返します。ACL 認識の仕組み、アイデンティティモデル、コネクタのサポート、およびそれを有効にする際の責任の概要については、「」を参照してくださいアクセスコントロールリストの認識の有効化。

重要

ACL 対応は、認可ではなく ACL 対応フィルタリングを提供します。Bedrock Managed Knowledge Base はエンドユーザーを認証しません。アプリケーションはユーザーを認証し、検証済みの ID コンテキストを渡す必要があります。詳細については、「アクセスコントロールリストの認識の有効化」を参照してください。

リクエストの取得での userContext の使用

ACL 対応の取得を実行するには、取得リクエストに userContextフィールドを含めます。はユーザーの ID userContextを指定します。userId は常に、基盤となるデータソースに関連付けられたユーザーのユニバーサル E メールアドレスです。


{
    "knowledgeBaseId": "your-knowledge-base-id",
    "retrievalQuery": {
        "text": "your query"
    },
    "userContext": {
        "userId": "user@example.com"
    }
}

取得リクエストuserContextでを指定しない場合、ACL 対応データソースはゼロの結果を返します。同じナレッジベースの非 ACL データソースは、通常どおり結果を返します。

ACLs による取得動作

ACL 対応を有効にすると、次の動作が適用されます。

ACL 対応データソースに必要なユーザーコンテキスト — 取得リクエストでユーザーコンテキストを指定しない場合、ACL 対応データソースはゼロの結果を返します。同じナレッジベースの非 ACL データソースは、通常どおり結果を返します。
ACL メタデータがないということは、アクセスできないことを意味します — ACL が有効なデータソースのドキュメントに ACL がない場合 (たとえば、コネクタがアクセス許可を抽出できなかったり、ドキュメントが公開されたりした場合）、そのドキュメントはどのユーザーにも返されません。アクセス許可の欠落は、パブリックではなく制限付きとして扱われます。
混合データソース — ACL 対応データソースと非 ACL データソースの両方を同じナレッジベースに持つことができます。ACL 以外のデータソースからのドキュメントは、ユーザーコンテキストに関係なくすべてのユーザーに返されます。
部分的な結果 — リアルタイム ACL 検証が一部のドキュメントへのアクセスを拒否すると、レスポンスに含まれる結果の数が、リクエストされたよりも少なくなる可能性がありますmaxResults。Bedrock マネージドナレッジベースは、追加のドキュメントをバックフィルしません。アプリケーションは、リクエストされたよりも少ない結果でレスポンスを処理する必要があります。
許可の拒否オーバーライド — ドキュメントの許可リストと拒否リストの両方にユーザーが表示された場合、アクセスは拒否されます。

注記

サードパーティー ID プロバイダーの認証情報は、最大 1 時間キャッシュされます。キャッシュが更新されるまで、アクセスが継続される場合があります。

アクセスコントロールのアクセス許可の変更は、結果整合性があります。更新は通常、数分以内に有効になります。

トラブルシューティング

ACL 対応の取得が結果または予期しない結果を返さない場合、通常はコネクタ固有のアクセス許可、認証情報、または ACL 設定が原因です。コネクタのトラブルシューティングガイダンスを参照してください。

ドキュメントの表記規則

マネージドナレッジベースをテストする

ドキュメントコンテンツを取得する