Trabalhando com fontes de identidade do Amazon Cognito Trabalhando com fontes de identidade do OIDC Validação de clientes e públicos Autorização do lado do cliente para JWTs

Uso do Amazon Verified Permissions com provedores de identidade

Uma fonte de identidade é uma representação de um provedor de identidade externo (IdP) nas Permissões Verificadas da Amazon. As fontes de identidade fornecem informações de um usuário que se autenticou com um IdP que tem uma relação de confiança com seu repositório de políticas. Quando seu aplicativo faz uma solicitação de autorização com um token de uma fonte de identidade, seu repositório de políticas pode tomar decisões de autorização a partir das propriedades do usuário e das permissões de acesso. As fontes de identidade de permissões verificadas melhoram a autorização com uma conexão direta com seu repositório central de identidades e serviço de autenticação.

Você pode usar os provedores de identidade () do OpenID Connect (OIDC) com permissões IdPs verificadas. Seu aplicativo pode gerar solicitações de autorização com identidade (ID) OIDC ou acessar tokens web JSON (JWTs). Com tokens de ID, as Permissões Verificadas lêem IDs de usuários e declarações de atributos como principais para controle de acesso baseado em atributos (ABAC). Com os tokens de acesso, as Permissões Verificadas lêem os IDs dos usuários como principais e outras declarações como contexto. Com os dois tipos de token, você pode mapear uma declaração como groups para um grupo principal e criar políticas que avaliem o controle de acesso baseado em funções (RBAC).

Você pode adicionar um grupo de usuários do Amazon Cognito ou um IdP personalizado do OpenID Connect (OIDC) como sua fonte de identidade.

Tópicos

Trabalhando com fontes de identidade do Amazon Cognito

As permissões verificadas trabalham em estreita colaboração com os grupos de usuários do Amazon Cognito. Os JWTs do Amazon Cognito têm uma estrutura previsível. As permissões verificadas reconhecem essa estrutura e tiram o máximo proveito das informações que ela contém. Por exemplo, você pode implementar um modelo de autorização de controle de acesso baseado em função (RBAC) com tokens de ID ou tokens de acesso.

Uma nova fonte de identidade de grupos de usuários do Amazon Cognito exige as seguintes informações:

Região da AWS A.
O ID do grupo de usuários.
O tipo de entidade do usuário que você deseja associar à sua fonte de identidade, por exemploMyCorp::User.
O tipo de entidade do grupo que você deseja associar à sua fonte de identidade, por exemploMyCorp::UserGroup.
(Opcional) Os IDs de cliente do seu grupo de usuários que você deseja autorizar a fazer solicitações ao seu repositório de políticas.

Como as Permissões Verificadas só funcionam com grupos de usuários do Amazon Cognito nos mesmos Conta da AWS, você não pode especificar uma fonte de identidade em outra conta. As permissões verificadas definem o prefixo da entidade — o identificador da fonte de identidade que você deve referenciar nas políticas que atuam de acordo com os diretores do grupo de usuários — como o ID do seu grupo de usuários, por exemplo. us-west-2_EXAMPLE

As declarações de token do grupo de usuários podem conter atributos, escopos, grupos, IDs de clientes e dados personalizados. Os JWTs do Amazon Cognito têm a capacidade de incluir uma variedade de informações que podem contribuir para as decisões de autorização nas Permissões verificadas. Isso inclui:

Declarações de nome de usuário e grupo com um cognito: prefixo
Atributos de usuário personalizados com um custom: prefix
Declarações personalizadas adicionadas em tempo de execução
Reivindicações padrão do OIDC, como e sub email

Abordamos essas reivindicações em detalhes e como gerenciá-las nas políticas de permissões verificadas, emTrabalhando com fontes de identidade em esquemas e políticas.

Importante

Embora você possa revogar os tokens do Amazon Cognito antes que eles expirem, os JWTs são considerados recursos sem estado independentes, com assinatura e validade. Espera-se que os serviços em conformidade com o JSON Web Token RFC 7519 validem os tokens remotamente e não precisem validá-los com o emissor. Isso significa que o Verified Permissions pode conceder acesso com base em um token revogado ou emitido para o usuário posteriormente excluído. Para mitigar esse risco, recomendamos que você crie seus tokens com o menor período de validade possível e revogue os tokens de atualização quando quiser remover a autorização para continuar a sessão de um usuário.

As políticas do Cedar para fontes de identidade de grupos de usuários em Permissões verificadas usam uma sintaxe especial para nomes de declarações que contêm caracteres diferentes de alfanuméricos e sublinhado (). _ Isso inclui declarações de prefixo do grupo de usuários que contêm um : cognito:username caractere, como e. custom:department Para escrever uma condição de política que faça referência à custom:department reivindicação cognito:username or, escreva-a como principal["cognito:username"] eprincipal["custom:department"], respectivamente.

