Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Autentique a los usuarios finales en Memory con OAuth
El plano de datos Amazon Bedrock AgentCore Memory autentica a las personas que llaman únicamente con la versión 4 de AWS Signature (SIGv4). Cuando su backend o su agente llama a Memory en nombre de muchos usuarios, Memory solo ve la función de IAM de su backend; no puede verificar ni exigir a qué usuario final va dirigida una solicitud determinada. Mantener los datos de un usuario separados de los de otro depende totalmente de que el código de la aplicación defina el espacio de nombres actorId y el espacio de nombres correctos en cada solicitud; en la capa de memoria no hay nada que impida que una persona que gestione solicitudes del usuario A lea los datos del usuario B.
Al usar Memory con una AgentCore puerta de enlace configurada para la autenticación entrante mediante OAuth (CUSTOM_JWT), se añade una compatibilidad con OAuth que Memory no tiene por sí sola. La persona que llama presenta la solicitud al JWT del usuario final, la puerta de enlace la valida y las políticas de control de acceso imponen el aislamiento en función de las afirmaciones del token, a nivel de infraestructura, independientemente de la lógica de la aplicación. A continuación, la puerta de enlace llama a Memory en su función de ejecución de puerta de enlace y actúa como puente entre la OAuth-authenticated persona que llama y el plano de datos de Memory. IAM-authenticated
nota
Esta página se basa en el conector de AgentCore memoria. Configure primero una puerta de enlace con un conector de memoria como destino. Para obtener más información, consulte Acceder a AgentCore la memoria a través de una puerta de enlace.
Cómo conecta la puerta de enlace OAuth con la memoria
Cuando una puerta de enlace utiliza la autenticación CUSTOM_JWT entrante frente al objetivo de un conector de memoria:
-
La persona que llama envía una solicitud a la puerta de enlace con un token portador de JWT emitido por tu proveedor de OpenID Connect. En función de la aplicación, el token puede representar a un usuario final o al propio agente, y puede incluir información sobre el usuario final en sus declaraciones.
-
La puerta de enlace valida el token comparándolo con el proveedor que hayas configurado y las afirmaciones del token (como
subyclient_id) pasan a estar disponibles en las políticas de control de acceso de la puerta de enlace como etiquetas principales. -
Si una política permite la solicitud, la puerta de enlace la reenvía al plano de datos de memoria bajo su función de ejecución de puerta de enlace (el modo de credenciales
GATEWAY_IAM_ROLEsalientes).
sugerencia
En una arquitectura típica de agentes o chatbots, el usuario final no llama directamente a Memory. Su agente o servicio de backend es el que llama mediante HTTP y envía el JWT del usuario final junto con cada solicitud de memoria; el token «viaja con» la solicitud. La pasarela autentica ese token y evalúa las políticas en función de lo que afirma. De este modo, el acceso se aplica al usuario final al que representa el token, aunque el agente sea la entidad que realiza la llamada.
Por eso es importante un control de acceso detallado: con él, puede asegurarse de que una solicitud solo llegue a los datos de memoria que pertenecen al usuario final autenticado incluidos en el token, en lugar de confiar en que el propio agente defina el espacio de nombres correcto y el espacio de nombres. actorId
Con una aplicación de agente, los usuarios finales pueden iniciar sesión a través de un proveedor de identidad de OAuth estándar (por ejemplo, Amazon Cognito o cualquier proveedor de OpenID Connect) y usted puede imponer el aislamiento de memoria por usuario en función de la identidad del usuario final autenticado. Su aplicación no distribuye AWS las credenciales a los usuarios finales y no es necesario que Memory comprenda OAuth de forma nativa.
La configuración del CUSTOM_JWT autorizador (la URL de detección de OpenID Connect, la audiencia y los clientes permitidos y los ámbitos) es una tarea estándar de autorización de entrada de una puerta de enlace y no es específica de Memory. Para ver la configuración del autorizador, consulte Crear una puerta de enlace. AgentCore Para saber cómo se relacionan las afirmaciones de JWT con el AgentCore::OAuthUser principal y sus etiquetas, consulte Conceptos básicos.
nota
El OAuth (CUSTOM_JWT) entrante solo es compatible con el modo de credenciales salientes. GATEWAY_IAM_ROLE El CALLER_IAM_CREDENTIALS modo reenvía la identidad de IAM de la persona que llama, que no existe para la persona que JWT-authenticated llama, por lo que se rechaza al crear el objetivo. Para ver la matriz de compatibilidad completa, consulta los modos de autenticación entrante y saliente.
Exija el acceso a la memoria por usuario
La autenticación de las personas que llaman con OAuth es lo que hace posible la autorización basada en la identidad, pero la autenticación por sí sola no limita lo que puede hacer la persona que llama. Cualquier solicitud con un token válido aún puede llegar a todos los actores, sesiones y espacios de nombres del recurso de memoria. Para garantizar que cada solicitud solo pueda acceder a los datos de memoria que pertenecen al usuario final autenticado (cuya identidad figura en el JWT), añada políticas de control de acceso con un control de acceso detallado. Para saber cómo escribir esas políticas, consulta el control de acceso a Memory. Fine-grained
