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.
# Trabajar con fuentes Amazon Cognito de identidad
Verified Permissions trabaja en estrecha colaboración con los grupos de usuarios de Amazon Cognito. Amazon Cognito JWTs tienen una estructura predecible. Verified Permissions reconoce esta estructura y aprovecha al máximo la información que contiene. Por ejemplo, puede implementar un modelo de autorización de control de acceso basado en roles (RBAC) con tokens de identificación o de acceso.
Una nueva fuente de identidad de grupos de usuarios de Amazon Cognito requiere la siguiente información:
+ El Región de AWS.
+ El ID del grupo de usuarios.
+ El tipo de entidad principal que desea asociar a su fuente de identidad, por ejemplo`MyCorp::User`.
+ El tipo de entidad de grupo principal que desea asociar a su fuente de identidad, por ejemplo`MyCorp::UserGroup`.
+ El cliente IDs de su grupo de usuarios al que desea autorizar para realizar solicitudes a su almacén de políticas.
Como los permisos verificados solo funcionan con grupos de usuarios de Amazon Cognito en la misma cuenta Cuenta de AWS, no puede especificar una fuente de identidad en otra cuenta. Verified Permissions establece el *prefijo de la entidad* (el identificador de la fuente de identidad al que debe hacer referencia en las políticas que actúan sobre los principios del grupo de usuarios) como el ID de su grupo de usuarios, por ejemplo. `us-west-2_EXAMPLE` En este caso, haría referencia a un usuario de ese grupo de usuarios con un ID como `a1b2c3d4-5678-90ab-cdef-EXAMPLE22222` `us-west-2_EXAMPLE|a1b2c3d4-5678-90ab-cdef-EXAMPLE22222`
*Las* notificaciones de los tokens del grupo de usuarios pueden contener atributos, ámbitos, grupos IDs, clientes y datos personalizados. [Amazon Cognito JWTs](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)tienen la capacidad de incluir una variedad de información que puede contribuir a las decisiones de autorización en los permisos verificados. Entre ellos se incluyen:
1. El nombre de usuario y las reclamaciones grupales incluyen un `cognito:` prefijo
1. [Atributos de usuario personalizados](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-custom-attributes) con un `custom: prefix`
1. Las reclamaciones personalizadas se añaden en tiempo de ejecución
1. El estándar de la OIDC afirma como y `sub` `email`
Tratamos estas reclamaciones en detalle y cómo gestionarlas en las políticas de permisos verificados, en. [Asignación de Amazon Cognito tokens al esquema](cognito-map-token-to-schema.md)
**importante**
Si bien puedes revocar los Amazon Cognito tokens antes de que caduquen, se JWTs consideran recursos apátridas que son autónomos y están sujetos a una firma y validez. Por lo general, los servicios que cumplen con [el RFC 7519 de JSON Web Token](https://datatracker.ietf.org/doc/html/rfc7519) validan los tokens de forma remota y no están obligados a validarlos con el emisor. Esto significa que los permisos verificados pueden conceder acceso en función de un token que se haya revocado o emitido a un usuario que se haya eliminado posteriormente. Para reducir este riesgo, le recomendamos que cree tokens con una validez lo más corta posible y que revoque los tokens de actualización cuando desee eliminar la autorización para continuar con la sesión de un usuario. Para obtener más información, consulta [Finalizar las sesiones de usuario con la revocación de un token](https://docs.aws.amazon.com/cognito/latest/developerguide/token-revocation.html)
En el siguiente ejemplo, se muestra cómo puede crear una política que haga referencia a algunas de las reclamaciones del grupo de usuarios de Amazon Cognito asociadas a un principal.
```
permit(
principal,
action,
resource == ExampleCo::Photo::"VacationPhoto94.jpg"
)
when {
principal["cognito:username"]) == "alice" &&
principal["custom:department"]) == "Finance"
};
```
En el siguiente ejemplo, se muestra cómo se puede crear una política que haga referencia a un principal que sea un usuario de un grupo de usuarios de Cognito. Tenga en cuenta que el ID principal adopta la forma de`"|"`.
```
permit(
principal == ExampleCo::User::"us-east-1_example|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
action,
resource == ExampleCo::Photo::"VacationPhoto94.jpg"
);
```
Las políticas de Cedar para las fuentes de identidad de los grupos de usuarios de Verified Permissions utilizan una sintaxis especial para los nombres de las notificaciones que contienen caracteres distintos de los alfanuméricos y los guiones bajos ()`_`. Esto incluye las notificaciones de prefijos de grupos de usuarios que contienen un `:` carácter, como y. `cognito:username` `custom:department` Para escribir una condición de la póliza que haga referencia a la `custom:department` afirmación `cognito:username` o a la reclamación, escríbalas como `principal["cognito:username"]` y`principal["custom:department"]`, respectivamente.
**nota**
Si un token contiene una reclamación con un `custom:` prefijo `cognito:` o y un nombre de reclamación con el valor literal `cognito` o`custom`, una solicitud de autorización con un prefijo no [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)se aceptará con un`ValidationException`.
Para obtener más información sobre la representación cartográfica de las reclamaciones, consulte[Asignación de Amazon Cognito tokens al esquema](cognito-map-token-to-schema.md). Para obtener más información sobre la autorización de Amazon Cognito los usuarios, consulte [Autorización con permisos verificados de Amazon](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) en la Guía *para desarrolladores de Amazon Cognito*.
**Topics**
+ [Creación de fuentes de Amazon Cognito identidad de Amazon Verified Permissions](cognito-create.md)
+ [Edición de fuentes de Amazon Cognito identidad de Amazon Verified Permissions](cognito-edit.md)
+ [Asignación de Amazon Cognito tokens al esquema](cognito-map-token-to-schema.md)
+ [Validación de clientes y audiencias para Amazon Cognito](cognito-validation.md)
# Creación de fuentes de Amazon Cognito identidad de Amazon Verified Permissions
El siguiente procedimiento agrega una fuente de identidad a un almacén de políticas existente.
También puede crear una fuente de identidad al [crear un nuevo almacén de políticas](policy-stores-create.md) en la consola de permisos verificados. En este proceso, puede importar automáticamente las notificaciones de los tokens de su fuente de identidad a los atributos de la entidad. Elige la opción **Configuración guiada o Configuración** **con API Gateway un proveedor de identidad**. Estas opciones también crean políticas iniciales.
**nota**
**Las fuentes de identidad** no están disponibles en el panel de navegación de la izquierda hasta que haya creado un almacén de políticas. Las fuentes de identidad que cree están asociadas al almacén de políticas actual.
Puede omitir el tipo de entidad principal al crear una fuente de identidad [create-identity-source](https://docs.aws.amazon.com/cli/latest/reference/verifiedpermissions/create-identity-source.html)en la API de permisos verificados AWS CLI o [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)en ella. Sin embargo, un tipo de entidad en blanco crea una fuente de identidad con un tipo de entidad de`AWS::Cognito`. El nombre de esta entidad no es compatible con el esquema del almacén de políticas. Para integrar Amazon Cognito las identidades en el esquema del almacén de políticas, debe establecer el tipo de entidad principal en una entidad de almacén de políticas compatible.
------
#### [ Consola de administración de AWS ]
**Para crear una fuente de identidad de un grupo de usuarios de Amazon Cognito**
1. Abra la [consola de permisos verificados](https://console.aws.amazon.com/verifiedpermissions/). Elige tu almacén de políticas.
1. En el panel de navegación de la izquierda, elija **Fuentes de identidad**.
1. Seleccione **Crear fuente de identidad**.
1. En **Detalles del grupo de usuarios de Cognito**, seleccione Región de AWS e introduzca el **ID del grupo de usuarios** para su fuente de identidad.
1. En **Configuración principal**, en **Tipo principal**, elija el tipo de entidad para los principales de esta fuente. Las identidades de los grupos de usuarios de Amazon Cognito conectados se asignarán al tipo de entidad principal seleccionado.
1. En **Configuración de grupo**, seleccione **Usar el grupo de Cognito** si quiere mapear la notificación del grupo `cognito:groups` de usuarios. Elija un tipo de entidad que sea principal del tipo principal.
1. En **Validación de la aplicación del cliente**, elija si desea validar la aplicación del cliente IDs.
+ Para validar la aplicación cliente IDs, elija **Aceptar solo los tokens con una aplicación cliente coincidente IDs**. Elija **Agregar nuevo ID de aplicación cliente** para cada ID de aplicación cliente que desee validar. Para eliminar un ID de aplicación cliente que se haya agregado, elija **Eliminar** junto al ID de la aplicación cliente.
+ Seleccione **No validar la aplicación cliente IDs** si no desea validar la aplicación cliente IDs.
1. Seleccione **Crear fuente de identidad**.
1. (Opcional) Si su almacén de políticas tiene un esquema, antes de poder hacer referencia a los atributos que extrae de los tokens de identidad o de acceso en sus políticas de Cedar, debe actualizar su esquema para que Cedar conozca el tipo de principal que crea su fuente de identidad. Esta incorporación al esquema debe incluir los atributos a los que desee hacer referencia en sus políticas de Cedar. Para obtener más información sobre cómo asignar los atributos de los Amazon Cognito tokens a los atributos principales de Cedar, consulte[Asignación de Amazon Cognito tokens al esquema](cognito-map-token-to-schema.md).
**nota**
Al crear un [almacén de políticas vinculado a una API](policy-stores-api-userpool.md) o utilizar **Configurar con API Gateway un proveedor de identidades** al crear almacenes de políticas, Verified Permissions consulta los atributos de usuario del grupo de usuarios y crea un esquema en el que el tipo principal se rellena con los atributos del grupo de usuarios.
1. Cree políticas que utilicen la información de los tokens para tomar decisiones de autorización. Para obtener más información, consulte [Creación de políticas estáticas de Amazon Verified Permissions](policies-create.md).
Ahora que ha creado una fuente de identidad, actualizado el esquema y creado políticas, utilice Verified Permissions `IsAuthorizedWithToken` para tomar decisiones de autorización. Para obtener más información, consulta la *guía [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)de referencia de la API de permisos verificados de Amazon*.
------
#### [ AWS CLI ]
**Para crear una fuente de identidad de un grupo de usuarios de Amazon Cognito**
Puede crear una fuente de identidad mediante la [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)operación. El siguiente ejemplo crea una fuente de identidad que puede acceder a las identidades autenticadas de un grupo de Amazon Cognito usuarios.
1. Cree un `config.txt` archivo que contenga los siguientes detalles del grupo de Amazon Cognito usuarios para que los utilice el `--configuration` parámetro del `create-identity-source` comando.
```
{
"cognitoUserPoolConfiguration": {
"userPoolArn": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_1a2b3c4d5",
"clientIds":["a1b2c3d4e5f6g7h8i9j0kalbmc"],
"groupConfiguration": {
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. Ejecute el siguiente comando para crear una fuente de Amazon Cognito identidad.
```
$ aws verifiedpermissions create-identity-source \
--configuration file://config.txt \
--principal-entity-type "User" \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
1. (Opcional) Si su almacén de políticas tiene un esquema, antes de poder hacer referencia a los atributos que extrae de los tokens de identidad o acceso en sus políticas de Cedar, debe actualizar su esquema para que Cedar sepa el tipo de principal que crea su fuente de identidad. Esta incorporación al esquema debe incluir los atributos a los que desee hacer referencia en sus políticas de Cedar. Para obtener más información sobre cómo asignar los atributos de los Amazon Cognito tokens a los atributos principales de Cedar, consulte[Asignación de Amazon Cognito tokens al esquema](cognito-map-token-to-schema.md).
**nota**
Al crear un [almacén de políticas vinculado a una API](policy-stores-api-userpool.md) o utilizar **Configurar con API Gateway un proveedor de identidades** al crear almacenes de políticas, Verified Permissions consulta los atributos de usuario del grupo de usuarios y crea un esquema en el que el tipo principal se rellena con los atributos del grupo de usuarios.
1. Cree políticas que utilicen la información de los tokens para tomar decisiones de autorización. Para obtener más información, consulte [Creación de políticas estáticas de Amazon Verified Permissions](policies-create.md).
Ahora que ha creado una fuente de identidad, actualizado el esquema y creado políticas, utilice Verified Permissions `IsAuthorizedWithToken` para tomar decisiones de autorización. Para obtener más información, consulta la *guía [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)de referencia de la API de permisos verificados de Amazon*.
------
Para obtener más información sobre el uso de los tokens de acceso e identidad de Amazon Cognito para los usuarios autenticados en Verified Permissions, consulte [Autorización con Amazon Verified Permissions](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) en la *Guía para desarrolladores de Amazon Cognito*.
# Edición de fuentes de Amazon Cognito identidad de Amazon Verified Permissions
Puede editar algunos parámetros de su fuente de identidad después de crearla. No puedes cambiar el tipo de fuente de identidad, tienes que eliminarla y crear una nueva para cambiarla a OIDC o Amazon Cognito a OIDC. Amazon Cognito Si el esquema del almacén de políticas coincide con los atributos de la fuente de identidad, tenga en cuenta que debe actualizar el esquema por separado para reflejar los cambios que realice en la fuente de identidad.
------
#### [ Consola de administración de AWS ]
**Para actualizar una fuente Amazon Cognito de identidad**
1. Abra la [consola de permisos verificados](https://console.aws.amazon.com/verifiedpermissions/). Elige tu almacén de políticas.
1. En el panel de navegación de la izquierda, elija **Fuentes de identidad**.
1. Seleccione el ID de la fuente de identidad que desee editar.
1. Elija **Edit (Edición de)**.
1. En **Detalles del grupo de usuarios de Cognito**, seleccione Región de AWS y escriba el **ID del grupo de usuarios** para su fuente de identidad.
1. En **Detalles principales**, puede actualizar el **tipo principal de** la fuente de identidad. Las identidades de los grupos de usuarios de Amazon Cognito conectados se asignarán al tipo de entidad principal seleccionado.
1. En **Configuración de grupo**, seleccione **Usar grupos de Cognito** si quiere mapear la notificación del grupo `cognito:groups` de usuarios. Elija un tipo de entidad que sea principal del tipo principal.
1. En **Validación de la aplicación del cliente**, elija si desea validar la aplicación del cliente IDs.
+ Para validar la aplicación cliente IDs, elija **Aceptar solo los tokens con una aplicación cliente coincidente IDs**. Elija **Agregar nuevo ID de aplicación cliente** para cada ID de aplicación cliente que desee validar. Para eliminar un ID de aplicación cliente que se haya agregado, elija **Eliminar** junto al ID de la aplicación cliente.
+ Seleccione **No validar la aplicación cliente IDs** si no desea validar la aplicación cliente IDs.
1. Seleccione **Save changes (Guardar cambios)**.
1. Si ha cambiado el tipo de entidad principal de la fuente de identidad, debe actualizar el esquema para que refleje correctamente el tipo de entidad principal actualizado.
Para eliminar una fuente de identidad, pulse el botón de opción situado junto a una fuente de identidad y, a continuación, elija **Eliminar fuente de identidad**. Escriba `delete` en el cuadro de texto y, a continuación, seleccione **Eliminar fuente de identidad** para confirmar la eliminación de la fuente de identidad.
------
#### [ AWS CLI ]
**Para actualizar una fuente Amazon Cognito de identidad**
Puede actualizar una fuente de identidad mediante la [UpdateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_UpdateIdentitySource.html)operación. En el siguiente ejemplo, se actualiza la fuente de identidad especificada para que utilice un grupo Amazon Cognito de usuarios diferente.
1. Cree un `config.txt` archivo que contenga los siguientes detalles del grupo de Amazon Cognito usuarios para que los utilice el `--configuration` parámetro del `update-identity-source` comando.
```
{
"cognitoUserPoolConfiguration": {
"userPoolArn": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_1a2b3c4d5",
"clientIds":["a1b2c3d4e5f6g7h8i9j0kalbmc"],
"groupConfiguration": {
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. Ejecute el siguiente comando para actualizar una fuente de Amazon Cognito identidad.
```
$ aws verifiedpermissions update-identity-source \
--update-configuration file://config.txt \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
**nota**
Si cambia el tipo de entidad principal de la fuente de identidad, debe actualizar el esquema para que refleje correctamente el tipo de entidad principal actualizado.
------
# Asignación de Amazon Cognito tokens al esquema
Es posible que desee añadir una fuente de identidad a un almacén de políticas y asignar las reclamaciones de los proveedores, o símbolos, a su esquema de almacén de políticas. Puede automatizar este proceso mediante la [configuración guiada](policy-stores-create.md) para crear su almacén de políticas con una fuente de identidad o actualizar el esquema manualmente una vez creado el almacén de políticas. Una vez que haya asignado los tokens al esquema, puede crear políticas que hagan referencia a ellos.
Esta sección de la guía del usuario contiene la siguiente información:
+ Cuándo puede rellenar automáticamente los atributos de un esquema de almacén de políticas
+ ¿Cómo utilizar las notificaciones Amazon Cognito simbólicas en tus políticas de permisos verificados
+ ¿Cómo crear manualmente un esquema para una fuente de identidad
Los [almacenes de políticas vinculados a la API](policy-stores-api-userpool.md) y los almacenes de políticas con una fuente de identidad que se crearon mediante una [configuración guiada](policy-stores-create.md) no requieren la asignación manual de los atributos del token de identidad (ID) al esquema. Puede proporcionar permisos verificados con los atributos de su grupo de usuarios y crear un esquema que se complete con los atributos de los usuarios. En la autorización del token de identificación, Verified Permissions asigna las reclamaciones a los atributos de una entidad principal. Es posible que tengas que asignar manualmente Amazon Cognito los tokens a tu esquema en las siguientes condiciones:
+ Ha creado un almacén de políticas o un almacén de políticas vacío a partir de una muestra.
+ Desea extender el uso de los tokens de acceso más allá del control de acceso basado en roles (RBAC).
+ Los almacenes de políticas se crean con la API REST de permisos verificados, un AWS SDK o el. AWS CDK
Para Amazon Cognito utilizarlos como fuente de identidad en su almacén de políticas de permisos verificados, debe tener atributos de proveedor en su esquema. El esquema es fijo y debe corresponder a las entidades que crean los tokens del proveedor [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. Si ha creado su almacén de políticas de forma que rellene automáticamente su esquema a partir de la información del proveedor en un token de identificación, está listo para escribir políticas. Si crea un almacén de políticas sin un esquema para su fuente de identidad, debe agregar atributos de proveedor al esquema que coincidan con las entidades creadas mediante las solicitudes de API. A continuación, puede escribir políticas utilizando los atributos del token del proveedor.
Para obtener más información sobre el uso del ID de Amazon Cognito y los tokens de acceso para los usuarios autenticados en los permisos verificados, consulte Autorización [con permisos verificados de Amazon](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) en la Guía para desarrolladores de *Amazon* Cognito.
**Topics**
+ [Asignación de los tokens de identificación al esquema](#cognito-map-id-token)
+ [Asignar tokens de acceso](#cognito-map-access-token)
+ [Notación alternativa para las reclamaciones Amazon Cognito delimitadas por dos puntos](#cognito-colon-claims)
+ [Lo que debe saber sobre el mapeo de esquemas](#cognito-map-token-to-schema-things-to-know)
## Asignación de los tokens de identificación al esquema
Verified Permissions procesa las reclamaciones de los tokens de identificación como atributos del usuario: sus nombres y cargos, su pertenencia a un grupo y su información de contacto. Los identificadores son especialmente útiles en un modelo de autorización de *control de acceso basado en atributos* (ABAC). Si quieres que los permisos verificados analicen el acceso a los recursos en función de quién realiza la solicitud, elige los tokens de identificación como fuente de identidad.
Amazon Cognito Los tokens de identificación funcionan con la mayoría de las bibliotecas [de terceros dependientes del OIDC.](https://openid.net/developers/certified-openid-connect-implementations/) Amplían las características del OIDC con afirmaciones adicionales. La aplicación puede autenticar al usuario con las operaciones de la API de autenticación de los grupos de usuarios de Amazon Cognito o con la interfaz de usuario alojada en el grupo de usuarios. *Para obtener más información, consulte [Uso de la API y los puntos de enlace](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pools-API-operations.html) en la Amazon Cognito Guía para desarrolladores.*Afirmaciones útiles en los Amazon Cognito identificadores
*`cognito:username` y `preferred_username`*
Variantes del nombre de usuario del usuario.
*`sub`*
El identificador de usuario único (UUID) del usuario
*Reclamaciones con prefijo `custom:`*
Un prefijo para los atributos personalizados del grupo de usuarios, como. `custom:employmentStoreCode`
*Notificaciones estándar*
El OIDC estándar afirma como y. `email` `phone_number` Para obtener más información, consulte [las afirmaciones estándar](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) de *OpenID Connect Core 1.0 que incorporan el conjunto de erratas 2*.
*`cognito:groups`*
Pertenencias a grupos de un usuario. En un modelo de autorización basado en el control de acceso basado en funciones (RBAC), esta afirmación presenta las funciones que puede evaluar en sus políticas.
*Reclamaciones transitorias*
Reclamaciones que no son propiedad del usuario, pero que se agregan en tiempo de ejecución mediante un disparador [Lambda previo a la generación del token](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html). Las afirmaciones transitorias se parecen a las afirmaciones estándar, pero están fuera de la norma, por ejemplo`tenant`, o. `department`
En las políticas que hacen referencia a Amazon Cognito atributos que tienen un `:` separador, haga referencia a los atributos en el formato`principal["cognito:username"]`. La afirmación de los roles `cognito:groups` es una excepción a esta regla. Verified Permissions asigna el contenido de esta declaración a las entidades principales de la entidad de usuario.
Para obtener más información sobre la estructura de los tokens de ID de los grupos de usuarios de Amazon Cognito, consulte [Uso del token de ID](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html) en la Guía para *Amazon Cognito desarrolladores*.
El siguiente ejemplo de token de identificación tiene cada uno de los cuatro tipos de atributos. Incluye la afirmación Amazon Cognito específica`cognito:username`, la notificación personalizada`custom:employmentStoreCode`, la afirmación estándar y la reclamación `email` transitoria. `tenant`
```
{
"sub": "91eb4550-XXX",
"cognito:groups": [
"Store-Owner-Role",
"Customer"
],
"email_verified": true,
"clearance": "confidential",
"iss": "https://cognito-idp.us-east-2.amazonaws.com/us-east-2_EXAMPLE",
"cognito:username": "alice",
"custom:employmentStoreCode": "petstore-dallas",
"origin_jti": "5b9f50a3-05da-454a-8b99-b79c2349de77",
"aud": "1example23456789",
"event_id": "0ed5ad5c-7182-4ecf-XXX",
"token_use": "id",
"auth_time": 1687885407,
"department": "engineering",
"exp": 1687889006,
"iat": 1687885407,
"tenant": "x11app-tenant-1",
"jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN1111111",
"email": "alice@example.com"
}
```
Al crear una fuente de identidad con el grupo de Amazon Cognito usuarios, se especifica el tipo de entidad principal con la que Verified Permissions genera las solicitudes de autorización. `IsAuthorizedWithToken` Después, sus políticas pueden probar los atributos de esa entidad principal como parte de la evaluación de esa solicitud. Su esquema define el tipo y los atributos principales de una fuente de identidad y, a continuación, puede hacer referencia a ellos en sus políticas de Cedar.
También especifica el tipo de entidad de grupo que desea obtener de la afirmación del grupo de fichas de identificación. En las solicitudes de autorización, Verified Permissions asigna cada miembro de la reclamación del grupo a ese tipo de entidad de grupo. En las políticas, puede hacer referencia a esa entidad del grupo como principal.
El siguiente ejemplo muestra cómo reflejar los atributos del token de identidad de ejemplo en su esquema de Verified Permissions. Para obtener más información sobre cómo editar el esquema, consulte [Edición de esquemas de almacenes de políticas](schema-edit.md). Si la configuración de su fuente de identidad especifica el tipo de entidad principal `User`, puede incluir algo similar al siguiente ejemplo para que esos atributos estén disponibles para Cedar.
```
"User": {
"shape": {
"type": "Record",
"attributes": {
"cognito:username": {
"type": "String",
"required": false
},
"custom:employmentStoreCode": {
"type": "String",
"required": false
},
"email": {
"type": "String"
},
"tenant": {
"type": "String",
"required": true
}
}
}
}
```
Para ver un ejemplo de política que se validará con este esquema, consulte[Refleja los atributos Amazon Cognito del token de ID](policies-examples.md#policies-examples-cognito-id).
## Asignar tokens de acceso
Verified Permissions procesa las notificaciones de token de acceso distintas de las declaradas por el grupo como atributos de la acción o atributos de *contexto*. Además de la pertenencia a un grupo, los tokens de acceso de su IdP pueden contener información sobre el acceso a la API. Los tokens de acceso son útiles en los modelos de autorización que utilizan el control de acceso basado en roles (RBAC). Los modelos de autorización que se basan en declaraciones de token de acceso distintas de la pertenencia a un grupo requieren un esfuerzo adicional en la configuración del esquema.
Amazon Cognito Los tokens de acceso tienen afirmaciones que se pueden utilizar para la autorización:Afirmaciones útiles en los tokens de Amazon Cognito acceso
*`client_id`*
El ID de la aplicación cliente de una parte que confía en el OIDC. Con el ID de cliente, Verified Permissions puede comprobar que la solicitud de autorización proviene de un cliente autorizado para el almacén de políticas. En la autorización machine-to-machine (M2M), el sistema solicitante autoriza una solicitud con un secreto de cliente y proporciona el identificador del cliente y los alcances como prueba de la autorización.
*`scope`*
Los [ámbitos OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) que representan los permisos de acceso del portador del token.
*`cognito:groups`*
Pertenencias a grupos de un usuario. En un modelo de autorización basado en el control de acceso basado en funciones (RBAC), esta afirmación presenta las funciones que puede evaluar en sus políticas.
*Reclamaciones transitorias*
Reclamaciones que no son un permiso de acceso, pero que se añaden en tiempo de ejecución mediante un disparador [Lambda previo a la generación del token](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html) de un grupo de usuarios. Las afirmaciones transitorias se parecen a las afirmaciones estándar, pero están fuera del estándar, por ejemplo`tenant`, o. `department` La personalización de los tokens de acceso añade un coste a tu AWS factura.
Para obtener más información sobre la estructura de los tokens de acceso de los grupos de usuarios de Amazon Cognito, consulte [Uso del token de acceso](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html) en la Guía para *Amazon Cognito desarrolladores*.
Un token de Amazon Cognito acceso se asigna a un objeto de contexto cuando se transfiere a Verified Permissions. Se puede hacer referencia a los atributos del token de acceso mediante `context.token.attribute_name`. El siguiente ejemplo de token de acceso incluye tanto el `client_id` como las notificaciones de `scope`.
```
{
"sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e",
"cognito:groups": [
"Store-Owner-Role",
"Customer"
],
"iss": "https://cognito-idp.us-east-2.amazonaws.com/us-east-2_EXAMPLE",
"client_id": "1example23456789",
"origin_jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN1111111",
"event_id": "bda909cb-3e29-4bb8-83e3-ce6808f49011",
"token_use": "access",
"scope": "MyAPI/mydata.write",
"auth_time": 1688092966,
"exp": 1688096566,
"iat": 1688092966,
"jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN2222222",
"username": "alice"
}
```
El siguiente ejemplo muestra cómo reflejar los atributos del token de acceso de ejemplo en su esquema de Verified Permissions. Para obtener más información sobre cómo editar el esquema, consulte [Edición de esquemas de almacenes de políticas](schema-edit.md).
```
{
"MyApplication": {
"actions": {
"Read": {
"appliesTo": {
"context": {
"type": "ReusedContext"
},
"resourceTypes": [
"Application"
],
"principalTypes": [
"User"
]
}
}
},
...
...
"commonTypes": {
"ReusedContext": {
"attributes": {
"token": {
"type": "Record",
"attributes": {
"scope": {
"type": "Set",
"element": {
"type": "String"
}
},
"client_id": {
"type": "String"
}
}
}
},
"type": "Record"
}
}
}
}
```
Para ver un ejemplo de política que se validará con este esquema, consulte[Refleja los atributos del token de Amazon Cognito acceso](policies-examples.md#policies-examples-cognito-access).
## Notación alternativa para las reclamaciones Amazon Cognito delimitadas por dos puntos
En el momento en que se lanzó Verified Permissions, el esquema recomendado para los símbolos establecía como, Amazon Cognito por ejemplo, estas cadenas delimitadas por puntos `cognito:groups` y las `custom:store` convertía para utilizar el `.` carácter como delimitador jerárquico. *Este formato se denomina notación de puntos.* Por ejemplo, una referencia a lo que `cognito:groups` pasó a figurar `principal.cognito.groups` en sus políticas. Aunque puede seguir utilizando este formato, le recomendamos que cree su esquema y sus políticas con una [notación entre corchetes](#cognito-map-token-to-schema-things-to-know). En este formato, una referencia `cognito:groups` se convierte `principal["cognito:groups"]` en una referencia en sus políticas. Los esquemas generados automáticamente para los identificadores de los grupos de usuarios desde la consola de permisos verificados utilizan la notación entre corchetes.
Puede seguir utilizando la notación de puntos en los esquemas y políticas creados manualmente para las fuentes de identidad. Amazon Cognito No puede utilizar la notación de puntos `:` ni ningún otro carácter no alfanumérico en el esquema o las políticas de ningún otro tipo de IdP de OIDC.
Un esquema de notación de puntos anida cada instancia de un `:` carácter como elemento secundario de la frase `cognito` o frase `custom` inicial, como se muestra en el siguiente ejemplo:
```
"CognitoUser": {
"shape": {
"type": "Record",
"attributes": {
"cognito": {
"type": "Record",
"required": true,
"attributes": {
"username": {
"type": "String",
"required": true
}
}
},
"custom": {
"type": "Record",
"required": true,
"attributes": {
"employmentStoreCode": {
"type": "String",
"required": true
}
}
},
"email": {
"type": "String"
},
"tenant": {
"type": "String",
"required": true
}
}
}
}
```
Para ver un ejemplo de política que se validará con este esquema y utilizará la notación de puntos, consulte[Utiliza la notación de puntos para hacer referencia a los atributos](policies-examples.md#policies-examples-dot).
## Lo que debe saber sobre el mapeo de esquemas
**El mapeo de atributos difiere entre los tipos de token**
En la autorización del token de acceso, Verified Permissions asigna las reclamaciones al [contexto](context.md). En la autorización del token de identificación, Verified Permissions asigna las reclamaciones a los atributos principales. En el caso de los almacenes de políticas que cree en la consola de permisos verificados, solo los almacenes de políticas **vacíos** y de **ejemplo** no tienen una fuente de identidad y requieren que complete el esquema con los atributos del grupo de usuarios para la autorización del token de identificación. La autorización de los tokens de acceso se basa en el control de acceso basado en roles (RBAC) con las solicitudes de pertenencia a grupos y no asigna automáticamente otras solicitudes al esquema del almacén de políticas.
**Los atributos de la fuente de identidad no son obligatorios**
Al crear una fuente de identidad en la consola de permisos verificados, no se marca ningún atributo como obligatorio. Esto evita que las reclamaciones incumplidas provoquen errores de validación en las solicitudes de autorización. Puede establecer los atributos como obligatorios según sea necesario, pero deben estar presentes en todas las solicitudes de autorización.
**El RBAC no requiere atributos en el esquema**
Los esquemas de las fuentes de identidad dependen de las asociaciones de entidades que realice al agregar la fuente de identidad. Una fuente de identidad asigna una reclamación a un tipo de entidad de usuario y otra a un tipo de entidad de grupo. Estas asignaciones de entidades son el núcleo de una configuración de fuente de identidad. Con esta información mínima, puede escribir políticas que realicen acciones de autorización para usuarios específicos y grupos específicos de los que los usuarios puedan ser miembros, en un modelo de control de acceso basado en roles (RBAC). La adición de notificaciones de token al esquema amplía el ámbito de autorización del almacén de políticas. Los atributos de usuario de los tokens de identificación contienen información sobre los usuarios que puede contribuir a la autorización del control de acceso basado en atributos (ABAC). Los atributos de contexto de los tokens de acceso tienen información similar a los ámbitos OAuth 2.0 que pueden aportar información adicional sobre el control de acceso por parte del proveedor, pero requieren modificaciones adicionales en el esquema.
Las opciones **Configurar con API Gateway y un proveedor de identidades** y **Configuración guiada** de la consola de permisos verificados asignan reclamos de token de ID al esquema. Este no es el caso de las solicitudes de token de acceso. [Para añadir notificaciones de token de acceso no grupales a tu esquema, debes editarlo en modo JSON y añadir los atributos commonTypes.](https://docs.cedarpolicy.com/schema/json-schema.html#schema-commonTypes) Para obtener más información, consulte [Asignar tokens de acceso](#cognito-map-access-token).
**Elige un tipo de token**
La forma en que el almacén de políticas trabaja con la fuente de identidad depende de una decisión clave en la configuración de la fuente de identidad: si va a procesar los tokens de identificación o de acceso. Con un proveedor de Amazon Cognito identidades, puede elegir el tipo de token al crear un almacén de políticas vinculado a una API. Al crear un [almacén de políticas vinculado a una API](policy-stores-api-userpool.md), debe elegir si desea configurar la autorización para los tokens de ID o de acceso. Esta información afecta a los atributos del esquema que Verified Permissions aplica a su almacén de políticas y a la sintaxis del autorizador Lambda para su API. API Gateway Especialmente si desea beneficiarse de la asignación automática de las solicitudes de token de identificación a los atributos de la consola de permisos verificados, decida con antelación qué tipo de token quiere procesar antes de crear su fuente de identidad. Cambiar el tipo de token requiere un esfuerzo considerable para refactorizar las políticas y el esquema. En los siguientes temas se describe el uso de los identificadores de acceso y de identificación en los almacenes de pólizas.
**El analizador Cedar requiere corchetes para algunos caracteres**
Las políticas suelen hacer referencia a los atributos del esquema en un formato como`principal.username`. En el caso de la mayoría de los caracteres no alfanuméricos`:`, como`.`, o `/` que puedan aparecer en los nombres de las notificaciones de los tokens, Verified Permissions no puede analizar un valor de condición como `principal.cognito:username` o. `context.ip-address` En su lugar, debe formatear estas condiciones con una notación entre corchetes en el formato `principal["cognito:username"]` o`context["ip-address"]`, respectivamente. El carácter de subrayado `_` es un carácter válido en los nombres de las reclamaciones y es la única excepción no alfanumérica a este requisito.
Un ejemplo parcial de un esquema de un atributo principal de este tipo es el siguiente:
```
"User": {
"shape": {
"type": "Record",
"attributes": {
"cognito:username": {
"type": "String",
"required": true
},
"custom:employmentStoreCode": {
"type": "String",
"required": true,
},
"email": {
"type": "String",
"required": false
}
}
}
}
```
Un ejemplo parcial de un esquema de un atributo de contexto de este tipo tiene el siguiente aspecto:
```
"GetOrder": {
"memberOf": [],
"appliesTo": {
"resourceTypes": [
"Order"
],
"context": {
"type": "Record",
"attributes": {
"ip-address": {
"required": false,
"type": "String"
}
}
},
"principalTypes": [
"User"
]
}
}
```
Para ver un ejemplo de política que se validará con este esquema, consulte[Utiliza la notación entre corchetes para hacer referencia a los atributos del token](policies-examples.md#policies-examples-brackets).
# Validación de clientes y audiencias para Amazon Cognito
Al añadir una fuente de identidad a un almacén de políticas, Verified Permissions tiene opciones de configuración que comprueban que los identificadores de identidad y de acceso se utilizan según lo previsto. Esta validación se lleva a cabo durante el procesamiento de las solicitudes de `BatchIsAuthorizedWithToken` API `IsAuthorizedWithToken` y las solicitudes de API. El comportamiento difiere entre los identificadores y los identificadores de acceso Amazon Cognito y entre las fuentes de identidad del OIDC. Con los proveedores de grupos de usuarios de Amazon Cognito, Verified Permissions puede validar el ID de cliente tanto en el identificador como en el token de acceso. Con los proveedores de OIDC, Verified Permissions puede validar el ID del cliente en los tokens de ID y la audiencia en los tokens de acceso.
Un *ID de cliente* es un identificador asociado a la instancia del proveedor de identidad que utiliza tu aplicación, por ejemplo. `1example23456789` Una *audiencia* es una ruta URL asociada a la *parte de confianza* prevista, o al destino, del token de acceso, por ejemplo`https://mytoken.example.com`. Cuando se utilizan los tokens de acceso, la `aud` afirmación siempre se asocia a la audiencia.
Amazon Cognito Los identificadores tienen una `aud` declaración que contiene el ID del [cliente de la aplicación](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html). Los tokens de acceso tienen una `client_id` declaración que también contiene el ID de cliente de la aplicación.
Cuando ingresas uno o más valores para la **validación de la aplicación cliente** en tu fuente de identidad, Verified Permissions compara esta lista de clientes IDs de aplicaciones con la afirmación del token de ID o la `aud` afirmación del token `client_id` de acceso. Verified Permissions no valida la URL del público de una parte que depende para Amazon Cognito las fuentes de identidad.
## Autorización por parte del cliente para JWTs
Es posible que desee procesar los tokens web JSON en su aplicación y transferir sus solicitudes a Verified Permissions sin utilizar una fuente de identidad del almacén de políticas. Puedes extraer los atributos de tu entidad de un token web JSON (JWT) y analizarlos para convertirlos en permisos verificados.
En este ejemplo, se muestra cómo se pueden invocar permisos verificados desde una aplicación mediante un JWT.¹
```
async function authorizeUsingJwtToken(jwtToken) {
const payload = await verifier.verify(jwtToken);
let principalEntity = {
entityType: "PhotoFlash::User", // the application needs to fill in the relevant user type
entityId: payload["sub"], // the application need to use the claim that represents the user-id
};
let resourceEntity = {
entityType: "PhotoFlash::Photo", //the application needs to fill in the relevant resource type
entityId: "jane_photo_123.jpg", // the application needs to fill in the relevant resource id
};
let action = {
actionType: "PhotoFlash::Action", //the application needs to fill in the relevant action id
actionId: "GetPhoto", //the application needs to fill in the relevant action type
};
let entities = {
entityList: [],
};
entities.entityList.push(...getUserEntitiesFromToken(payload));
let policyStoreId = "PSEXAMPLEabcdefg111111"; // set your own policy store id
const authResult = await client
.isAuthorized({
policyStoreId: policyStoreId,
principal: principalEntity,
resource: resourceEntity,
action: action,
entities,
})
.promise();
return authResult;
}
function getUserEntitiesFromToken(payload) {
let attributes = {};
let claimsNotPassedInEntities = ['aud', 'sub', 'exp', 'jti', 'iss'];
Object.entries(payload).forEach(([key, value]) => {
if (claimsNotPassedInEntities.includes(key)) {
return;
}
if (Array.isArray(value)) {
var attibuteItem = [];
value.forEach((item) => {
attibuteItem.push({
string: item,
});
});
attributes[key] = {
set: attibuteItem,
};
} else if (typeof value === 'string') {
attributes[key] = {
string: value,
}
} else if (typeof value === 'bigint' || typeof value ==='number') {
attributes[key] = {
long: value,
}
} else if (typeof value === 'boolean') {
attributes[key] = {
boolean: value,
}
}
});
let entityItem = {
attributes: attributes,
identifier: {
entityType: "PhotoFlash::User",
entityId: payload["sub"], // the application needs to use the claim that represents the user-id
}
};
return [entityItem];
}
```
¹ En este ejemplo de código se utiliza la [aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify)biblioteca para verificar JWTs si están firmados por un OIDC compatible. IdPs