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 de identidad en esquemas y políticas
Es posible que desee añadir una fuente de identidad a un almacén de políticas y las reclamaciones del proveedor de mapas a su esquema de almacén de políticas. Puedes automatizar este proceso o actualizar el esquema manualmente. 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 de token de Amazon Cognito y OIDC en sus 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 y los almacenes de políticas con una fuente de identidad mediante la configuración guiada 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 o los tokens de OIDC y crear un esquema que se complete con los atributos de usuario. En la autorización de los tokens de identificación, Verified Permissions asigna las reclamaciones a los atributos de una entidad principal. Es posible que tenga que asignar manualmente los tokens de Amazon Cognito a su esquema en las siguientes condiciones:
-
Creó un almacén de políticas o un almacén de políticas en blanco 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 usar Amazon Cognito o un proveedor de identidad (IdP) de OIDC como fuente de identidad en su almacén de políticas de permisos verificados, debe tener atributos de proveedor en su esquema. Si creó 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 los atributos del proveedor al esquema. El esquema debe corresponder a las entidades que crean los tokens del proveedor IsAuthorizedWithTokeno a las solicitudes de la API de BatchIsAuthorizedWithtoken. 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 en la Guía para desarrolladores de Amazon Cognito.
Temas
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. 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 alcances de 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 una fuente de identidad 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 a tu esquema notificaciones de token de acceso que no sean grupales, debes editarlo en modo JSON y añadir los atributos commonTypes.
Los grupos de OIDC afirman que admite varios formatos
Al añadir un proveedor de OIDC, puede elegir el nombre del grupo reclamado en su ID o en los tokens de acceso que desee asignar a la membresía del grupo de un usuario en su almacén de políticas. Los permisos verificados reconocen las solicitudes de los grupos en los siguientes formatos:
-
Cadena sin espacios:
"groups": "MyGroup" -
Lista delimitada por espacios:.
"groups": "MyGroup1 MyGroup2 MyGroup3"Cada cadena es un grupo. -
Lista JSON (delimitada por comas):
"groups": ["MyGroup1", "MyGroup2", "MyGroup3"]
nota
Los permisos verificados interpretan cada cadena de una reclamación de grupo separada por espacios como un grupo independiente. Para interpretar el nombre de un grupo con un carácter de espacio como un grupo único, sustituya o elimine el espacio de la afirmación. Por ejemplo, formatee un grupo denominado My
Group comoMyGroup.
Elija 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 identidades de Amazon Cognito, 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, debe elegir si desea configurar la autorización para los tokens de identificación 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 de Lambda para su API de API Gateway. Con un proveedor de OIDC, debes elegir un tipo de token al añadir la fuente de identidad. Puedes elegir un identificador o un token de acceso, y tu elección no permitirá que el tipo de token no elegido se procese en tu almacén de pólizas. Especialmente si quieres beneficiarte de la asignación automática de las solicitudes de token de identificación a los atributos de la consola de permisos verificados, decide con antelación qué tipo de token quieres procesar antes de crear tu 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 comoprincipal.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:groups o. context.ip-address En su lugar, debe formatear estas condiciones con una notación entre corchetes en el formato principal["cognito:username"] ocontext["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" ] } }
Un ejemplo de política para los atributos que se validarán con este esquema es el siguiente:
permit ( principal in MyCorp::UserGroup::"us-west-2_EXAMPLE|MyUserGroup", action, resource ) when { principal["cognito:username"] == "alice" && principal["custom:employmentStoreCode"] == "petstore-dallas" && principal has email && principal.email == "alice@example.com" && context["ip-address"] like "192.0.2.*" };
Asignación de tokens de ID 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.
Tokens de Amazon Cognito ID
Los tokens de Amazon Cognito ID funcionan con la mayoría de las bibliotecas de partes confiables de OIDC. Amplían las funciones 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 conexión en la Guía para desarrolladores de Amazon Cognito.
Afirmaciones útiles en los tokens de Amazon Cognito ID
cognito:usernameypreferred_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 - Reclamaciones estándar
-
La OIDC estándar afirma como
emaily.phone_numberPara obtener más información, consulte las afirmaciones estándarde 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. 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 los atributos de Amazon Cognito que tienen un : separador, haga referencia a los atributos en el formato. principal[" La afirmación de los roles cognito:username"]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 en la Guía para desarrolladores de Amazon Cognito.
El siguiente ejemplo de token de identificación tiene cada uno de los cuatro tipos de atributos. Incluye la notificación específica de Amazon Cognito cognito:username, la notificación personalizada custom:employmentStoreCode, la notificación estándar email, y la notificación 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" }
Cuando crea una fuente de identidad con su grupo de usuarios de Amazon Cognito, 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 en modo JSON. 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 } } } }
Tras actualizar el esquema para reflejar los atributos de Amazon Cognito, puede crear políticas que hagan referencia a los atributos.
permit ( principal in MyCorp::UserGroup::"us-west-2_EXAMPLE|MyUserGroup", action, resource ) when { principal["cognito:username"] == "alice" && principal["custom:employmentStoreCode"] == "petstore-dallas" && principal.tenant == "x11app-tenant-1" && principal has email && principal.email == "alice@example.com" };
Tokens de ID de OIDC
Trabajar con tokens de ID de un proveedor de OIDC es prácticamente lo mismo que trabajar con tokens de ID de Amazon Cognito. La diferencia está en las afirmaciones. Su IdP puede presentar atributos OIDC estándar
Para obtener más información, consulte Crear almacenes de políticas de Verified Permissions.
El siguiente es un ejemplo de esquema para un almacén de políticas con una fuente de identidad OIDC.
"User": { "shape": { "type": "Record", "attributes": { "email": { "type": "String" }, "email_verified": { "type": "Boolean" }, "name": { "type": "String", "required": true }, "phone_number": { "type": "String" }, "phone_number_verified": { "type": "Boolean" } } } }
La siguiente política se aplica a los miembros de un grupo de su proveedor de OIDC.
permit ( principal in MyCorp::UserGroup::"MyOIDCProvider|MyUserGroup", action, resource ) when { principal.email_verified == true && principal.email == "alice@example.com" && principal.phone_number_verified == true && principal.phone_number like "+1206*" };
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.
Asignar tokens de acceso de Amazon Cognito
Los tokens de acceso de Amazon Cognito tienen notificaciones que se pueden usar en las autorizaciones:
Afirmaciones útiles en los tokens de acceso de Amazon Cognito
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 de OAuth 2.0
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 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.departmentLa 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 en la Guía para desarrolladores de Amazon Cognito.
Un token de acceso de Amazon Cognito 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.. El siguiente ejemplo de token de acceso incluye tanto el attribute_nameclient_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 en modo JSON.
{ "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" } } } }
Tras actualizar el esquema para reflejar los atributos de Amazon Cognito, puede crear políticas que hagan referencia a los atributos.
permit(principal, action in [MyApplication::Action::"Read", MyApplication::Action::"GetStoreInventory"], resource) when { context.token.client_id == "52n97d5afhfiu1c4di1k5m8f60" && context.token.scope.contains("MyAPI/mydata.write") };
Mapeo de los tokens de acceso del OIDC
La mayoría de los tokens de acceso de proveedores de OIDC externos se alinean estrechamente con los tokens de acceso de Amazon Cognito. Un token de acceso OIDC se asigna a un objeto de contexto cuando se pasa a Verified Permissions. Se puede hacer referencia a los atributos del token de acceso mediante context.token.. El siguiente ejemplo de token de acceso OIDC incluye ejemplos de afirmaciones base.attribute_name
{ "sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e", "groups": [ "Store-Owner-Role", "Customer" ], "iss": "https://auth.example.com", "client_id": "1example23456789", "aud": "https://myapplication.example.com" "scope": "MyAPI-Read", "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 en modo JSON.
{ "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" } } } }
Después de actualizar el esquema para reflejar los atributos del IdP, puede crear políticas que hagan referencia a los atributos.
permit( principal, action in [MyApplication::Action::"Read", MyApplication::Action::"GetStoreInventory"], resource ) when { context.token.client_id == "52n97d5afhfiu1c4di1k5m8f60" && context.token.scope.contains("MyAPI-read") };
Notación alternativa para las reclamaciones delimitadas por dos puntos de Amazon Cognito
En el momento en que se lanzó Verified Permissions, el esquema recomendado para el token de Amazon Cognito afirmaba lo mismo cognito:groups y custom:store convertía estas cadenas delimitadas por dos puntos 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. Si bien puede seguir utilizando este formato, le recomendamos que cree su esquema y sus políticas con una notación entre corchetes. 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 de 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 } } } }
Con un esquema en este formato, puede crear una política con notación de puntos, como en el ejemplo siguiente:
permit(principal, action, resource) when { principal.cognito.username == "alice" && principal.custom.employmentStoreCode == "petstore-dallas" && principal.tenant == "x11app-tenant-1" && principal has email && principal.email == "alice@example.com" };