nota

Se um token contiver uma declaração com um custom: prefixo cognito: or e um nome de solicitação com o valor literal cognito oucustom, uma solicitação de autorização com IsAuthorizedWithTokenfalhará com a. ValidationException

Este exemplo mostra como você pode criar uma política que faça referência a algumas das reivindicações dos grupos de usuários do Amazon Cognito associadas a um 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 obter mais informações sobre o mapeamento de declarações, consulteMapeamento de tokens de ID para o esquema. Para obter mais informações sobre autorização para usuários do Amazon Cognito, consulte Autorização com permissões verificadas da Amazon no Guia do desenvolvedor do Amazon Cognito.

Trabalhando com fontes de identidade do OIDC

Você também pode configurar qualquer IdP compatível do OpenID Connect (OIDC) como fonte de identidade de um repositório de políticas. Os provedores do OIDC são semelhantes aos grupos de usuários do Amazon Cognito: eles produzem JWTs como produto da autenticação. Para adicionar um provedor OIDC, você deve fornecer uma URL do emissor

Uma nova fonte de identidade do OIDC requer as seguintes informações:

O URL do emissor. As permissões verificadas devem ser capazes de descobrir um .well-known/openid-configuration endpoint nesse URL.
O tipo de token que você deseja usar nas solicitações de autorização. Nesse caso, você escolheu o token de identidade.
O tipo de entidade do usuário que você deseja associar à sua fonte de identidade, por exemploMyCorp::User.
O tipo de entidade do grupo que você deseja associar à sua fonte de identidade, por exemploMyCorp::UserGroup.
Um exemplo de token de ID ou uma definição das declarações no token de ID.
O prefixo que você deseja aplicar às IDs de entidade de usuário e grupo. Na CLI e na API, você pode escolher esse prefixo. Nos repositórios de políticas que você cria com o Configurar com o API Gateway e uma fonte de identidade ou a opção Configuração guiada, as Permissões Verificadas atribuem um prefixo do nome do emissor menoshttps://, por exemplo. MyCorp::User::"auth.example.com|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"

A autorização com fontes de identidade do OIDC usa as mesmas operações de API que as fontes de identidade do grupo de usuários: IsAuthorizedWithTokene BatchIs AuthorizedWith o token.

Este exemplo mostra como você pode criar uma política que permita o acesso aos relatórios de fim de ano para funcionários do departamento de contabilidade, que tenham uma classificação confidencial e não estejam em um escritório satélite. As permissões verificadas derivam esses atributos das declarações no token de ID do principal.


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

Validação de clientes e públicos

Quando você adiciona uma fonte de identidade a um repositório de políticas, as Permissões Verificadas têm opções de configuração que verificam se os tokens de ID e acesso estão sendo usados conforme o esperado. Essa validação acontece no processamento IsAuthorizedWithToken e nas solicitações de BatchIsAuthorizedWithToken API. O comportamento difere entre tokens de ID e acesso e entre as fontes de identidade do Amazon Cognito e do OIDC. Com os provedores de grupos de usuários do Amazon Cognito, as Permissões Verificadas podem validar a ID do cliente em tokens de ID e de acesso. Com os provedores do OIDC, as Permissões Verificadas podem validar o ID do cliente em tokens de ID e o público em tokens de acesso.

Um ID de cliente é um identificador associado a um aplicativo OAuth ou OIDC configurado com o provedor, por exemplo. 1example23456789 Um público é um caminho de URL associado à parte confiável ou ao destino pretendido do aplicativo de destino, por exemplohttps://myapplication.example.com. A aud afirmação nem sempre está associada ao público.

O Verified Permissions realiza a validação do público da fonte de identidade e do cliente da seguinte forma:

Autorização do lado do cliente para JWTs

Talvez você queira processar tokens web JSON em seu aplicativo e passar suas reivindicações para Permissões Verificadas sem usar uma fonte de identidade do repositório de políticas. Você pode extrair seus atributos de entidade de um JSON Web Token (JWT) e analisá-los em Permissões verificadas.

Este exemplo mostra como você pode chamar Permissões Verificadas de um IdC IDP.¹


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 === '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 need to use the claim that represents the user-id
    }
  };
  return [entityItem];
}

¹ Esse exemplo de código usa a biblioteca aws-jwt-verify para verificar JWTs assinados por compatíveis com OIDC. IdPs

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Exemplo de políticas vinculadas a modelos para exemplos de armazenamentos de políticas

Criação de origens de identidade