Asignación de tokens OIDC 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 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 que se crearon mediante una 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 y crear un esquema que se complete con los atributos de los usuarios. En la autorización de un token de identificación, Verified Permissions asigna las reclamaciones a los atributos de una entidad principal.

Para usar un proveedor de identidades (IdP) de OIDC como fuente de identidad en el 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 IsAuthorizedWithTokeno BatchIsAuthorizedWithTokena las solicitudes de 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.

Asignación de los identificadores 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 para tu fuente de identidad.

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 o tener un esquema personalizado. Al crear un nuevo almacén de políticas en la consola de permisos verificados, puede agregar una fuente de identidad OIDC con un token de ID de ejemplo, o puede asignar manualmente las notificaciones de los tokens a los atributos del usuario. Como Verified Permissions no conoce el esquema de atributos de tu IdP, debes proporcionar esta información.

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"
         }
      }
   }
}

Para ver un ejemplo de política que se validará con este esquema, consulte. Refleja los atributos del token de ID de OIDC

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.

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.attribute_name. El siguiente ejemplo de token de acceso OIDC incluye ejemplos de afirmaciones base.

{
    "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, consulte. Refleja los atributos del token de acceso del OIDC

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 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. Para obtener más información, consulte Asignar tokens de acceso.

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:

1. Cadena sin espacios: "groups": "MyGroup"

2. Lista delimitada por espacios:. "groups": "MyGroup1 MyGroup2 MyGroup3" Cada cadena es un grupo.

3. 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 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: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 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, consulteUtiliza la notación entre corchetes para hacer referencia a los atributos del token.