As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Autorização com o Amazon Verified Permissions

O Amazon Verified Permissions é um serviço de autorização para as aplicações que você cria. Quando você adiciona um grupo de usuários do Amazon Cognito como uma fonte de identidade, a aplicação pode passar tokens de acesso ou identidade (ID) do grupo de usuários para o Verified Permissions tomar uma decisão de permissão ou negação. O Verified Permissions consideram as propriedades do usuário e o contexto da solicitação com base nas políticas que você escreve na linguagem de política Cedar. O contexto da solicitação pode incluir um identificador para o documento, a imagem ou outro recurso solicitado e a ação que o usuário deseja realizar no recurso.

Seu aplicativo pode fornecer a identidade do usuário ou os tokens de acesso às permissões verificadas IsAuthorizedWithTokenou BatchIsAuthorizedWithTokenAPIsolicitações. Essas API operações aceitam seus usuários como usuários Principal e tomam decisões de Action autorização para aqueles Resource que eles desejam acessar. Personalizações adicionais Context podem contribuir para uma decisão de acesso detalhada.

Quando seu aplicativo apresenta um token em uma IsAuthorizedWithToken API solicitação, o Verified Permissions realiza as seguintes validações.

Tokens revogados e usuários excluídos

O Verified Permissions valida somente as informações que ele conhece da fonte de identidade e do prazo de expiração do token do usuário. O Verified Permissions não verifica a revogação do token ou a existência do usuário. Se você revogou o token do usuário ou excluiu o perfil do usuário do grupo de usuários, o Verified Permissions considerará o token válido até que ele expire.

Avaliação de políticas

Configure o grupo de usuários como uma fonte de identidade para o repositório de políticas. Configure a aplicação para enviar os tokens de usuários em solicitações ao Verified Permissions. Para cada solicitação, o Verified Permissions compara as reivindicações no token com uma política. Uma política de permissões verificadas é como uma IAM política em AWS. Ela declara uma entidade principal, um recurso e uma ação. As permissões verificadas respondem à sua solicitação dizendo Allow se ela corresponde a uma ação permitida e não corresponde a uma Deny ação explícita; caso contrário, ela responde com. Deny Para obter mais informações, consulte Políticas do Amazon Verified Permissions no Guia do usuário do Amazon Verified Permissions.

Personalização de tokens

Para alterar, adicionar e remover as declarações de usuário que você deseja apresentar às Permissões verificadas, personalize o conteúdo em seus tokens de acesso e identidade com umAcionador do Lambda antes da geração do token. Com um gatilho de geração de pré-token, é possível adicionar e modificar reivindicações nos tokens. Por exemplo, é possível consultar um banco de dados para obter atributos adicionais do usuário e codificá-los no token de ID.

APIautorização com permissões verificadas

Seu ID ou tokens de acesso podem autorizar solicitações para back-end do API Amazon REST APIs Gateway com permissões verificadas. Você pode criar um repositório de políticas com links imediatos para seu grupo de usuários API e. Com a opção inicial Configurar com Cognito e API Gateway, as Permissões Verificadas adicionam uma fonte de identidade do grupo de usuários ao repositório de políticas e um autorizador Lambda ao. API Quando seu aplicativo passa um token portador do grupo de usuários para oAPI, o autorizador Lambda invoca Permissões verificadas. O autorizador passa o token como principal e o caminho e o método da solicitação como uma ação.

O diagrama a seguir ilustra o fluxo de autorização para um API gateway API com permissões verificadas. Para obter uma análise detalhada, consulte os repositórios API de políticas vinculados no Guia do usuário de permissões verificadas da Amazon.

As permissões verificadas estruturam a API autorização em torno de grupos de grupos de usuários. Como os tokens de ID e acesso incluem uma cognito:groups declaração, seu repositório de políticas pode gerenciar o controle de acesso baseado em funções (RBAC) para você APIs em vários contextos de aplicativos.

Escolhendo as configurações do repositório de políticas

Ao configurar uma fonte de identidade em um repositório de políticas, você deve escolher se deseja processar tokens de acesso ou ID. Essa decisão é importante para a forma como seu mecanismo de políticas opera. Os tokens de ID contêm atributos do usuário. Os tokens de acesso contêm informações de controle de acesso do usuário: OAuth escopos. Embora os dois tipos de token tenham informações de associação ao grupo, geralmente recomendamos o token de acesso RBAC com um repositório de políticas de permissões verificadas. O token de acesso aumenta a associação ao grupo com escopos que podem contribuir para a decisão de autorização. As reivindicações em um token de acesso se tornam contextuais na solicitação de autorização.

