CLI AWS を使用して同意ポータルを作成する

同意ポータルを作成するポータル URL のポーリング同意ポータルの設定を完了する

create-consent-portal コマンドを使用して同意ポータルを作成します。ポータルを作成したら、を取得するまでそのステータスACTIVEをポーリングしますportalUrl。開始する前に、「同意ポータルの前提条件」のステップを完了してください。代わりにコンソールを使用して同意ポータルを作成するには、「コンソールを使用して同意ポータルを作成する」を参照してください。

create-consent-portal コマンドには、次のパラメータが必要です。

executionRoleArn – 同意ポータルが引き受ける IAM ロールの ARN。
idpConfig – ID プロバイダーの設定。これには、必須 credentialProviderArn (JWT 発行 OIDC ID プロバイダー用に以前に作成した OAuth2 認証情報プロバイダーの ARN) と、オプション scopesおよびが含まれますaudience。
name – 同意ポータルの名前 (1～50 文字）。
sources – タイプのソースの 1 つですagentcore-gateway。

オプションの description、tags、および clientTokenパラメータを指定することもできます。

注記

idpConfig.credentialProviderArn 値は、を呼び出す前に作成した OAuth2 認証情報プロバイダーの ARN である必要がありますcreate-consent-portal。JWT 発行 OIDC ID プロバイダーの OAuth2 認証情報プロバイダーを最初に作成し、ここで ARN を渡します。詳細については、「同意ポータルの前提条件」およびAgentCore Identity で認証情報プロバイダーを管理する」を参照してください。

注記

同意ポータルは常に、で設定したopenidスコープに加えてスコープをリクエストしますidpConfig.scopes。設定されたすべてのスコープとを IdP で定義して許可openidする必要があります。そうしないと、認可がinvalid_scopeエラーで失敗します。scopes リストopenidにを含めます。

次のコマンドは、同意ポータルを作成します。強調表示された値を独自の値に置き換えます。


aws bedrock-agentcore-control create-consent-portal \
    --name "my-consent-portal" \
    --execution-role-arn "arn:aws:iam::<account-id>:role/<execution-role-name>" \
    --idp-config '{
        "credentialProviderArn": "arn:aws:bedrock-agentcore:<region>:<account-id>:token-vault/default/oauth2credentialprovider/<credential-provider-id>",
        "scopes": ["openid", "email", "profile"],
        "audience": "<audience>"
    }' \
    --sources '[{
        "identifier": "<gateway-id>",
        "type": "agentcore-gateway"
    }]'

レスポンスにはconsentPortalId、、consentPortalArn、ポータルが含まれますstatus。ポータルが CREATINGステータスの間は、フィールドportalUrlと statusReasonフィールドが null になる場合があります。

同意ポータルを作成すると、 CREATINGステータスで開始されます。を使用してget-consent-portal、ポータルのステータスがになるまでポータルをポーリングします。この時点でACTIVE、 portalUrl が使用可能になります。同意ポータル ID または完全な ARN をとして渡すことができます--consent-portal-identifier。

次のコマンドは、同意ポータルを取得します。<consent-portal-id> を自分の値に置き換えます。


aws bedrock-agentcore-control get-consent-portal \
    --consent-portal-identifier "<consent-portal-id>"

返された statusがになったらACTIVE、レスポンスportalUrlからを取得し、「同意ポータルのセットアップを完了する」のセットアップステップを完了します。ステータスがの場合はFAILED、 statusReasonフィールドを調べて問題を診断します。

ポータルが ACTIVEになり、を取得したらportalUrl、次の手順を実行して、エンドユーザーがポータルにサインインできるようにします。これらのステップでは、プライマリ IdP を設定します。これはidpConfig、ユーザーがサインインする ID であるで渡した認証情報プロバイダーです。ユーザーがエージェントにアクセスの同意を付与できるリソースを追加するには、「同意ポータルのターゲットを設定する」を参照してください。

プライマリ IdP にポータルコールバック URL を登録します。で渡した認証情報プロバイダーをバックアップする IdP アプリケーションでidpConfig、承認されたリダイレクト (コールバック) URI <portalUrl>/callbackとしてを追加します。末尾にスラッシュなしで正確に値を入力します。末尾にスラッシュがあると、IdP は認証中にコールバックを登録解除として拒否します。この設定のラベル付けは IdPs ごとに異なります。例えば、Amazon Cognito はこれを許可コールバック URLsと呼び出し、Okta はそれをサインインリダイレクト URIs。
アクティブな IdP ユーザーが存在することを確認します。プライマリ IdP にサインインできるアクティブなユーザーが少なくとも 1 人いることを確認します。一部の IdPs では、ユーザーをアプリケーションに割り当てる必要があります。例えば、Okta では、ユーザーはアプリケーションの割り当てに基づいて割り当てる必要があります。
ポータルにサインインします。ブラウザportalUrlでを開き、既存の IdP ユーザーの認証情報でサインインします。サインインに成功すると、同意ポータルページに移動し、プライマリ IdP、認証情報プロバイダー、ポータルコールバック URL が正しく設定されていることを確認します。

ポータルのゲートウェイにターゲットが設定されていない場合、同意を付与するリソースがないため、同意ポータルページは空で表示されます。ページに接続が表示されるようにターゲットを追加するには、「同意ポータルのターゲットを設定する」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

コンソールを使用してを作成する

同意ポータルターゲットを設定する