As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Autentique usuários finais na memória com OAuth
O plano de dados Amazon Bedrock AgentCore Memory autentica os chamadores somente com a versão 4 do AWS Signature (SigV4). Quando seu back-end ou agente chama a Memory em nome de muitos usuários, a Memory vê apenas a função IAM do seu back-end — ela não pode verificar ou impor a qual usuário final se destina uma determinada solicitação. Manter os dados de um usuário separados dos de outro depende inteiramente da configuração correta do código do aplicativo actorId e do namespace em cada solicitação; nada na camada de memória impede que uma solicitação que processa o Usuário A leia os dados do Usuário B.
Ao conectar a memória a um AgentCore gateway configurado para autenticação de entrada OAuth (CUSTOM_JWT), você adiciona suporte ao OAuth que a memória não tem sozinha. O chamador apresenta a solicitação ao JWT do usuário final, o gateway a valida e as políticas de controle de acesso impõem isolamento com base nas declarações do token — na camada de infraestrutura, independente da lógica do seu aplicativo. O gateway então chama a Memória sob sua função de execução de gateway, atuando como uma ponte entre o OAuth-authenticated chamador e o plano de IAM-authenticated dados da Memória.
nota
Esta página se baseia no conector de AgentCore memória. Configure primeiro um gateway com um conector de memória alvo. Para obter mais informações, consulte Acessar AgentCore memória por meio de um gateway.
Como o gateway conecta o OAuth à memória
Quando um gateway usa autenticação de CUSTOM_JWT entrada na frente de um destino de conector de memória:
-
O chamador envia uma solicitação ao gateway com um token portador JWT emitido pelo seu provedor OpenID Connect. Dependendo do seu aplicativo, o token pode representar um usuário final ou o próprio agente e pode conter informações do usuário final em suas reivindicações.
-
O gateway valida o token em relação ao provedor que você configurou, e as declarações do token (como
subeclient_id) ficam disponíveis para as políticas de controle de acesso do gateway como tags principais. -
Se uma política permitir a solicitação, o gateway a encaminha para o plano de dados da memória sob sua função de execução do gateway (o modo de credencial de
GATEWAY_IAM_ROLEsaída).
dica
Em uma arquitetura típica de chatbot ou agente, o usuário final não liga diretamente para a Memória. Seu agente ou serviço de back-end é o chamador HTTP e passa o JWT do usuário final junto com cada solicitação de memória — o token “viaja com” a solicitação. O gateway autentica esse token e avalia as políticas em relação às suas reivindicações, portanto, o acesso é imposto ao usuário final que o token representa, mesmo que o agente seja a entidade que faz a chamada.
É por isso que o controle de acesso refinado é importante: com ele, você pode garantir que uma solicitação alcance somente os dados de memória que pertencem ao usuário final autenticado transportados no token, em vez de confiar no agente para definir o namespace correto e o próprio namespace. actorId
Com um aplicativo de agente, seus usuários finais podem fazer login por meio de um provedor de identidade OAuth padrão — por exemplo, o Amazon Cognito ou qualquer provedor do OpenID Connect — e você pode aplicar o isolamento de memória por usuário com base na identidade autenticada do usuário final. Seu aplicativo não distribui AWS credenciais para usuários finais e a Memória não precisa entender o OAuth de forma nativa.
Configurar o CUSTOM_JWT autorizador (URL de descoberta do OpenID Connect, público e clientes permitidos e escopos) é uma tarefa padrão de autorização de entrada do gateway e não é específica da Memory. Para a configuração do autorizador, consulte Criar um AgentCore gateway. Para saber como as reivindicações da JWT são mapeadas para o AgentCore::OAuthUser principal e suas tags, consulte Conceitos Principais conceitos básicos.
nota
A entrada do OAuth (CUSTOM_JWT) é compatível somente com o modo de credencial de GATEWAY_IAM_ROLE saída. O CALLER_IAM_CREDENTIALS modo encaminha a identidade IAM do chamador, que não existe para um JWT-authenticated chamador, portanto, é rejeitada na criação do alvo. Para ver a matriz de compatibilidade completa, consulte Modos de autenticação de entrada e saída.
Imponha o acesso por usuário à memória
Autenticar chamadores com OAuth é o que possibilita a autorização baseada em identidade, mas a autenticação por si só não limita o que um chamador pode fazer. Qualquer solicitação com um token válido ainda pode alcançar cada ator, sessão e namespace no recurso Memory. Para garantir que cada solicitação possa acessar apenas dados de memória pertencentes ao usuário final autenticado — cuja identidade é transmitida no JWT — adicione políticas de controle de acesso com controle de acesso refinado. Para saber como escrever essas políticas, consulte Controle de Fine-grained acesso para memória.
