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.
Autorización con Amazon Verified Permissions
Amazon Verified Permissions es un servicio de autorización para las aplicaciones que crea. Al agregar un grupo de usuarios de Amazon Cognito como origen de identidad, la aplicación puede pasar tokens de acceso o identidad (ID) de grupo de usuarios a Verified Permissions para que tomen una decisión de permitir o denegar. Los permisos verificados consideran las propiedades del usuario y el contexto de la solicitud en función de las políticas que escriba en Lenguaje de política de Cedar
Tu aplicación puede proporcionar la identidad de tu usuario o los tokens de acceso a los permisos verificados IsAuthorizedWithTokeno a BatchIsAuthorizedWithTokenAPIlas solicitudes. Estas API operaciones aceptan a tus usuarios como usuarios Principal
y toman decisiones de Action
autorización para aquellos a los Resource
que desean acceder. La personalización adicional Context
puede contribuir a una decisión de acceso detallada.
Cuando tu aplicación presenta un token en una IsAuthorizedWithToken
API solicitud, Verified Permissions realiza las siguientes validaciones.
-
El grupo de usuarios es un origen de identidad de Verified Permissions configurado para el almacén de políticas solicitado.
-
La reclamación
client_id
oaud
, en el token de acceso o identidad, respectivamente, coincide con el ID de cliente de la aplicación de un grupo de usuarios que proporcionó a Verified Permissions. Para verificar esta reclamación, debe configurar la validación del ID de cliente en el origen de identidad de Verified Permissions. -
El token no ha caducado.
-
El valor de la
token_use
reclamación de tu token coincide con los parámetros a los que has pasado.IsAuthorizedWithToken
Latoken_use
reclamación debe seraccess
si la pasaste alaccessToken
parámetro yid
si la pasaste alidentityToken
parámetro. -
La firma de tu token proviene de las claves JSON web publicadas (JWKs) de tu grupo de usuarios. Puedes ver tu JWKs anuncio
https://cognito-idp.
.Region
.amazonaws.com/your user pool ID
/.well-known/jwks.json
Tokens revocados y usuarios eliminados
Los permisos verificados solo validan la información que conoce del origen de identidad y de la fecha de caducidad del token del usuario. Los permisos verificados no comprueban la revocación del token ni la existencia del usuario. Si revocó el token del usuario o eliminó el perfil de usuario del grupo de usuarios, Verified Permissions seguirá considerando que el token es válido hasta que caduque.
Evaluación de políticas
Configure el grupo de usuarios como origen de identidad para el almacén de políticas. Configure la aplicación para enviar los tokens de los usuarios en las solicitudes de permisos verificados. Para cada solicitud, Verified Permissions compara las reclamaciones del token con una política. Una política de permisos verificados es como una IAM política de AWS. Declara un entidad principal, un recurso y una acción. Verified Permissions responde a tu solicitud Allow
si coincide con una acción permitida y no con una Deny
acción explícita; de lo contrario, responde conDeny
. Para obtener más información, consulte las políticas de Amazon Verified Permissions en la Guía del usuario de Amazon Verified Permissions.
Personalización de tokens
Para cambiar, añadir y eliminar las reclamaciones de los usuarios que deseas presentar a Verified Permissions, personaliza el contenido de tus identificadores de acceso e identidad con unDesencadenador de Lambda anterior a la generación del token. Con un desencadenador previo a la generación del token, puede agregar y modificar reclamaciones en los tokens. Por ejemplo, puede consultar una base de datos para atributos de usuario adicionales y codificarlos en el token de ID.
nota
Debido a la forma en que Verified Permissions procesa las reclamaciones, no agregue las reclamaciones con nombres cognito
, dev
y custom
en la función de generación previa al token. Si presenta estos prefijos de reclamación reservados no en formato delimitado por dos puntos, como cognito:username
sino como nombres de reclamación completos, las solicitudes de autorización producen un error.
Recursos adicionales de
APIautorización con permisos verificados
Tu ID o tus tokens de acceso pueden autorizar las solicitudes al back-end de Amazon API Gateway REST APIs con permisos verificados. Puede crear un almacén de políticas con enlaces inmediatos a su grupo de usuarios y. API Con la opción de inicio Configurar con Cognito y API Gateway, Verified Permissions añade una fuente de identidad del grupo de usuarios al almacén de políticas y un autorizador Lambda al. API Cuando la aplicación pasa un token portador del grupo de usuarios alAPI, el autorizador de Lambda invoca los permisos verificados. El autorizador transfiere el token como principal y la ruta y el método de la solicitud como acción.
El siguiente diagrama ilustra el flujo de autorización de una API puerta de enlace API con permisos verificados. Para obtener un desglose detallado, consulta las tiendas API de políticas vinculadas en la Guía del usuario de permisos verificados de Amazon.
Los permisos verificados estructuran API la autorización en torno a grupos de usuarios. Como tanto el identificador como el token de acceso incluyen una cognito:groups
reclamación, su almacén de políticas puede gestionar el control de acceso basado en roles (RBAC) por usted APIs en una variedad de contextos de aplicación.
Elegir la configuración del almacén de políticas
Al configurar una fuente de identidad en un almacén de políticas, debe elegir si desea procesar los tokens de acceso o de identificación. Esta decisión es importante para el funcionamiento de su motor de políticas. Los tokens de identificación contienen atributos de usuario. Los tokens de acceso contienen información sobre el control de acceso del usuario: OAuth ámbitos. Si bien ambos tipos de token contienen información sobre la pertenencia a un grupo, generalmente recomendamos utilizar el token de acceso en un almacén de políticas de permisos RBAC verificados. El token de acceso aumenta la pertenencia a un grupo con ámbitos que pueden contribuir a la decisión de autorización. Las afirmaciones de un token de acceso pasan a formar parte del contexto de la solicitud de autorización.
También debe configurar los tipos de entidades de usuario y grupo al configurar un grupo de usuarios como fuente de identidad. Los tipos de entidad son identificadores principales, de acciones y de recursos a los que puede hacer referencia en las políticas de permisos verificados. Las entidades de los almacenes de políticas pueden tener una relación de pertenencia, en la que una entidad puede ser miembro de una entidad principal. Con la pertenencia, puede hacer referencia a grupos principales, grupos de acción y grupos de recursos. En el caso de los grupos de usuarios, el tipo de entidad de usuario que especifique debe ser miembro del tipo de entidad del grupo. Al configurar un almacén API de políticas vinculado o seguir la configuración guiada en la consola de permisos verificados, el almacén de políticas tiene automáticamente esta relación padre-miembro.
El token de ID se puede combinar RBAC con el control de acceso basado en atributos (). ABAC Tras crear un almacén API de políticas vinculado a un servidor, puede mejorarlas con los atributos de los usuarios y la pertenencia a grupos. Las afirmaciones de atributos de un token de ID se convierten en los atributos principales de la solicitud de autorización. Sus políticas pueden tomar decisiones de autorización en función de los atributos principales.
También puede configurar un almacén de políticas para que acepte tokens con una aud
o una client_id
afirmación que coincida con una lista de clientes de aplicaciones aceptables que usted proporcione.
Ejemplo de política de autorización basada en funciones API
Por ejemplo, el siguiente ejemplo de política se creó mediante la configuración de un almacén de políticas de permisos verificados. PetStoreRESTAPI
permit( principal in PetStore::UserGroup::"us-east-1_EXAMPLE|MyGroup", action in [ PetStore::Action::"get /pets", PetStore::Action::"get /pets/{petId}" ], resource );
Verified Permissions devuelve una Allow
decisión a la solicitud de autorización de tu aplicación cuando:
-
Tu aplicación pasó un identificador o un token de acceso en un
Authorization
encabezado como token portador. -
Tu aplicación pasó un token con una
cognito:groups
afirmación que contiene la cadenaMyGroup
. -
Su solicitud hizo una
HTTP GET
solicitud a, por ejemplo,https://myapi.example.com/pets
ohttps://myapi.example.com/pets/scrappy
.
Política de ejemplo para un usuario de Amazon Cognito
Su grupo de usuarios también puede generar solicitudes de autorización para permisos verificados en condiciones distintas de las API solicitudes. Puede enviar cualquier decisión de control de acceso de su aplicación a su almacén de políticas. Por ejemplo, puede complementar la seguridad de Amazon DynamoDB o Amazon S3 con un control de acceso basado en atributos antes de que las solicitudes transiten por la red, lo que reduce el uso de la cuota.
El siguiente ejemplo utiliza el Lenguaje de políticas de Cedarexample_image.png
. John, un usuario de su aplicación, recibe un token de identificación del cliente de la aplicación y lo envía en una GET solicitud a un usuario URL que requiere autorización. https://example.com/images/example_image.png
El token de ID de John tiene una reclamación aud
del ID de cliente de la aplicación de grupo de usuarios 1234567890example
. La función de Lambda previa a la generación del token también insertó una nueva reclamación costCenter
con un valor, para John, de Finance1234
.
permit ( principal, actions in [ExampleCorp::Action::"readFile", "writeFile"], resource == ExampleCorp::Photo::"example_image.png" ) when { principal.aud == "1234567890example" && principal.custom.costCenter like "Finance*" };
El siguiente cuerpo de la solicitud da como resultado una respuesta Allow
.
{ "accesstoken": "
[John's ID token]
", "action": { "actionId": "readFile", "actionType": "Action" }, "resource": { "entityId": "example_image.png", "entityType": "Photo" } }
Cuando desee especificar una entidad principal en una política de Verified Permissions, utilice el siguiente formato:
permit ( principal == [Namespace]::[Entity]::"[user pool ID]"|"[user sub]", action, resource );
El siguiente es un ejemplo principal para un usuario de un grupo de usuarios con un ID us-east-1_Example
con un sub, o ID de usuario,973db890-092c-49e4-a9d0-912a4c0a20c7
.
principal ==
ExampleCorp
::User
::"us-east-1_Example
|973db890-092c-49e4-a9d0-912a4c0a20c7
",
Cuando desee especificar un grupo de usuarios en una política de permisos verificados, utilice el siguiente formato:
permit ( principal in [Namespace]::[Group Entity]::"[Group name]", action, resource );
A continuación se muestra un ejemplo
Control de acceso basado en atributos
La autorización con permisos verificados para sus aplicaciones y los atributos para la función de control de acceso de los grupos de identidades de Amazon Cognito para AWS las credenciales son formas de control de acceso basado en atributos (). ABAC La siguiente es una comparación de las características de Verified Permissions y Amazon CognitoABAC. EnABAC, un sistema examina los atributos de una entidad y toma una decisión de autorización a partir de las condiciones que usted defina.
Servicio | Proceso | Resultado |
---|---|---|
Amazon Verified Permissions | Devuelve una Deny decisión Allow o tomada a partir del análisis de un grupo de usuariosJWT. |
El acceso a los recursos de la aplicación se realiza correctamente o fracasa según la evaluación de las políticas de Cedar. |
Grupos de identidades de Amazon Cognito (atributos para el control de acceso) | Asigna etiquetas de sesión a su usuario en función de sus atributos. IAMlas condiciones de la política pueden comprobar las etiquetas Allow o Deny el acceso de los Servicios de AWS usuarios. |
Una sesión etiquetada con AWS credenciales temporales para un IAM rol. |