Você também deve configurar os tipos de entidade de usuário e grupo ao configurar um grupo de usuários como fonte de identidade. Os tipos de entidade são identificadores principais, de ação e de recursos que você pode consultar nas políticas de permissões verificadas. As entidades nos repositórios de políticas podem ter uma relação de associação, em que uma entidade pode ser membro de uma entidade controladora. Com a associação, você pode referenciar grupos principais, grupos de ação e grupos de recursos. No caso de grupos de grupos de usuários, o tipo de entidade do usuário que você especificar deve ser membro do tipo de entidade do grupo. Quando você configura um repositório API de políticas vinculado ou segue a Configuração guiada no console de Permissões verificadas, seu repositório de políticas tem automaticamente essa relação pai-membro.

O token de ID pode ser combinado RBAC com o controle de acesso baseado em atributos ()ABAC. Depois de criar um repositório API de políticas vinculado, você pode aprimorar suas políticas com atributos de usuário e associação a grupos. As declarações de atributo em um token de ID se tornam atributos principais na solicitação de autorização. Suas políticas podem tomar decisões de autorização com base nos atributos principais.

Você também pode configurar um repositório de políticas para aceitar tokens com uma client_id declaração aud ou que corresponda a uma lista de clientes de aplicativos aceitáveis que você fornece.

Exemplo de política para autorização baseada em funções API

O exemplo de política a seguir foi criado pela configuração de um repositório de políticas de permissões verificadas, por PetStoreexemplo RESTAPI.

permit(
  principal in PetStore::UserGroup::"us-east-1_EXAMPLE|MyGroup",
  action in [ PetStore::Action::"get /pets", PetStore::Action::"get /pets/{petId}" ],
  resource
  );

As permissões verificadas retornam uma Allow decisão à solicitação de autorização do seu aplicativo quando:

Exemplo de política para um usuário do Amazon Cognito

Seu grupo de usuários também pode gerar solicitações de autorização para Permissões Verificadas em condições diferentes das API solicitações. Você pode enviar qualquer decisão de controle de acesso em seu aplicativo ao seu repositório de políticas. Por exemplo, você pode complementar a segurança do Amazon DynamoDB ou do Amazon S3 com controle de acesso baseado em atributos antes que qualquer solicitação transite pela rede, reduzindo o uso da cota.

O exemplo a seguir usa a linguagem de política Cedar para permitir que usuários do setor financeiro que se autenticam com um cliente de aplicação do grupo de usuários leiam e escrevam example_image.png. John, um usuário do seu aplicativo, recebe um token de ID do seu cliente do aplicativo e o passa em uma GET solicitação para um URL que requer autorização,https://example.com/images/example_image.png. O token de ID de John tem uma reivindicação aud do ID de cliente da aplicação do grupo de usuários 1234567890example. A função do Lambda de geração de pré-token também inseriu uma nova reivindicação costCenter com um valor, para John, de Finance1234.

permit (
   principal,
   actions in [ExampleCorp::Action::"readFile", "writeFile"],
   resource == ExampleCorp::Photo::"example_image.png"
)
when {
   principal.aud == "1234567890example" &&
   principal.custom.costCenter like "Finance*"
};

O corpo da solicitação a seguir resulta em uma resposta Allow.

{
   "accesstoken": "[John's ID token]",
   "action": {
      "actionId": "readFile",
      "actionType": "Action"
   },
   "resource": {
      "entityId": "example_image.png",
      "entityType": "Photo"
   }
}

Quando você quiser especificar uma entidade principal em uma política do Verified Permissions, use o seguinte formato:

permit (
   principal == [Namespace]::[Entity]::"[user pool ID]"|"[user sub]",
   action,
   resource
);

A seguir está um exemplo principal para um usuário em um grupo de usuários com ID us-east-1_Example com sub ou ID de usuário. 973db890-092c-49e4-a9d0-912a4c0a20c7

principal == ExampleCorp::User::"us-east-1_Example|973db890-092c-49e4-a9d0-912a4c0a20c7",

Quando quiser especificar um grupo de usuários em uma política de permissões verificadas, use o seguinte formato:

permit (
   principal in [Namespace]::[Group Entity]::"[Group name]",
   action,
   resource
);

A seguir está um exemplo

Controle de acesso baseado em atributos

A autorização com permissões verificadas para seus aplicativos e o recurso de atributos para controle de acesso dos grupos de identidade do Amazon Cognito para AWS credenciais são formas de controle de acesso baseado em atributos (). ABAC Veja a seguir uma comparação dos recursos das Permissões Verificadas e do Amazon CognitoABAC. EmABAC, um sistema examina os atributos de uma entidade e toma uma decisão de autorização a partir das condições definidas por você.