Uso de fuentes de identidad de Amazon Cognito Trabajar con OIDC fuentes de identidad Validación de clientes y audiencias Autorización del lado del cliente para JWTs

Uso de Amazon Verified Permissions con proveedores de identidades

Una fuente de identidad es una representación de un proveedor de identidad externo (IdP) en Amazon Verified Permissions. Las fuentes de identidad proporcionan información de un usuario que se autenticó con un IdP que tiene una relación de confianza con su almacén de políticas. Cuando la aplicación realiza una solicitud de autorización con un token de una fuente de identidad, el almacén de políticas puede tomar decisiones de autorización a partir de las propiedades del usuario y los permisos de acceso. Las fuentes de identidad de Verified Permissions mejoran la autorización con una conexión directa al almacén de identidades central y al servicio de autenticación.

Puede usar proveedores de identidad () de OpenID Connect (OIDCIdPs) con permisos verificados. Su aplicación puede generar solicitudes de autorización con OIDC identidad (ID) o acceder a tokens JSON web (JWTs). Con los identificadores de identidad, Verified Permissions lee las declaraciones de los usuarios IDs y las considera fundamentales para el control de acceso basado en atributos (). ABAC Con los tokens de acceso, Verified Permissions interpreta al usuario IDs como principal y el resto de las afirmaciones como contexto. Con ambos tipos de token, puedes asignar una reclamación similar groups a un grupo principal y crear políticas que evalúen el control de acceso basado en roles (). RBAC

Puede añadir un grupo de usuarios de Amazon Cognito o un OIDC IdP de OpenID Connect () personalizado como fuente de identidad.

Temas

Uso de fuentes de identidad de Amazon Cognito

Verified Permissions trabaja en estrecha colaboración con los grupos de usuarios de Amazon Cognito. Amazon Cognito JWTs tiene 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 (RBAC) basado en roles con fichas 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 de usuario que desea asociar a su fuente de identidad, por ejemploMyCorp::User.
El tipo de entidad de grupo que desea asociar a su fuente de identidad, por ejemploMyCorp::UserGroup.
(Opcional) 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

Las notificaciones de los tokens del grupo de usuarios pueden contener atributos, ámbitos, grupos, datos de clientes y personalizados. IDs Amazon Cognito JWTs tiene 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:

Reclamaciones de nombre de usuario y grupo con un prefijo cognito:
Atributos de usuario personalizados con un custom: prefix
Las reclamaciones personalizadas se añaden en tiempo de ejecución
OIDCreclamaciones estándar como sub y email

Tratamos estas reclamaciones en detalle y cómo gestionarlas en las políticas de permisos verificados, enAsignación de tokens de proveedores de identidad al esquema.

importante

Si bien puede revocar los tokens de Amazon Cognito antes de que caduquenJWTs, se consideran recursos apátridas que son autónomos con firma y validez. Se espera que los servicios que cumplen con el JSON Web Token RFC 7519 validen los tokens de forma remota y no están obligados a validarlos con el emisor. Esto significa que Verified Permissions puede conceder acceso en función de un token que se haya revocado o emitido para un usuario que luego se haya eliminado. 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.

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"] yprincipal["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 ocustom, una solicitud de autorización con un prefijo no IsAuthorizedWithTokense aceptará con unValidationException.

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 == ExampleCo::User::"us-east-1_example|4fe90f4a-ref8d9-4033-a750-4c8622d62fb6", 
     action, 
     resource == ExampleCo::Photo::"VacationPhoto94.jpg" 
)
when { 
     principal["cognito:username"]) == "alice" &&
     principal["custom:department"]) == "Finance"
};

Para obtener más información sobre la representación cartográfica de las reclamaciones, consulteAsignación de tokens de ID al esquema. Para obtener más información sobre la autorización de los usuarios de Amazon Cognito, consulte Autorización con permisos verificados de Amazon en la Guía para desarrolladores de Amazon Cognito.

Trabajar con OIDC fuentes de identidad

También puede configurar cualquier OIDC IdP de OpenID Connect () compatible como fuente de identidad de un almacén de políticas. OIDClos proveedores son similares a los grupos de usuarios de Amazon Cognito: se producen JWTs como producto de la autenticación. Para añadir un OIDC proveedor, debe proporcionar un emisor URL

Una nueva fuente de OIDC identidad requiere la siguiente información:

El emisor. URL Los permisos verificados deben poder detectar un .well-known/openid-configuration punto final en este URL punto.
El tipo de token que quieres usar en las solicitudes de autorización. En este caso, ha elegido el token de identidad.
Por ejemplo, el tipo de entidad de usuario que desea asociar a su fuente de identidadMyCorp::User.
El tipo de entidad de grupo que desea asociar a su fuente de identidad, por ejemploMyCorp::UserGroup.
Un ejemplo de token de ID o una definición de las afirmaciones del token de ID.
El prefijo que desea aplicar a la entidad IDs de usuario y grupo. En CLI yAPI, puede elegir este prefijo. En los almacenes de políticas que se crean con la opción Configurar con API Gateway y una fuente de identidad o con la opción de configuración guiada, Verified Permissions asigna un prefijo con el nombre del emisor menoshttps://, por ejemplo. MyCorp::User::"auth.example.com|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"

La autorización con fuentes de OIDC identidad utiliza las mismas API operaciones que las fuentes de identidad del grupo de usuarios: y. IsAuthorizedWithToken BatchIsAuthorizedWithToken

En el siguiente ejemplo, se muestra cómo se puede crear una política que permita el acceso a los informes de fin de año a los empleados del departamento de contabilidad que tengan una clasificación confidencial y no estén en una oficina satélite. Verified Permissions obtiene estos atributos de las afirmaciones que figuran en el token de identificación del director.


permit(
     principal in MyCorp::UserGroup::"MyOIDCProvider|Accounting", 
     action, 
     resource in MyCorp::Folder::"YearEnd2024" 
) when { 
     principal.jobClassification == "Confidential" &&
     !(principal.location like "SatelliteOffice*")
};

Validación de clientes y audiencias

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 produce en el procesamiento de las BatchIsAuthorizedWithToken API solicitudes IsAuthorizedWithToken y en ellas. El comportamiento difiere entre los identificadores y los tokens de acceso, y entre Amazon Cognito y las fuentes de OIDC identidad. 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 OIDC los proveedores, 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 una OIDC aplicación OAuth o aplicación que está configurada con el proveedor, por ejemplo1example23456789. Una audiencia es una URL ruta asociada a la parte de confianza prevista, o al destino, de la aplicación de destino, por ejemplohttps://myapplication.example.com. La aud afirmación no siempre está asociada a la audiencia.

Verified Permissions valida la fuente de identidad, la audiencia y el cliente de la siguiente manera:

Amazon Cognito

Los tokens de Amazon Cognito ID tienen una aud declaración que contiene el ID de cliente de la aplicación. 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. Los permisos verificados no validan la audiencia de una parte de confianza para las fuentes de identidad de Amazon URL Cognito.

OIDC

OIDCLos tokens de identificación tienen una aud declaración que contiene una lista de clientes. IDs Los tokens de acceso tienen una aud declaración que contiene URL la audiencia del token. Los tokens de acceso también tienen una client_id declaración que contiene el ID de cliente deseado.

Puedes introducir uno o más valores para la validación de la audiencia con un OIDC proveedor. Cuando eliges un tipo de token de identificación, Verified Permissions valida el ID del cliente y comprueba que al menos un miembro del cliente IDs de la aud reclamación coincide con un valor de validación de audiencia.

Verified Permissions valida la audiencia para los tokens de acceso y comprueba que la aud afirmación coincide con un valor de validación de audiencia. Este valor del token de acceso proviene principalmente de la aud reclamación, pero puede proceder de la client_id reclamación cid or si no existe ninguna aud reclamación. Consulta con tu IdP el formato y la afirmación de audiencia correctos.

Un ejemplo de valor de validación de audiencia de un token de identificación es1example23456789.

Un ejemplo de valor de validación de la audiencia del token de acceso eshttps://myapplication.example.com.

Autorización del lado del cliente para JWTs

Es posible que desee procesar los tokens JSON web de su aplicación y transferir sus solicitudes a Verified Permissions sin utilizar una fuente de identidad de un almacén de políticas. Puedes extraer los atributos de tu entidad de un token JSON web (JWT) y analizarlos para convertirlos en permisos verificados.

En este ejemplo se muestra cómo se puede llamar a los permisos verificados desde un OIDC ID.¹


async function authorizeUsingJwtToken(jwtToken) {
  
    const payload = await verifier.verify(jwtToken);
   
    var 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
    };
    var 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
    };
    var 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
    };
    var entities = {
        entityList: [],
    };
    entities.entityList.push(...getUserEntitiesFromToken(payload));
    var 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];
}

¹ Este ejemplo de código usa la aws-jwt-verifybiblioteca para verificar JWTs firmados por -compatible. OIDC IdPs

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Ejemplo de políticas vinculadas a plantillas

Crear fuentes de identidad