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
Seu aplicativo pode fornecer a identidade ou os tokens de acesso do usuário à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.
-
O grupo de usuários é uma fonte de identidade do Verified Permissions configurada para o repositório de políticas solicitado.
-
A reivindicação
client_id
ouaud
, no token de acesso ou identidade, respectivamente, corresponde a um ID de cliente da aplicação do grupo de usuários que você forneceu ao Verified Permissions. Para verificar essa reivindicação, é necessário configurar a validação do ID do cliente na fonte de identidade do Verified Permissions. -
O token não expirou.
-
O valor da
token_use
reivindicação em seu token corresponde aos parâmetros para os quais você passouIsAuthorizedWithToken
. Atoken_use
afirmação deve seraccess
se você a passou para oaccessToken
parâmetro eid
se você a passou para oidentityToken
parâmetro. -
A assinatura em seu token vem das chaves da JSON web publicadas (JWKs) do seu grupo de usuários. Você pode ver seu JWKs em
https://cognito-idp.
.Region
.amazonaws.com/your user pool ID
/.well-known/jwks.json
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.
nota
Devido à forma como o Verified Permissions processa as solicitações, não adicione reivindicações com o nome cognito
, dev
ou custom
na função de geração de pré-token. Quando você apresenta esses prefixos de solicitação reservados não no formato delimitado por dois pontos como cognito:username
, como nomes completos de reivindicações, as solicitações de autorização falham.
Recursos adicionais
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.
![Um diagrama que ilustra o fluxo de API autorização com Amazon Verified Permissions. Um aplicativo faz uma solicitação para um Amazon API GatewayAPI. Isso API invoca um autorizador Lambda. O autorizador faz uma API solicitação às Permissões verificadas. As permissões verificadas verificam a validade do token e retornam uma decisão de autorização.](images/amazon-cognito-avp-use-case.png)
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:
-
Seu aplicativo passou um ID ou token de acesso em um
Authorization
cabeçalho como um token portador. -
Seu aplicativo passou um token com uma
cognito:groups
declaração que contém a stringMyGroup
. -
Seu aplicativo fez uma
HTTP GET
solicitação para, por exemplo,https://myapi.example.com/pets
ouhttps://myapi.example.com/pets/scrappy
.
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 Cedarexample_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ê.
Serviço | Processar | Resultado |
---|---|---|
Amazon Verified Permissions | Retorna uma Deny decisão Allow or da análise de um grupo de usuáriosJWT. |
O acesso aos recursos do aplicativo é bem-sucedido ou não, com base na avaliação da política da Cedar. |
Grupos de identidade do Amazon Cognito (atributos para controle de acesso) | Atribui tags de sessão ao seu usuário com base em seus atributos. IAMas condições da política podem verificar as tags Allow ou Deny o acesso do usuário Serviços da AWS a. |
Uma sessão marcada com AWS credenciais temporárias para uma IAM função. |