Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Prerequisiti del portale di consenso
Prima di creare un portale per il consenso, create il provider di credenziali OAuth2 di cui inserite l'ARNidpConfig.credentialProviderArn, configurate il gateway utilizzato dal portale e create il ruolo di esecuzione che il portale assume. Questo argomento descrive ogni prerequisito.
Provider di credenziali OAuth2
Un portale di consenso richiede un provider di credenziali OAuth2 per il tuo provider di identità OIDC. JWT-issuing Questo è l'IdP principale a cui accedono gli utenti finali; è separato da qualsiasi provider di credenziali in uscita (per destinazione) che l'agente utilizza per agire su una risorsa. È necessario creare questo provider di credenziali OAuth2 prima di creare il portale e fornire il relativo ARN come quando si chiama. idpConfig.credentialProviderArn create-consent-portal Il provider di credenziali OAuth2 deve fare riferimento allo stesso emittente OIDC dell'autorizzatore JWT del gateway e gli ambiti consentiti nell'applicazione IdP che lo supporta devono includere. openid Per ulteriori informazioni sulla creazione di un provider di credenziali OAuth2, consulta Gestire i provider di credenziali con Identity. AgentCore
Quando crei l'applicazione IdP che supporta questo provider di credenziali, utilizza un'applicazione web OIDC che utilizza la concessione del codice di autorizzazione e ha un segreto client. Non impostate ancora un vero URI di reindirizzamento: l'URL di callback del portale esiste solo dopo la creazione del portale. Lascia vuoto l'elenco degli URI di reindirizzamento o imposta un valore segnaposto e crea anche almeno un utente di prova attivo con cui puoi accedere. Si registra il vero URI di reindirizzamento e si completa l'accesso dopo l'accesso al portaleACTIVE, come descritto in Creare un portale di consenso con la CLI. AWS
Il portale di consenso supporta solo i principali IdPs che emettono token di accesso JWT. OAuth2-only i fornitori che non emettono token ID e non pubblicano alcun documento di rilevamento OIDC (ad esempio, Slack GitHub, Salesforce, Atlassian e LinkedIn) non possono essere utilizzati come IdP primario, sebbene rimangano validi come provider in uscita per i gateway target.
Gateway con autenticazione in entrata JWT
Un portale di consenso si collega esattamente a un Amazon Bedrock AgentCore Gateway come unica fonte di tipo. agentcore-gateway Il gateway deve essere configurato con un tipo di autenticazione in entrata di JWT in modo che l'autorizzatore faccia riferimento a un provider di identità OIDC. Quando si crea il portale di consenso, AWS convalida che l'autorizzatore del gateway e il provider di credenziali OAuth2 forniti facciano riferimento allo stesso emittente OIDC. idpConfig Per ulteriori informazioni sulla configurazione dei provider di credenziali e dei provider di identità, vedi Gestire i provider di credenziali con l'impostazione e la configurazione di Identity and Provider. AgentCore Configurazione e configurazione del provider
Il portale di consenso supporta solo i token di accesso IdPs JWT di emissione. IdPs i token di accesso opachi che emettono token di accesso e OAuth2-only fornitori non sono supportati come IdP principale per un portale di consenso.
Il gateway deve esistere prima di creare il portale di consenso, ma non è ancora necessario aggiungere i relativi obiettivi di autenticazione in uscita. Le destinazioni determinano ciò che appare nella pagina Connessioni del portale e l'URL di ritorno dipende da quello del portaleportalUrl, che esiste solo quando il portale non lo è. ACTIVE Aggiungi gli obiettivi come fase successiva alla creazione, descritta in Creare un portale di consenso con la AWS CLI.
Ruolo di esecuzione
Un portale di consenso assume un ruolo IAM che trasmetti executionRoleArn quando crei il portale. Il servizio Consent Portal assume questo ruolo per leggere le configurazioni del gateway e del provider di credenziali OAuth2 e per recuperare il segreto del client OAuth. Il ruolo richiede una politica di fiducia e una politica di autorizzazioni specifiche. Per le politiche e le istruzioni richieste, vedi Ruolo di esecuzione del portale di consenso.