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á.
# Trabalhando com fontes de Amazon Cognito identidade
As permissões verificadas trabalham em estreita colaboração com os grupos de usuários do Amazon Cognito. Amazon Cognito JWTs 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 principal que você deseja associar à sua fonte de identidade, por exemplo`MyCorp::User`.
+ O tipo de entidade do grupo principal que você deseja associar à sua fonte de identidade, por exemplo`MyCorp::UserGroup`.
+ O cliente IDs 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` Nesse caso, você referenciaria um usuário nesse grupo de usuários com ID `a1b2c3d4-5678-90ab-cdef-EXAMPLE22222` como `us-west-2_EXAMPLE|a1b2c3d4-5678-90ab-cdef-EXAMPLE22222`
As *declarações* de token do grupo de usuários podem conter atributos, escopos, grupos IDs, clientes e dados personalizados. [Amazon Cognito JWTs](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)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:
1. Declarações de nome de usuário e grupo com um `cognito:` prefixo
1. [Atributos de usuário personalizados](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-custom-attributes) com um `custom: prefix`
1. Declarações personalizadas adicionadas em tempo de execução
1. 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, em[Mapeamento de Amazon Cognito tokens para o esquema](cognito-map-token-to-schema.md).
**Importante**
Embora você possa revogar Amazon Cognito os tokens antes que eles expirem, eles JWTs são considerados recursos apátridas que são independentes, com assinatura e validade. Espera-se que os serviços em conformidade com [o JSON Web Token RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519) validem os tokens remotamente e não precisem validá-los com o emissor. Isso significa que é possível que as Permissões Verificadas concedam acesso com base em um token que foi revogado ou emitido para um usuário que foi 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. Para obter mais informações, consulte [Encerramento de sessões de usuário com revogação de token](https://docs.aws.amazon.com/cognito/latest/developerguide/token-revocation.html)
O exemplo a seguir mostra como você pode criar uma política que faça referência a algumas das reivindicações de grupos de usuários do Amazon Cognito associadas a um principal.
```
permit(
principal,
action,
resource == ExampleCo::Photo::"VacationPhoto94.jpg"
)
when {
principal["cognito:username"]) == "alice" &&
principal["custom:department"]) == "Finance"
};
```
O exemplo a seguir mostra como você pode criar uma política que faça referência a um principal que é um usuário em um grupo de usuários do Cognito. Observe que o ID principal assume a forma de`"|"`.
```
permit(
principal == ExampleCo::User::"us-east-1_example|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
action,
resource == ExampleCo::Photo::"VacationPhoto94.jpg"
);
```
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"]` e`principal["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` ou`custom`, uma solicitação de autorização com [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)falhará com a. `ValidationException`
Para obter mais informações sobre o mapeamento de declarações, consulte[Mapeamento de Amazon Cognito tokens para o esquema](cognito-map-token-to-schema.md). Para obter mais informações sobre autorização para Amazon Cognito usuários, consulte [Autorização com permissões verificadas da Amazon no Guia](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) do *desenvolvedor do Amazon Cognito*.
**Topics**
+ [Criação de fontes de Amazon Cognito identidade do Amazon Verified Permissions](cognito-create.md)
+ [Editando fontes de Amazon Cognito identidade do Amazon Verified Permissions](cognito-edit.md)
+ [Mapeamento de Amazon Cognito tokens para o esquema](cognito-map-token-to-schema.md)
+ [Validação de clientes e públicos para Amazon Cognito](cognito-validation.md)
# Criação de fontes de Amazon Cognito identidade do Amazon Verified Permissions
O procedimento a seguir adiciona uma fonte de identidade a um repositório de políticas existente.
Você também pode criar uma fonte de identidade ao [criar um novo repositório de políticas](policy-stores-create.md) no console de Permissões Verificadas. Nesse processo, você pode importar automaticamente as declarações em seus tokens de origem de identidade para os atributos da entidade. Escolha a opção **Configuração guiada** ou ** API Gateway Configurar com um provedor de identidade**. Essas opções também criam políticas iniciais.
**nota**
As **origens de identidade** só estarão disponíveis no painel de navegação à esquerda depois que você criar um armazenamento de políticas. As origens de identidade criadas por você são associadas ao armazenamento de políticas atual.
Você pode omitir o tipo de entidade principal ao criar uma fonte de identidade [create-identity-source](https://docs.aws.amazon.com/cli/latest/reference/verifiedpermissions/create-identity-source.html)na API de permissões verificadas AWS CLI ou [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)na API de permissões verificadas. No entanto, um tipo de entidade em branco cria uma fonte de identidade com um tipo de entidade de`AWS::Cognito`. Esse nome de entidade não é compatível com o esquema do repositório de políticas. Para integrar Amazon Cognito identidades com seu esquema de armazenamento de políticas, você deve definir o tipo de entidade principal como uma entidade de armazenamento de políticas compatível.
------
#### [ Console de gerenciamento da AWS ]
**Para criar uma origem de identidade de grupos de usuários do Amazon Cognito**
1. Abra o [console de Permissões verificadas](https://console.aws.amazon.com/verifiedpermissions/). Escolha seu repositório de políticas.
1. No painel de navegação à esquerda, escolha **Origens de identidade**.
1. Escolha **Criar origem de identidade**.
1. Em **Detalhes do grupo de usuários do Cognito**, selecione Região da AWS e insira o **ID do grupo de usuários** para sua fonte de identidade.
1. Em **Configuração principal**, em **Tipo principal**, escolha o tipo de entidade para principais dessa origem. As identidades dos grupos de usuários conectados do Amazon Cognito serão mapeadas para o tipo de entidade principal selecionado.
1. Em **Configuração de grupo**, selecione **Usar grupo Cognito** se quiser mapear a declaração do grupo `cognito:groups` de usuários. Escolha um tipo de entidade que seja pai do tipo principal.
1. Em **Validação do aplicativo cliente**, escolha se deseja validar o aplicativo IDs cliente.
+ Para validar o aplicativo cliente IDs, escolha **Aceitar somente tokens com o aplicativo IDs cliente correspondente**. Escolha **Adicionar novo ID de aplicação cliente** para cada ID de aplicação cliente a ser validado. Para remover um ID de aplicação cliente adicionado, escolha **Remover** ao lado do ID de aplicação cliente.
+ Escolha **Não validar o aplicativo cliente IDs** se você não quiser validar o aplicativo cliente. IDs
1. Escolha **Criar origem de identidade**.
1. (Opcional) Se seu repositório de políticas tiver um esquema, antes de fazer referência aos atributos extraídos dos tokens de identidade ou acesso em suas políticas do Cedar, você deverá atualizar seu esquema para que o Cedar conheça o tipo de principal que sua fonte de identidade cria. Essa adição ao esquema deve incluir os atributos que você deseja referenciar nas políticas do Cedar. Para obter mais informações sobre o mapeamento de atributos de Amazon Cognito token para os atributos principais do Cedar, consulte[Mapeamento de Amazon Cognito tokens para o esquema](cognito-map-token-to-schema.md).
**nota**
Quando você cria um [repositório de políticas vinculado à API](policy-stores-api-userpool.md) ou usa **Configurar com API Gateway um provedor de identidade** ao criar repositórios de políticas, o Verified Permissions consulta seu grupo de usuários em busca de atributos de usuário e cria um esquema em que seu tipo principal é preenchido com atributos do grupo de usuários.
1. Crie políticas que usem informações dos tokens para tomar decisões de autorização. Para obter mais informações, consulte [Criação de políticas estáticas do Amazon Verified Permissions](policies-create.md).
Agora que você criou uma fonte de identidade, atualizou o esquema e criou políticas, use `IsAuthorizedWithToken` para que as Permissões Verificadas tomem decisões de autorização. Para obter mais informações, consulte [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)o *guia de referência da Amazon Verified Permissions API*.
------
#### [ AWS CLI ]
**Para criar uma origem de identidade de grupos de usuários do Amazon Cognito**
Você pode criar uma fonte de identidade usando a [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)operação. O exemplo a seguir cria uma fonte de identidade que pode acessar identidades autenticadas de um grupo de Amazon Cognito usuários.
1. Crie um `config.txt` arquivo que contenha os seguintes detalhes do grupo de Amazon Cognito usuários para uso pelo `--configuration` parâmetro no `create-identity-source` comando.
```
{
"cognitoUserPoolConfiguration": {
"userPoolArn": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_1a2b3c4d5",
"clientIds":["a1b2c3d4e5f6g7h8i9j0kalbmc"],
"groupConfiguration": {
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. Execute o comando a seguir para criar uma fonte de Amazon Cognito identidade.
```
$ aws verifiedpermissions create-identity-source \
--configuration file://config.txt \
--principal-entity-type "User" \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
1. (Opcional) Se seu repositório de políticas tiver um esquema, antes de fazer referência aos atributos extraídos dos tokens de identidade ou acesso em suas políticas do Cedar, você deverá atualizar seu esquema para que o Cedar conheça o tipo de principal que sua fonte de identidade cria. Essa adição ao esquema deve incluir os atributos que você deseja referenciar nas políticas do Cedar. Para obter mais informações sobre o mapeamento de atributos de Amazon Cognito token para os atributos principais do Cedar, consulte[Mapeamento de Amazon Cognito tokens para o esquema](cognito-map-token-to-schema.md).
**nota**
Quando você cria um [repositório de políticas vinculado à API](policy-stores-api-userpool.md) ou usa **Configurar com API Gateway um provedor de identidade** ao criar repositórios de políticas, o Verified Permissions consulta seu grupo de usuários em busca de atributos de usuário e cria um esquema em que seu tipo principal é preenchido com atributos do grupo de usuários.
1. Crie políticas que usem informações dos tokens para tomar decisões de autorização. Para obter mais informações, consulte [Criação de políticas estáticas do Amazon Verified Permissions](policies-create.md).
Agora que você criou uma fonte de identidade, atualizou o esquema e criou políticas, use `IsAuthorizedWithToken` para que as Permissões Verificadas tomem decisões de autorização. Para obter mais informações, consulte [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)o *guia de referência da Amazon Verified Permissions API*.
------
Para obter mais informações sobre o uso de tokens de acesso e identidade do Amazon Cognito para usuários autenticados no Verified Permissions, consulte [Autorização com o Amazon Verified Permissions](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) no *Guia do desenvolvedor do Amazon Cognito*.
# Editando fontes de Amazon Cognito identidade do Amazon Verified Permissions
Você pode editar alguns parâmetros da sua fonte de identidade depois de criá-la. Você não pode alterar o tipo de fonte de identidade, você precisa excluir a fonte de identidade e criar uma nova para mudar para o OIDC ou Amazon Cognito para o OIDC. Amazon Cognito Se o esquema do repositório de políticas corresponder aos atributos da fonte de identidade, observe que você deve atualizar o esquema separadamente para refletir as alterações feitas na fonte de identidade.
------
#### [ Console de gerenciamento da AWS ]
**Para atualizar uma fonte Amazon Cognito de identidade**
1. Abra o [console de Permissões verificadas](https://console.aws.amazon.com/verifiedpermissions/). Escolha seu repositório de políticas.
1. No painel de navegação à esquerda, escolha **Origens de identidade**.
1. Escolha o ID da origem de identidade a ser editada.
1. Escolha **Editar**.
1. Em **Detalhes do grupo de usuários do Cognito**, selecione Região da AWS e digite o **ID do grupo de usuários** para sua fonte de identidade.
1. Em **Detalhes do principal**, você pode atualizar o **tipo de principal** para a fonte de identidade. As identidades dos grupos de usuários conectados do Amazon Cognito serão mapeadas para o tipo de entidade principal selecionado.
1. Em **Configuração de grupo**, selecione **Usar grupos do Cognito** se quiser mapear a declaração do grupo `cognito:groups` de usuários. Escolha um tipo de entidade que seja pai do tipo principal.
1. Em **Validação do aplicativo cliente**, escolha se deseja validar o aplicativo IDs cliente.
+ Para validar o aplicativo cliente IDs, escolha **Aceitar somente tokens com o aplicativo IDs cliente correspondente**. Escolha **Adicionar novo ID de aplicação cliente** para cada ID de aplicação cliente a ser validado. Para remover um ID de aplicação cliente adicionado, escolha **Remover** ao lado do ID de aplicação cliente.
+ Escolha **Não validar o aplicativo cliente IDs** se você não quiser validar o aplicativo cliente. IDs
1. Escolha **Salvar alterações**.
1. Se você alterou o tipo de entidade principal da origem de identidade, deverá atualizar seu esquema para refletir corretamente o tipo de entidade principal atualizado.
Você pode excluir uma origem de identidade escolhendo o botão de opção ao lado de uma origem de identidade e, em seguida, escolhendo **Excluir origem de identidade**. Digite `delete` na caixa de texto e escolha **Excluir origem de identidade** para confirmar a exclusão da origem de identidade.
------
#### [ AWS CLI ]
**Para atualizar uma fonte Amazon Cognito de identidade**
Você pode atualizar uma fonte de identidade usando a [UpdateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_UpdateIdentitySource.html)operação. O exemplo a seguir atualiza a fonte de identidade especificada para usar um grupo de Amazon Cognito usuários diferente.
1. Crie um `config.txt` arquivo que contenha os seguintes detalhes do grupo de Amazon Cognito usuários para uso pelo `--configuration` parâmetro no `update-identity-source` comando.
```
{
"cognitoUserPoolConfiguration": {
"userPoolArn": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_1a2b3c4d5",
"clientIds":["a1b2c3d4e5f6g7h8i9j0kalbmc"],
"groupConfiguration": {
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. Execute o comando a seguir para atualizar uma fonte de Amazon Cognito identidade.
```
$ aws verifiedpermissions update-identity-source \
--update-configuration file://config.txt \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
**nota**
Se você alterar o tipo de entidade principal da origem de identidade, será necessário atualizar o esquema para refletir corretamente o tipo de entidade principal atualizado.
------
# Mapeamento de Amazon Cognito tokens para o esquema
Talvez você queira adicionar uma fonte de identidade a um repositório de políticas e mapear declarações, ou tokens, do provedor ao esquema do repositório de políticas. Você pode automatizar esse processo usando a [Configuração guiada](policy-stores-create.md) para criar seu repositório de políticas com uma fonte de identidade ou atualizar seu esquema manualmente após a criação do repositório de políticas. Depois de mapear os tokens para o esquema, você pode criar políticas que façam referência a eles.
Esta seção do guia do usuário tem as seguintes informações:
+ Quando você pode preencher automaticamente os atributos de um esquema de armazenamento de políticas
+ Como usar declarações de Amazon Cognito token em suas políticas de permissões verificadas
+ Como criar manualmente um esquema para uma fonte de identidade
Os [repositórios de políticas vinculados à API](policy-stores-api-userpool.md) e os repositórios de políticas com uma fonte de identidade que foram criados por meio da [configuração guiada](policy-stores-create.md) não exigem o mapeamento manual dos atributos do token de identidade (ID) para o esquema. Você pode fornecer Permissões Verificadas com os atributos em seu grupo de usuários e criar um esquema preenchido com atributos de usuário. Na autorização do token de ID, as Permissões verificadas mapeiam as reivindicações aos atributos de uma entidade principal. Talvez seja necessário mapear manualmente Amazon Cognito os tokens para seu esquema nas seguintes condições:
+ Você criou um repositório de políticas vazio ou um repositório de políticas a partir de uma amostra.
+ Você deseja estender o uso de tokens de acesso além do controle de acesso baseado em funções (RBAC).
+ Você cria repositórios de políticas com a API REST de permissões verificadas, um AWS SDK ou o. AWS CDK
Para usar Amazon Cognito como fonte de identidade em seu repositório de políticas de Permissões Verificadas, você deve ter atributos de provedor em seu esquema. O esquema é fixo e deve corresponder às entidades que os tokens do provedor criam [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)ou às solicitações de [BatchIsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_BatchIsAuthorizedWithToken.html)API. Se você criou seu repositório de políticas de uma forma que preenche automaticamente seu esquema a partir das informações do provedor em um token de ID, você está pronto para escrever políticas. Se você criar um repositório de políticas sem um esquema para sua fonte de identidade, deverá adicionar atributos de provedor ao esquema que correspondam às entidades criadas usando solicitações de API. Em seguida, você pode escrever políticas usando atributos do token do provedor.
Para obter mais informações sobre o uso do Amazon Cognito ID e tokens de acesso para usuários autenticados em Permissões verificadas, consulte Autorização [com permissões verificadas da Amazon](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) no Guia do desenvolvedor do *Amazon* Cognito.
**Topics**
+ [Mapeamento de tokens de ID para o esquema](#cognito-map-id-token)
+ [Mapeamento de tokens de acesso](#cognito-map-access-token)
+ [Notação alternativa para declarações delimitadas por Amazon Cognito dois pontos](#cognito-colon-claims)
+ [Coisas que você deve saber sobre mapeamento de esquemas](#cognito-map-token-to-schema-things-to-know)
## Mapeamento de tokens de ID para o esquema
As permissões verificadas processam as reivindicações de token de ID como atributos do usuário: seus nomes e títulos, sua associação ao grupo, suas informações de contato. Os tokens de ID são mais úteis em um modelo de autorização de *controle de acesso baseado em atributos* (ABAC). Quando você quiser que as Permissões Verificadas analisem o acesso aos recursos com base em quem está fazendo a solicitação, escolha tokens de ID para sua fonte de identidade.
Amazon Cognito Os tokens de ID funcionam com a maioria das [bibliotecas independentes do OIDC.](https://openid.net/developers/certified-openid-connect-implementations/) Eles ampliam os recursos do OIDC com reivindicações adicionais. Seu aplicativo pode autenticar o usuário com as operações da API de autenticação de grupos de usuários do Amazon Cognito ou com a interface de usuário hospedada do grupo de usuários. Para obter mais informações, consulte Como [usar a API e os endpoints](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pools-API-operations.html) no *Guia do Amazon Cognito desenvolvedor*.Reivindicações úteis em tokens Amazon Cognito de ID
*`cognito:username` e `preferred_username`*
Variantes do nome de usuário do usuário.
*`sub`*
O identificador de usuário exclusivo (UUID) do usuário
*Reivindicações com um `custom:` prefixo*
Um prefixo para atributos personalizados do grupo de usuários, como`custom:employmentStoreCode`.
*Reivindicações padrão*
Afirmações padrão do OIDC, como e. `email` `phone_number` Para obter mais informações, consulte [Declarações padrão](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) no *OpenID Connect Core 1.0 incorporando o conjunto de erratas 2*.
*`cognito:groups`*
As associações de um usuário ao grupo. Em um modelo de autorização baseado no controle de acesso baseado em funções (RBAC), essa declaração apresenta as funções que você pode avaliar em suas políticas.
*Reivindicações transitórias*
Declarações que não são propriedade do usuário, mas são adicionadas em tempo de execução por um acionador [Lambda de pré-geração de tokens](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html) do grupo de usuários. As reivindicações transitórias se assemelham às reivindicações padrão, mas estão fora do padrão, por exemplo `tenant` ou. `department`
Nas políticas que fazem referência a Amazon Cognito atributos que têm um `:` separador, faça referência aos atributos no formato`principal["cognito:username"]`. A reivindicação de funções `cognito:groups` é uma exceção a essa regra. As permissões verificadas mapeiam o conteúdo dessa declaração para as entidades principais da entidade do usuário.
Para obter mais informações sobre a estrutura dos tokens de ID dos grupos de usuários do Amazon Cognito, consulte [Uso do token de ID](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html) no Guia do *Amazon Cognito desenvolvedor*.
O exemplo de token de ID a seguir tem cada um dos quatro tipos de atributos. Ela inclui a reivindicação Amazon Cognito específica`cognito:username`, a declaração personalizada`custom:employmentStoreCode`, a reivindicação padrão e a reivindicação `email` transitória. `tenant`
```
{
"sub": "91eb4550-XXX",
"cognito:groups": [
"Store-Owner-Role",
"Customer"
],
"email_verified": true,
"clearance": "confidential",
"iss": "https://cognito-idp.us-east-2.amazonaws.com/us-east-2_EXAMPLE",
"cognito:username": "alice",
"custom:employmentStoreCode": "petstore-dallas",
"origin_jti": "5b9f50a3-05da-454a-8b99-b79c2349de77",
"aud": "1example23456789",
"event_id": "0ed5ad5c-7182-4ecf-XXX",
"token_use": "id",
"auth_time": 1687885407,
"department": "engineering",
"exp": 1687889006,
"iat": 1687885407,
"tenant": "x11app-tenant-1",
"jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN1111111",
"email": "alice@example.com"
}
```
Ao criar uma fonte de identidade com seu grupo de Amazon Cognito usuários, você especifica o tipo de entidade principal com a qual o Verified Permissions gera nas solicitações de autorização`IsAuthorizedWithToken`. Suas políticas poderão, então, testar os atributos dessa entidade principal como parte da avaliação dessa solicitação. Seu esquema define o tipo e os atributos principais de uma fonte de identidade e, em seguida, você pode referenciá-los nas políticas do Cedar.
Você também especifica o tipo de entidade de grupo que deseja derivar da declaração do grupo de tokens de ID. Nas solicitações de autorização, as Permissões verificadas mapeiam cada membro da reivindicação do grupo para esse tipo de entidade do grupo. Nas políticas, você pode referenciar essa entidade do grupo como principal.
O exemplo a seguir mostra como refletir os atributos do exemplo de token de identidade no esquema do Verified Permissions. Para obter mais informações sobre a edição do esquema, consulte [Editando esquemas de armazenamento de políticas](schema-edit.md). Se a configuração da origem de identidade especificar o tipo de entidade principal `User`, você poderá incluir algo semelhante ao exemplo a seguir para disponibilizar esses atributos ao Cedar.
```
"User": {
"shape": {
"type": "Record",
"attributes": {
"cognito:username": {
"type": "String",
"required": false
},
"custom:employmentStoreCode": {
"type": "String",
"required": false
},
"email": {
"type": "String"
},
"tenant": {
"type": "String",
"required": true
}
}
}
}
```
Para obter um exemplo de política que será validada em relação a esse esquema, consulte. [Reflete os atributos Amazon Cognito do token de ID](policies-examples.md#policies-examples-cognito-id)
## Mapeamento de tokens de acesso
As permissões verificadas processam declarações de token de acesso diferentes das reivindicações do grupo como atributos da ação ou atributos de *contexto*. Além da associação ao grupo, os tokens de acesso do seu IdP podem conter informações sobre o acesso à API. Os tokens de acesso são úteis em modelos de autorização que usam controle de acesso baseado em funções (RBAC). Os modelos de autorização que dependem de declarações de token de acesso que não sejam a associação ao grupo exigem um esforço adicional na configuração do esquema.
Amazon Cognito os tokens de acesso têm reivindicações que podem ser usadas para autorização:Reivindicações úteis em tokens de Amazon Cognito acesso
*`client_id`*
O ID do aplicativo cliente de uma parte confiável do OIDC. Com a ID do cliente, as Permissões Verificadas podem verificar se a solicitação de autorização vem de um cliente permitido para o repositório de políticas. Na autorização machine-to-machine (M2M), o sistema solicitante autoriza uma solicitação com um segredo do cliente e fornece o ID e os escopos do cliente como evidência da autorização.
*`scope`*
Os [escopos OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) que representam as permissões de acesso do portador do token.
*`cognito:groups`*
As associações de um usuário ao grupo. Em um modelo de autorização baseado no controle de acesso baseado em funções (RBAC), essa declaração apresenta as funções que você pode avaliar em suas políticas.
*Reivindicações transitórias*
Declarações que não são uma permissão de acesso, mas são adicionadas em tempo de execução por um acionador [Lambda de pré-geração de tokens](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html) do grupo de usuários. As reivindicações transitórias se assemelham às reivindicações padrão, mas estão fora do padrão, por exemplo `tenant` ou. `department` A personalização dos tokens de acesso adiciona custo à sua AWS fatura.
Para obter mais informações sobre a estrutura dos tokens de acesso dos grupos de usuários do Amazon Cognito, consulte [Uso do token de acesso](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html) no Guia do *Amazon Cognito desenvolvedor*.
Um token de Amazon Cognito acesso é mapeado para um objeto de contexto quando passado para Permissões verificadas. Os atributos do token de acesso podem ser referenciados por meio de `context.token.attribute_name`. O exemplo de token de acesso a seguir inclui as reivindicações `client_id` e `scope`.
```
{
"sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e",
"cognito:groups": [
"Store-Owner-Role",
"Customer"
],
"iss": "https://cognito-idp.us-east-2.amazonaws.com/us-east-2_EXAMPLE",
"client_id": "1example23456789",
"origin_jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN1111111",
"event_id": "bda909cb-3e29-4bb8-83e3-ce6808f49011",
"token_use": "access",
"scope": "MyAPI/mydata.write",
"auth_time": 1688092966,
"exp": 1688096566,
"iat": 1688092966,
"jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN2222222",
"username": "alice"
}
```
O exemplo a seguir mostra como refletir os atributos do exemplo de token de acesso no esquema do Verified Permissions. Para obter mais informações sobre a edição do esquema, consulte [Editando esquemas de armazenamento de políticas](schema-edit.md).
```
{
"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 obter um exemplo de política que será validada em relação a esse esquema, consulte. [Reflete os atributos do token de Amazon Cognito acesso](policies-examples.md#policies-examples-cognito-access)
## Notação alternativa para declarações delimitadas por Amazon Cognito dois pontos
No momento em que as Permissões verificadas foram lançadas, o esquema recomendado para declarações de Amazon Cognito token, como `cognito:groups` e `custom:store` converteu essas cadeias de caracteres delimitadas por dois pontos para usar o caractere como um delimitador de hierarquia. `.` Esse formato é chamado de *notação de pontos*. Por exemplo, uma referência a `cognito:groups` tornou-se `principal.cognito.groups` em suas políticas. Embora você possa continuar usando esse formato, recomendamos que você crie seu esquema e suas políticas com a notação de [colchetes.](#cognito-map-token-to-schema-things-to-know) Nesse formato, uma referência a se `cognito:groups` torna `principal["cognito:groups"]` em suas políticas. Os esquemas gerados automaticamente para tokens de ID do grupo de usuários do console de Permissões Verificadas usam a notação de colchetes.
Você pode continuar usando a notação de pontos em esquemas e políticas criados manualmente para fontes de identidade. Amazon Cognito Você não pode usar a notação de pontos com `:` ou quaisquer outros caracteres não alfanuméricos no esquema ou nas políticas para qualquer outro tipo de IdP do OIDC.
Um esquema para notação de pontos agrupa cada instância de um `:` caractere como filha da frase `custom` inicial `cognito` ou da frase, conforme mostrado no exemplo a seguir:
```
"CognitoUser": {
"shape": {
"type": "Record",
"attributes": {
"cognito": {
"type": "Record",
"required": true,
"attributes": {
"username": {
"type": "String",
"required": true
}
}
},
"custom": {
"type": "Record",
"required": true,
"attributes": {
"employmentStoreCode": {
"type": "String",
"required": true
}
}
},
"email": {
"type": "String"
},
"tenant": {
"type": "String",
"required": true
}
}
}
}
```
Para obter um exemplo de política que validará esse esquema e usará a notação de pontos, consulte. [Usa notação de pontos para referenciar atributos](policies-examples.md#policies-examples-dot)
## Coisas que você deve saber sobre mapeamento de esquemas
**O mapeamento de atributos difere entre os tipos de token**
Na autorização do token de acesso, as permissões verificadas mapeiam as reivindicações de acordo com o [contexto](context.md). Na autorização do token de ID, as Permissões verificadas mapeiam as reivindicações para os atributos principais. Para repositórios de políticas que você cria no console de Permissões Verificadas, somente repositórios de políticas **vazios** e de **amostra** deixam você sem fonte de identidade e exigem que você preencha seu esquema com atributos do grupo de usuários para autorização do token de ID. A autorização do token de acesso é baseada no controle de acesso baseado em funções (RBAC) com declarações de associação a grupos e não mapeia automaticamente outras reivindicações para o esquema do repositório de políticas.
**Os atributos da fonte de identidade não são obrigatórios**
Quando você cria uma fonte de identidade no console de Permissões verificadas, nenhum atributo é marcado como obrigatório. Isso evita que declarações perdidas causem erros de validação nas solicitações de autorização. Você pode definir atributos como obrigatórios conforme necessário, mas eles devem estar presentes em todas as solicitações de autorização.
**O RBAC não exige atributos no esquema**
Os esquemas para fontes de identidade dependem das associações de entidades que você faz ao adicionar sua fonte de identidade. Uma fonte de identidade mapeia uma afirmação para um tipo de entidade de usuário e uma afirmação para um tipo de entidade de grupo. Esses mapeamentos de entidades são o núcleo de uma configuração de origem de identidade. Com essas informações mínimas, você pode criar políticas que executem ações de autorização para usuários específicos e grupos específicos dos quais os usuários possam ser membros, em um modelo de controle de acesso baseado em função (RBAC). A adição de declarações de token ao esquema amplia o escopo de autorização do seu repositório de políticas. Os atributos de usuário dos tokens de ID têm informações sobre usuários que podem contribuir para a autorização do controle de acesso baseado em atributos (ABAC). Os atributos de contexto dos tokens de acesso têm informações como escopos OAuth 2.0 que podem contribuir com informações adicionais de controle de acesso do seu provedor, mas exigem modificações adicionais no esquema.
As opções **Configurar com o API Gateway e um provedor de identidade** e **Configuração guiada** no console de permissões verificadas atribuem reivindicações de token de ID ao esquema. Esse não é o caso das reivindicações de token de acesso. [Para adicionar declarações de token de acesso que não sejam de grupo ao seu esquema, você deve editá-lo no modo JSON e adicionar atributos commonTypes.](https://docs.cedarpolicy.com/schema/json-schema.html#schema-commonTypes) Para obter mais informações, consulte [Mapeamento de tokens de acesso](#cognito-map-access-token).
**Escolha um tipo de token**
A forma como seu repositório de políticas funciona com sua fonte de identidade depende de uma decisão importante na configuração da fonte de identidade: se você processará tokens de ID ou de acesso. Com um provedor de Amazon Cognito identidade, você pode escolher o tipo de token ao criar um repositório de políticas vinculado à API. Ao criar um [repositório de políticas vinculado à API](policy-stores-api-userpool.md), você deve escolher se deseja configurar a autorização para tokens de ID ou de acesso. Essas informações afetam os atributos do esquema que as Permissões Verificadas aplicam ao seu armazenamento de políticas e a sintaxe do autorizador Lambda para sua API. API Gateway Especialmente se você quiser se beneficiar do mapeamento automático de declarações de token de ID para atributos no console de permissões verificadas, decida com antecedência sobre o tipo de token que você deseja processar antes de criar sua fonte de identidade. Alterar o tipo de token exige um esforço significativo para refatorar suas políticas e seu esquema. Os tópicos a seguir descrevem o uso de tokens de ID e acesso com repositórios de políticas.
**O analisador Cedar requer colchetes para alguns caracteres**
As políticas geralmente fazem referência aos atributos do esquema em um formato como`principal.username`. No caso da maioria dos caracteres não alfanuméricos`:`, como, ou`.`, `/` que podem aparecer nos nomes de reivindicações de token, as Permissões Verificadas não podem analisar um valor de condição como `principal.cognito:username` ou. `context.ip-address` Em vez disso, você deve formatar essas condições com a notação de colchetes no formato `principal["cognito:username"]` ou`context["ip-address"]`, respectivamente. O caractere sublinhado `_` é um caractere válido nos nomes das reivindicações e a única exceção não alfanumérica a esse requisito.
Um exemplo parcial de esquema para um atributo principal desse tipo tem a seguinte aparência:
```
"User": {
"shape": {
"type": "Record",
"attributes": {
"cognito:username": {
"type": "String",
"required": true
},
"custom:employmentStoreCode": {
"type": "String",
"required": true,
},
"email": {
"type": "String",
"required": false
}
}
}
}
```
Um exemplo parcial de esquema para um atributo de contexto desse tipo tem a seguinte aparência:
```
"GetOrder": {
"memberOf": [],
"appliesTo": {
"resourceTypes": [
"Order"
],
"context": {
"type": "Record",
"attributes": {
"ip-address": {
"required": false,
"type": "String"
}
}
},
"principalTypes": [
"User"
]
}
}
```
Para obter um exemplo de política que será validada em relação a esse esquema, consulte. [Usa notação de colchetes para referenciar atributos de token](policies-examples.md#policies-examples-brackets)
# Validação de clientes e públicos para Amazon Cognito
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 Amazon Cognito e entre fontes de identidade 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 à instância do provedor de identidade que seu aplicativo usa, por exemplo`1example23456789`. Um *público* é um caminho de URL associado à *parte confiável ou* ao destino pretendido do token de acesso, por exemplo`https://mytoken.example.com`. Ao usar tokens de acesso, a `aud` reivindicação está sempre associada ao público.
Amazon Cognito Os tokens de ID têm uma `aud` declaração que contém o ID do [cliente do aplicativo](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html). Os tokens de acesso têm uma `client_id` declaração que também contém o ID do cliente do aplicativo.
Quando você insere um ou mais valores para a **validação do aplicativo Cliente** em sua fonte de identidade, o Verified Permissions compara essa lista de clientes do aplicativo com IDs a `aud` reivindicação do token de ID ou com a declaração do token `client_id` de acesso. As permissões verificadas não validam uma URL de público confiável para fontes de identidade. Amazon Cognito
## 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 aplicativo usando um JWT.¹
```
async function authorizeUsingJwtToken(jwtToken) {
const payload = await verifier.verify(jwtToken);
let 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
};
let 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
};
let 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
};
let entities = {
entityList: [],
};
entities.entityList.push(...getUserEntitiesFromToken(payload));
let 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 exemplo de código usa a [aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify)biblioteca para verificar se a JWTs assinatura é compatível com IdPs OIDC.