Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Authentifier les utilisateurs finaux auprès de la mémoire avec OAuth
Le plan de données Amazon Bedrock AgentCore Memory authentifie les appelants avec AWS Signature Version 4 (Sigv4) uniquement. Lorsque votre backend ou votre agent appelle Memory pour le compte de nombreux utilisateurs, Memory ne voit que le rôle IAM de votre backend. Il ne peut ni vérifier ni appliquer à quel utilisateur final est destinée une demande donnée. La séparation des données d'un utilisateur de celles d'un autre dépend entièrement de la définition correcte du code de votre application actorId et de l'espace de noms pour chaque demande ; rien au niveau de la couche mémoire n'empêche une demande gérant l'utilisateur A de lire les données de l'utilisateur B.
En connectant Memory à une AgentCore passerelle configurée pour l'authentification entrante OAuth (CUSTOM_JWT), vous ajoutez le support OAuth que Memory ne possède pas à lui seul. L'appelant présente la demande au JWT de l'utilisateur final, la passerelle la valide et les politiques de contrôle d'accès appliquent l'isolation en fonction des revendications du jeton, au niveau de la couche infrastructure, indépendamment de la logique de votre application. La passerelle appelle ensuite Memory dans le cadre de son rôle d'exécution de passerelle, agissant comme un pont entre l' OAuth-authenticated appelant et le plan de IAM-authenticated données de Memory.
Note
Cette page s'appuie sur le connecteur AgentCore de mémoire. Configurez d'abord une passerelle avec une cible de connecteur de mémoire. Pour plus d'informations, voir Accès à AgentCore la mémoire via une passerelle.
Comment la passerelle relie OAuth à la mémoire
Lorsqu'une passerelle utilise CUSTOM_JWT l'authentification entrante devant une cible Memory Connector :
-
L'appelant envoie une demande à la passerelle avec un jeton porteur JWT émis par votre fournisseur OpenID Connect. Selon votre application, le jeton peut représenter un utilisateur final ou l'agent lui-même, et peut contenir des informations sur l'utilisateur final dans ses revendications.
-
La passerelle valide le jeton par rapport au fournisseur que vous avez configuré, et les revendications du jeton (telles que
subetclient_id) sont mises à la disposition des politiques de contrôle d'accès de la passerelle en tant que balises principales. -
Si une politique autorise la demande, la passerelle la transmet au plan de données de la mémoire dans le cadre de son rôle d'exécution de passerelle (mode d'identification
GATEWAY_IAM_ROLEsortant).
Astuce
Dans une architecture classique de chatbot ou d'agent, l'utilisateur final n'appelle pas Memory directement. Votre agent ou service principal est l'appelant HTTP et transmet le JWT de l'utilisateur final à chaque demande de mémoire : le jeton « voyage avec » la demande. La passerelle authentifie ce jeton et évalue les politiques par rapport à ses revendications, de sorte que l'accès est appliqué à l'utilisateur final représenté par le jeton, même si l'agent est l'entité qui passe l'appel.
C'est pourquoi un contrôle d'accès précis est important : grâce à lui, vous pouvez vous assurer qu'une demande n'atteint que les données de mémoire appartenant à l'utilisateur final authentifié contenues dans le jeton, au lieu de faire confiance à l'agent pour définir lui-même l'espace de noms correctactorId.
Avec une application d'agent, vos utilisateurs finaux peuvent se connecter via un fournisseur d'identité OAuth standard, par exemple Amazon Cognito ou tout autre fournisseur OpenID Connect, et vous pouvez appliquer l'isolation de la mémoire par utilisateur en fonction de l'identité de l'utilisateur final authentifié. Votre application ne distribue pas AWS d'informations d'identification aux utilisateurs finaux et Memory n'a pas besoin de comprendre OAuth de manière native.
La configuration de l'CUSTOM_JWTautorisateur (URL de découverte OpenID Connect, public et clients autorisés, et étendues) est une tâche d'autorisation entrante standard de passerelle qui n'est pas spécifique à Memory. Pour la configuration de l'autorisateur, voir Créer une AgentCore passerelle. Pour savoir comment les revendications JWT correspondent au AgentCore::OAuthUser principal et à ses balises, voir Concepts Concepts de base fondamentaux.
Note
OAuth (CUSTOM_JWT) inbound est compatible uniquement avec le mode d'identification GATEWAY_IAM_ROLE sortant. Le CALLER_IAM_CREDENTIALS mode transmet l'identité IAM de l'appelant, qui n'existe pas pour un JWT-authenticated appelant, elle est donc rejetée lors de la création de la cible. Pour consulter la matrice de compatibilité complète, consultez la section Modes d'authentification entrants et sortants.
Imposer l'accès à la mémoire par utilisateur
L'authentification des appelants avec OAuth est ce qui rend possible l'autorisation basée sur l'identité, mais l'authentification à elle seule ne limite pas les possibilités de l'appelant. Toute demande contenant un jeton valide peut toujours atteindre tous les acteurs, sessions et espaces de noms de la ressource Mémoire. Pour vous assurer que chaque demande ne peut accéder qu'aux données de mémoire appartenant à l'utilisateur final authentifié, dont l'identité est enregistrée dans le JWT, ajoutez des politiques de contrôle d'accès avec un contrôle d'accès précis. Pour savoir comment écrire ces politiques, consultez la section Contrôle Fine-grained d'accès à la mémoire.
