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à.
Autentica gli utenti finali in memoria con OAuth
Il piano dati Amazon Bedrock AgentCore Memory autentica i chiamanti solo con AWS Signature Version 4 (Sigv4). Quando il backend o l'agente chiama Memory per conto di molti utenti, Memory vede solo il ruolo IAM del backend e non può verificare o imporre a quale utente finale sia destinata una determinata richiesta. La separazione dei dati di un utente da quelli di un altro dipende interamente dall'impostazione corretta del codice dell'applicazione actorId e dallo spazio dei nomi su ogni richiesta; nulla a livello di memoria impedisce a una richiesta che gestisce l'utente A di leggere i dati dell'utente B.
Mettendo in primo piano la memoria con un AgentCore gateway configurato per l'autenticazione in ingresso OAuth (CUSTOM_JWT), si aggiunge il supporto OAuth che Memory non dispone da solo. Il chiamante presenta la richiesta al JWT dell'utente finale, il gateway la convalida e le politiche di controllo degli accessi impongono l'isolamento in base alle dichiarazioni del token, a livello di infrastruttura, indipendentemente dalla logica dell'applicazione. Il gateway chiama quindi Memory nell'ambito del suo ruolo di esecuzione del gateway, fungendo da ponte tra il OAuth-authenticated chiamante e il piano dati di Memory. IAM-authenticated
Nota
Questa pagina si basa sul connettore AgentCore Memory. Configura prima un gateway con una destinazione per il connettore di memoria. Per ulteriori informazioni, vedere Accedere alla AgentCore memoria tramite un gateway.
In che modo il gateway collega OAuth alla memoria
Quando un gateway utilizza l'autenticazione in CUSTOM_JWT entrata davanti a una destinazione del connettore di memoria:
-
Il chiamante invia una richiesta al gateway con un token al portatore JWT emesso dal provider OpenID Connect. A seconda dell'applicazione, il token può rappresentare un utente finale o l'agente stesso e può contenere informazioni sull'utente finale nei suoi claim.
-
Il gateway convalida il token rispetto al provider configurato e le dichiarazioni del token (ad esempio
subeclient_id) diventano disponibili per le politiche di controllo degli accessi del gateway come tag principali. -
Se una policy consente la richiesta, il gateway la inoltra al piano dati di memoria nell'ambito del suo ruolo di esecuzione del gateway (la modalità credenziali in
GATEWAY_IAM_ROLEuscita).
Suggerimento
In una tipica architettura di chatbot o agenti, l'utente finale non chiama direttamente Memory. L'agente o il servizio di backend è il chiamante HTTP e trasmette il JWT dell'utente finale insieme a ogni richiesta di memoria: il token «accompagna» la richiesta. Il gateway autentica quel token e valuta le politiche rispetto alle relative dichiarazioni, in modo che l'accesso venga applicato all'utente finale rappresentato dal token, anche se l'agente è l'entità che effettua la chiamata.
Ecco perché è importante un controllo granulare degli accessi: con esso, è possibile garantire che una richiesta raggiunga solo i dati di memoria che appartengono all'utente finale autenticato contenuti nel token, anziché affidarsi all'agente per impostare il namespace corretto. actorId
Con un'applicazione agente, gli utenti finali possono accedere tramite un provider di identità OAuth standard, ad esempio Amazon Cognito o qualsiasi provider OpenID Connect, e puoi imporre l'isolamento della memoria per utente in base all'identità dell'utente finale autenticato. L'applicazione non distribuisce AWS le credenziali agli utenti finali e la memoria non deve comprendere OAuth in modo nativo.
La configurazione dell'CUSTOM_JWTautorizzatore (l'URL di scoperta di OpenID Connect, il pubblico e i client consentiti e gli ambiti) è un'attività standard di autorizzazione in entrata del gateway e non è specifica per Memory. Per la configurazione dell'autorizzatore, vedi Creare un gateway. AgentCore Per sapere in che modo le dichiarazioni JWT si associano al AgentCore::OAuthUser principale e ai suoi tag, vedi Concetti principali.
Nota
OAuth (CUSTOM_JWT) in entrata è compatibile solo con la modalità credenziali in uscita. GATEWAY_IAM_ROLE La CALLER_IAM_CREDENTIALS modalità inoltra l'identità IAM del chiamante, che non esiste per un JWT-authenticated chiamante, quindi viene rifiutata al momento della creazione del target. Per la matrice di compatibilità completa, vedi Modalità di autenticazione in entrata e in uscita.
Imponi l'accesso alla memoria per utente
L'autenticazione dei chiamanti con OAuth è ciò che rende possibile l'autorizzazione basata sull'identità, ma l'autenticazione da sola non limita ciò che un chiamante può fare. Qualsiasi richiesta con un token valido può comunque raggiungere ogni attore, sessione e spazio dei nomi nella risorsa Memory. Per garantire che ogni richiesta possa accedere solo ai dati di memoria appartenenti all'utente finale autenticato, la cui identità è contenuta nel JWT, aggiungi politiche di controllo degli accessi con un controllo degli accessi granulare. Per informazioni su come scrivere tali politiche, consulta il controllo degli accessi per la memoria. Fine-grained
