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.
Asignación de tokens de proveedores de identidad 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 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 usar Amazon Cognito y las reclamaciones de OIDC token en tus políticas de permisos verificados
-
¿Cómo crear manualmente un esquema para una fuente de identidad
APILos almacenes de políticas vinculados y los almacenes de políticas con una fuente de identidad que se crearon mediante una configuración guiada no requieren la asignación manual de los atributos del token de identidad (ID) al esquema. Puedes proporcionar permisos verificados con los atributos de tu grupo de usuarios y crear un esquema que incluya 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 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 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 los permisos verificados REST API AWS SDK, un o el. AWS CDK
Para usar Amazon Cognito o un proveedor de OIDC identidad (IdP) 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 en las que los tokens del proveedor crean IsAuthorizedWithTokeno BatchIsAuthorizedWithTokenAPIsolicitan. 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 API solicitudes. 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
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 tokens de identificación son especialmente útiles en un modelo de autorización de control de acceso (ABAC) basado en atributos. 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 para tu 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 OIDC.
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 del usuario (UUID)
- Reclamaciones con
custom:prefijo -
Un prefijo para los atributos personalizados del grupo de usuarios, como.
custom:employmentStoreCode - Reclamaciones estándar
-
OIDCReclamaciones estándar como
emailyphone_number. Para 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 roles (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 de almacenes de políticas. 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, consulteRefleja los atributos del token de Amazon Cognito ID.
OIDCTokens de identificación
Trabajar con los tokens de ID de un OIDC proveedor es muy parecido a trabajar con los tokens de ID de Amazon Cognito. La diferencia está en las afirmaciones. Su IdP puede presentar OIDCatributos 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 OIDC identidad.
"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" } } } }
Para ver un ejemplo de política que se validará con este esquema, consulteRefleja los atributos OIDC del token de 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 API el acceso. 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 la parte que OIDC confía. 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
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 roles (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 de almacenes de políticas.
{ "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 acceso de Amazon Cognito
Mapeo de OIDC los tokens de acceso
La mayoría de los tokens de acceso de OIDC proveedores externos se alinean estrechamente con los tokens de acceso de Amazon Cognito. Un token de OIDC acceso 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 OIDC acceso incluye ejemplos de notificaciones 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 de almacenes de políticas.
{ "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, consulteRefleja OIDC los atributos del token de acceso.
Notación alternativa para las reclamaciones delimitadas por dos puntos de Amazon Cognito
Cuando 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. Aunque 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 usar 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 OIDC IdP.
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, consulteUtiliza la notación de puntos para hacer referencia a los atributos.
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 un control de acceso basado en roles (RBAC) con 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.
RBACno 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 de su 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 (ABAC) basado en atributos. 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 Configuración con API Gateway y un proveedor de identidad y Configuración guiada de la consola de permisos verificados asignan las notificaciones de los tokens de identificación 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 JSON modo y añadir atributos. commonTypes
OIDCgroup claim admite varios formatos
Al añadir un OIDC proveedor, puede elegir el nombre de la reclamación del grupo en el identificador o en los tokens de acceso que desea asignar a la pertenencia al 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. -
JSONlista (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 API vinculado a él. Al crear un almacén API de políticas vinculado a un servidor, 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 Lambda de su Gateway. API API Con un OIDC proveedor, debe elegir un tipo de token al agregar la fuente de identidad. Puedes elegir un identificador o un token de acceso y, si eliges, no se procesará en tu almacén de políticas el tipo de token no elegido. 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:username 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 es el siguiente:
"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, consulteUtiliza la notación entre corchetes para hacer referencia a los atributos del token.
