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à.
Schemi di autenticazione supportati
AgentCore Identity supporta due modelli di autenticazione principali che risolvono diversi casi d'uso degli agenti. La comprensione di questi modelli ti aiuterà a scegliere l'approccio giusto per l'implementazione del tuo agente specifico.
Per esempi dettagliati di come questi modelli si applicano a settori e tipi di agenti specifici, vedi Esempi di casi d'uso.
Argomenti
User-delegated accesso (concessione del codice di autorizzazione OAuth 2.0)
Il flusso di concessione del codice di autorizzazione OAuth 2.0 consente agli agenti di accedere ai dati specifici dell'utente con il consenso esplicito dell'utente. Questo modello è essenziale quando gli agenti devono accedere ai dati personali o eseguire azioni per conto di utenti specifici. Il flusso include una fase di consenso dell'utente in cui il proprietario della risorsa (utente) autorizza esplicitamente l'agente ad accedere ai propri dati entro ambiti specifici.
Caratteristiche chiave
-
Richiede il consenso esplicito dell'utente tramite una richiesta di autorizzazione
-
Fornisce l'accesso a dati e risorse specifici dell'utente
-
Mantiene una chiara separazione tra l'identità dell'agente e l'autorizzazione dell'utente
-
Supporta ambiti granulari che limitano i dati a cui l'agente può accedere
Scenario di esempio: un agente di produttività deve accedere a Google Calendar di un utente per pianificare riunioni, a Gmail per inviare email e a Google Drive per archiviare documenti. L'agente utilizza la concessione del codice di autorizzazione OAuth 2.0 per ottenere il consenso dell'utente per ciascun servizio, con ambiti specifici che limitano l'accesso solo ai dati necessari. L'utente autorizza esplicitamente l'agente tramite la schermata di consenso di Google e AgentCore Identity archivia in modo sicuro le credenziali risultanti per un uso futuro.
Questo modello è ideale per gli assistenti personali, gli agenti del servizio clienti e per qualsiasi scenario in cui gli agenti abbiano bisogno di accedere a dati specifici dell'utente su più servizi. Per esempi dettagliati specifici del settore, consulta Personal Assistant Agents e Customer service agents.
Machine-to-machine autenticazione (concessione delle credenziali del client OAuth 2.0)
Il flusso di concessione delle credenziali del client OAuth 2.0 consente l'autenticazione diretta tra i sistemi senza l'interazione dell'utente. Questo modello è appropriato quando gli agenti devono accedere a risorse che non sono specifiche dell'utente o quando gli agenti agiscono autonomamente con il consenso dell'utente preautorizzato.
Caratteristiche chiave
-
Non è richiesta alcuna interazione o consenso da parte dell'utente
-
L'agente si autentica direttamente con i server di risorse utilizzando le proprie credenziali
-
Adatto per processi in background, attività pianificate e operazioni a livello di sistema
-
Le autorizzazioni sono definite a livello di agente anziché a livello di utente
Scenario di esempio: un agente di elaborazione dati aziendale deve raccogliere dati da più sistemi interni, elaborarli e archiviare i risultati in un data warehouse. L'agente utilizza la concessione delle credenziali del client OAuth 2.0 per autenticarsi direttamente con ciascun sistema utilizzando la propria identità e le autorizzazioni preconfigurate. Non è richiesta alcuna interazione da parte dell'utente e l'agente può operare quando gli agenti agiscono autonomamente con il consenso dell'utente preautorizzato a intervalli pianificati.
Questo modello è ideale per gli agenti di automazione aziendale, i flussi di lavoro di elaborazione dati e l'automazione. DevOps Per esempi dettagliati specifici del settore, consulta Enterprise automation agents, Data processing and analytics agents e Development and agents. DevOps
On-behalf-of scambio di token (scambio di token OAuth 2.0)
On-behalf-of Lo scambio di token (OBO) consente agli agenti di accedere ai server di risorse a valle per conto di un utente già autenticato. L'agente scambia il token utente in entrata con un nuovo token di accesso con ambito di pubblico tramite un provider di credenziali in uscita, associando sia l'identità dell'utente che l'identità dell'agente al token risultante. I servizi downstream possono quindi prendere decisioni di autorizzazione in base a entrambe le identità, senza richiedere all'utente di passare attraverso un altro flusso di consenso.
Caratteristiche chiave
-
Nessun consenso utente aggiuntivo: il token utente in entrata viene scambiato direttamente con un token di accesso a valle
-
Propaga sia l'identità dell'utente che l'identità dell'agente (o del carico di lavoro) su più hop, fornendo a ciascun servizio a valle il contesto in cui prendere le proprie decisioni di autorizzazione
-
Supporta lo scambio di token standard (RFC 8693
) o la concessione di autorizzazione JWT (RFC 7523), a seconda del provider di identità
Scenario di esempio: accesso a un'applicazione aziendale per utente: un'azienda dispone di un'applicazione HR interna che impone il controllo degli accessi per utente: ogni dipendente può visualizzare solo i propri dati su retribuzioni e benefici. L'azienda vuole consentire ai dipendenti di interrogare questa applicazione tramite un agente di intelligenza artificiale, senza allentare nessuna delle politiche di accesso esistenti.
-
Mike (identity admin) configura l'applicazione HR come fornitore di credenziali OAuth in AgentCore Identity, inclusa la modalità di scambio di token OBO. Una volta configurata, non è necessario alcun provisioning per utente: qualsiasi dipendente in grado di autenticarsi presso l'agente può accedere all'applicazione HR tramite di essa.
-
Bob (agente sviluppatore) aggiunge uno strumento che chiama l'applicazione HR. Non scrive alcuna logica di scambio di token né gestisce i segreti dei clienti. Chiama
GetResourceOauth2Tokencon il token di accesso al carico di lavoro e AgentCore Identity restituisce un token downstream con ambito. Bob si concentra su ciò che l'agente fa con i dati, non su come vengono autorizzati. -
Sarah (utente finale) accede all'agente e gli chiede di estrarre il riepilogo dei vantaggi. Non le viene richiesto di accedere una seconda volta. Dietro le quinte, AgentCore Identity scambia il token in entrata di Sarah con un token di accesso a valle che riporta la sua identità. L'applicazione HR applica le politiche di accesso esistenti e restituisce solo i dati di Sarah, gli stessi dati che vedrebbe se accedesse direttamente all'applicazione.
Questo modello è ideale per gli agenti aziendali che utilizzano più servizi che riconoscono l'identità in un unico dominio di fiducia. Per un'analisi approfondita dei tipi di concessione, della configurazione e dei provider di identità supportati, consulta Token Exchange. On-behalf-of
Scelta del modello di autenticazione corretto
Nel progettare la strategia di autenticazione tramite agente, considerate questi fattori per determinare il modello più appropriato:
| Factor | User-delegated accesso (concessione del codice di autorizzazione OAuth 2.0) | Machine-to-machine autenticazione (concessione delle credenziali del client OAuth 2.0) | On-behalf-of scambio di token (scambio di token OAuth 2.0) |
|---|---|---|---|
|
Proprietà dei dati |
User-specific dati (email, documenti, calendari personali) |
Dati di proprietà del sistema o dell'organizzazione (analisi, registri, risorse condivise) |
User-specific dati, in cui l'utente è già autenticato con l'agente |
|
interazione con l'utente |
L'utente è presente e può fornire il consenso |
Nessuna interazione con l'utente richiesta o disponibile |
L'utente è già autenticato all'agente; nessuna nuova richiesta di consenso |
|
Tempistica dell'operazione |
Operazioni interattive in tempo reale |
Operazioni in background, pianificate o in batch |
Operazioni interattive in tempo reale avviate da un utente autenticato |
|
Ambito di autorizzazione |
Le autorizzazioni variano in base all'utente e alle relative scelte di consenso |
Autorizzazioni coerenti definite a livello di agente |
Autorizzazioni derivate dal token utente in entrata e dalla politica del fornitore a valle |
Molte implementazioni di agenti richiederanno tutti i modelli per i diversi aspetti della loro funzionalità. Ad esempio, un agente del servizio clienti potrebbe utilizzare l'accesso delegato dall'utente per recuperare i dati di un cliente specifico mentre utilizza l'autenticazione da macchina a macchina per accedere alle knowledge base aziendali e ai sistemi interni. Lo stesso agente può anche utilizzare lo scambio di token per conto dell'utente per propagare l'identità dell'utente ai servizi a valle che impongono l'autorizzazione per utente, senza chiedere nuovamente all'utente. AgentCore Identity supporta tutti i pattern contemporaneamente, consentendo agli agenti di utilizzare il meccanismo di autenticazione più appropriato per ogni risorsa a cui devono accedere.
Tutti i modelli di autenticazione traggono vantaggio dalle funzionalità principali di AgentCore Identity:
-
Archiviazione sicura delle credenziali senza rivelare segreti al codice dell'agente
-
Interfacce di autenticazione coerenti su più tipi di risorse
-
Registrazione completa degli audit per la sicurezza e la conformità
-
Fine-grained controlli di accesso basati su identità e contesto
-
Integrazione semplificata tramite SDK AgentCore
