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](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/what-is-avp.html) 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](https://docs.cedarpolicy.com/). El contexto de la solicitud puede incluir un identificador del documento, la imagen u otro recurso que solicitaron y la acción que el usuario desea realizar en el recurso.
Tu aplicación puede proporcionar la identidad de tu usuario o los tokens de acceso a los permisos verificados [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)o a las solicitudes de [BatchIsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_BatchIsAuthorizedWithToken.html)API. Estas operaciones de API aceptan a los usuarios como `Principal` y toman decisiones de autorización de `Action` en el `Resource` al que desean acceder. El código `Context` personalizado adicional puede contribuir a una decisión de acceso detallada.
Cuando la aplicación presenta un token en una solicitud de API `IsAuthorizedWithToken`, Verified Permissions realiza las siguientes validaciones.
1. El grupo de usuarios es un [origen de identidad](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) de Verified Permissions configurado para el almacén de políticas solicitado.
1. La reclamación `client_id` o `aud`, 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](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/cognito-validation.html) en el origen de identidad de Verified Permissions.
1. El token no ha caducado.
1. El valor de la notificación `token_use` que figura en su token coincide con los parámetros que ha pasado a `IsAuthorizedWithToken`. La notificación `token_use` debe ser `access` si la ha pasado al parámetro `accessToken` y `id` si la ha pasado al parámetro `identityToken`.
1. La firma de tu token proviene de las claves web JSON 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](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) para el [almacén de políticas](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/terminology.html#term-policy-store). 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 Verified Permissions es como una política de IAM en AWS. Declara un *entidad principal*, un *recurso* y una *acción*. Verified Permissions responde a la solicitud con `Allow` si coincide con una acción permitida y no con una acción `Deny` explícita; de lo contrario, responde con `Deny`. Para obtener más información, consulte las [políticas de Amazon Verified Permissions](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policies.html) en la *Guía del usuario de Amazon Verified Permissions*.
**Personalización de tokens**
Para cambiar, agregar o eliminar las notificaciones de usuario que desea presentar a Verified Permissions, personalice el contenido de los tokens de acceso e identidad con un [Desencadenador de Lambda anterior a la generación del token](user-pool-lambda-pre-token-generation.md). 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**
+ [Mapping Amazon Cognito tokens to Verified Permissions schema](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-sources_map-token-to-schema.html)
+ [Autorice API Gateway APIs con Amazon Verified Permissions y Amazon Cognito](https://aws.amazon.com/blogs/security/authorize-api-gateway-apis-using-amazon-verified-permissions-and-amazon-cognito/)
+ [Taller: Autenticación y autorización con Amazon Cognito y Verified Permissions](https://catalog.workshops.aws/app-auth)
## Autorización de API con Verified Permissions
Su ID o sus tokens de acceso pueden autorizar las solicitudes al backend de Amazon API Gateway REST APIs con permisos verificados. Puede crear un [almacén de políticas](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores.html) con enlaces inmediatos a su grupo de usuarios y a su API. Con la opción de inicio [Configuración con API Gateway y un origen de identidades](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores_create.html), Verified Permissions añade un origen de identidad del grupo de usuarios al almacén de políticas y un autorizador de Lambda a la API. Cuando la aplicación pasa un token portador del grupo de usuarios a la API, el autorizador de Lambda invoca Verified Permissions. El autorizador transfiere el token como entidad principal y la ruta y el método de solicitud como acción.
El siguiente diagrama ilustra el flujo de autorización de una API de API Gateway con Verified Permissions. Para obtener un desglose detallado, consulte [API-linked policy stores](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores_api-userpool.html) en la Guía del usuario de Amazon Verified Permissions.
![\[Diagrama que ilustra el flujo de autorización de la API con Amazon Verified Permissions. Una aplicación realiza una solicitud a una API de Amazon API Gateway. La API invoca un autorizador de Lambda. El autorizador realiza una solicitud de API a Verified Permissions. Verified Permissions comprueba la validez del token y devuelve una decisión de autorización.\]](http://docs.aws.amazon.com/es_es/cognito/latest/developerguide/images/amazon-cognito-avp-use-case.png)
Verified Permissions estructura la autorización de la API en torno a [grupos de usuarios](cognito-user-pools-user-groups.md). Como tanto el identificador como el token de acceso incluyen una `cognito:groups` reclamación, su almacén de pólizas puede gestionar el control de acceso basado en funciones (RBAC) por usted APIs en una variedad de contextos de aplicación.
### Elección de la configuración del almacén de políticas
Al configurar un origen de identidad en un almacén de políticas, debe elegir si desea procesar los tokens de acceso o de ID. Esta decisión es importante para el funcionamiento del motor de políticas. Los tokens de ID contienen atributos de usuario. [Los tokens de acceso contienen información sobre el control de acceso de los usuarios: ámbitos. OAuth ](cognito-user-pools-define-resource-servers.md) Aunque ambos tipos de token contienen información sobre la pertenencia a un grupo, generalmente recomendamos el token de acceso para el RBAC con un almacén de políticas de Verified Permissions. El token de acceso precisa la pertenencia a un grupo con ámbitos que pueden contribuir a la decisión de autorización. Las notificaciones de un token de acceso pasan a formar parte del [contexto](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/context.html) de la solicitud de autorización.
También debe configurar los tipos de entidad de usuario y grupo al configurar un grupo de usuarios como origen de identidad. Los tipos de entidad son identificadores de entidades principales, de acciones y de recursos a los que puede hacer referencia en las políticas de Verified Permissions. 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 de entidades 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 de políticas vinculado a una API](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores_api-userpool.html) o seguir la **configuración guiada** en la consola de Verified Permissions, el almacén de políticas tiene automáticamente esta relación de entidad principal y miembro.
El token de ID puede combinar el RBAC con el control de acceso basado en atributos (ABAC). Tras crear un [almacén de políticas vinculado a una API](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores_api-userpool.html), puede mejorar las políticas con los [atributos de usuario](#amazon-cognito-authorization-with-avp-example-policy) *y* la pertenencia a grupos. Las notificaciones de atributos de un token de ID se convierten en [atributos de la entidad principal](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policies_examples-abac.html) de la solicitud de autorización. Sus políticas pueden tomar decisiones de autorización en función de los atributos de la entidad principal.
También puede configurar un almacén de políticas para que acepte tokens con una notificación `aud` o `client_id` que coincidan con una lista de clientes de aplicación aceptables que haya proporcionado.
### Ejemplo de política para una autorización de API basada en el rol
El siguiente ejemplo de política se creó mediante la configuración de un almacén de políticas de permisos verificados para una API REST de [PetStore](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-from-example.html)ejemplo.
```
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 decisión `Allow` a la solicitud de autorización de su aplicación cuando:
1. La aplicación ha pasado un token de ID o de acceso en un encabezado `Authorization` como token de portador.
1. La aplicación ha pasado un token con una notificación `cognito:groups` con la cadena `MyGroup`.
1. La aplicación ha presentado una solicitud `HTTP GET` a, por ejemplo, `https://myapi.example.com/pets` o `https://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 Verified Permissions en condiciones distintas de las solicitudes de API. Puede enviar cualquier decisión de control de acceso de su aplicación a su almacén de políticas. Puede, por ejemplo, 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 Cedar](https://docs.cedarpolicy.com/) para permitir que los usuarios del departamento de Finanzas que se autentiquen con un cliente de aplicación de grupo de usuarios puedan leer y escribir `example_image.png`. John, un usuario de la aplicación, recibe un token de ID del cliente de la aplicación y lo pasa en una solicitud GET a una 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
);
```
A continuación, se muestra un ejemplo de entidad principal para un usuario de un grupo de usuarios con un ID `us-east-1_Example` con 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 Verified Permissions, utilice el siguiente formato:
```
permit (
principal in [Namespace]::[Group Entity]::"[Group name]",
action,
resource
);
```
**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](https://docs.aws.amazon.com/cognito/latest/developerguide/attributes-for-access-control.html) de los grupos de identidades de Amazon Cognito para AWS las credenciales son dos formas de control de acceso basado en atributos (ABAC). A continuación, se muestra una comparación de las características de Verified Permissions y Amazon Cognito ABAC. En ABAC, 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 una decisión obtenida a partir del análisis de un grupo de usuarios (JWT). | 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html) a su usuario en función de sus atributos. Las condiciones de la política de IAM pueden comprobar las etiquetas Allow o el acceso Deny de los usuarios. Servicios de AWS | Una sesión etiquetada con AWS credenciales temporales para un rol de IAM. |