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 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 JWTs produzem 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. + Registros CNAME que não incluem curingas. Por exemplo, não `a.example.com` pode ser mapeado para`*.example.net`. Por outro lado, não `*.example.com` pode ser mapeado para. `a.example.net` + 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 exemplo`MyCorp::User`. + O tipo de entidade do grupo que você deseja associar à sua fonte de identidade, por exemplo`MyCorp::UserGroup`. + Um exemplo de token de ID ou uma definição das declarações no token de ID. + O prefixo que você deseja aplicar à entidade IDs 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 a opção **Configurar com o API Gateway e um provedor de identidade** ou **Configuração guiada**, as Permissões Verificadas atribuem um prefixo do nome do emissor menos`https://`, por exemplo. `MyCorp::User::"auth.example.com|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"` Para obter mais informações sobre o uso de operações de API para autorizar solicitações de fontes do OIDC, consulte. [Operações de API disponíveis para autorização](authorization.md#authorization-operations) O exemplo a seguir 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. Observe que, ao fazer referência a um grupo no principal, você deve usar o `in` operador para que a política seja avaliada corretamente. ``` permit( principal in MyCorp::UserGroup::"MyOIDCProvider|Accounting", action, resource in MyCorp::Folder::"YearEnd2024" ) when { principal.jobClassification == "Confidential" && !(principal.location like "SatelliteOffice*") }; ``` **Topics** + [Criação de fontes de identidade OIDC do Amazon Verified Permissions](oidc-create.md) + [Editando fontes de identidade do Amazon Verified Permissions OIDC](oidc-edit.md) + [Mapeando tokens OIDC para o esquema](oidc-map-token-to-schema.md) + [Validação de clientes e públicos para fornecedores de OIDC](oidc-validation.md) # Criação de fontes de identidade OIDC 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 fonte de identidade do OpenID Connect (OIDC)** 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. Escolha provedor **OIDC externo**. 1. Em **URL do emissor**, insira a URL do emissor do OIDC. Esse é o endpoint do serviço que fornece o servidor de autorização, as chaves de assinatura e outras informações sobre seu provedor, por exemplo`https://auth.example.com`. Seu URL de emissor deve hospedar um documento de descoberta do OIDC em. `/.well-known/openid-configuration` 1. Em **Tipo de token**, escolha o tipo de OIDC JWT que você deseja que seu aplicativo envie para autorização. Para obter mais informações, consulte [Mapeando tokens OIDC para o esquema](oidc-map-token-to-schema.md). 1. Em **Mapear reivindicações de token para entidades do esquema**, escolha uma **entidade de usuário** e uma **declaração de usuário** para a fonte de identidade. A **entidade Usuário** é uma entidade em seu repositório de políticas que você deseja indicar aos usuários do seu provedor OIDC. A **reivindicação do usuário** é uma reivindicação`sub`, normalmente, de seu ID ou token de acesso que contém o identificador exclusivo da entidade a ser avaliada. As identidades do IdP OIDC conectado serão mapeadas para o tipo principal selecionado. 1. (Opcional) Em **Mapear declarações de token para entidades do esquema**, escolha uma **entidade de grupo** e uma **declaração de grupo** para a fonte de identidade. A **entidade do Grupo** é [mãe](https://docs.cedarpolicy.com/overview/terminology.html#term-group) da **entidade Usuário**. As reivindicações de grupo são mapeadas para essa entidade. A **declaração de grupo** é uma afirmação, normalmente`groups`, de seu ID ou token de acesso que contém uma string, JSON ou string delimitada por espaço de nomes de grupos de usuários para a entidade a ser avaliada. As identidades do IdP OIDC conectado serão mapeadas para o tipo principal selecionado. 1. Em **validação - opcional**, insira o cliente IDs ou público URLs que você deseja que seu repositório de políticas aceite nas solicitações de autorização, se houver. 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 que você extrai 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 dos atributos do token OIDC para os atributos principais do Cedar, consulte. [Mapeando tokens OIDC para o esquema](oidc-map-token-to-schema.md) 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 fonte de identidade OIDC** 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 provedor de identidade OIDC (IdP). 1. Crie um `config.txt` arquivo que contenha os seguintes detalhes de um IdP do OIDC para uso pelo `--configuration` parâmetro do comando. `create-identity-source` ``` { "openIdConnectConfiguration": { "issuer": "https://auth.example.com", "tokenSelection": { "identityTokenOnly": { "clientIds":["1example23456789"], "principalIdClaim": "sub" }, }, "entityIdPrefix": "MyOIDCProvider", "groupConfiguration": { "groupClaim": "groups", "groupEntityType": "MyCorp::UserGroup" } } } ``` 1. Execute o comando a seguir para criar uma fonte de identidade OIDC. ``` $ 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 que você extrai 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 dos atributos do token OIDC para os atributos principais do Cedar, consulte. [Mapeando tokens OIDC para o esquema](oidc-map-token-to-schema.md) 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*. ------ # Editando fontes de identidade do Amazon Verified Permissions OIDC 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 de identidade do OIDC** 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. Nos **detalhes do provedor OIDC**, altere a **URL do emissor conforme necessário**. 1. Em **Mapear declarações de token para atributos de esquema**, altere as associações entre declarações de usuário e grupo e os tipos de entidade de armazenamento de políticas, conforme necessário. Depois de alterar os tipos de entidade, você deve atualizar suas políticas e atributos do esquema para aplicar aos novos tipos de entidade. 1. Na **validação de público**, adicione ou remova valores de público que você deseja aplicar. 1. Escolha **Salvar alterações**. 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 de identidade do OIDC** 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 provedor OIDC diferente. 1. Crie um `config.txt` arquivo que contenha os seguintes detalhes de um IdP do OIDC para uso pelo `--configuration` parâmetro do comando. `update-identity-source` ``` { "openIdConnectConfiguration": { "issuer": "https://auth2.example.com", "tokenSelection": { "identityTokenOnly": { "clientIds":["2example10111213"], "principalIdClaim": "sub" }, }, "entityIdPrefix": "MyOIDCProvider", "groupConfiguration": { "groupClaim": "groups", "groupEntityType": "MyCorp::UserGroup" } } } ``` 1. Execute o comando a seguir para atualizar uma fonte de identidade do OIDC. ``` $ 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. ------ # Mapeando tokens OIDC 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 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. Para usar um provedor de identidade (IdP) do OIDC 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. **Topics** + [Mapeamento de tokens de ID para o esquema](#oidc-map-id-token) + [Mapeamento de tokens de acesso](#oidc-map-access-token) + [Coisas que você deve saber sobre mapeamento de esquemas](#oidc-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. Trabalhar com tokens de ID de um provedor de OIDC é quase o mesmo que trabalhar com tokens de Amazon Cognito ID. A diferença está nas reivindicações. Seu IdP pode apresentar [atributos padrão do OIDC](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) ou ter um esquema personalizado. Ao criar um novo repositório de políticas no console de Permissões verificadas, você pode adicionar uma fonte de identidade do OIDC com um exemplo de token de ID ou mapear manualmente as declarações de token para os atributos do usuário. Como as Permissões Verificadas não conhecem o esquema de atributos do seu IdP, você deve fornecer essas informações. Para obter mais informações, consulte [Criação de armazenamentos de políticas do Verified Permissions](policy-stores-create.md). Veja a seguir um exemplo de esquema para um repositório de políticas com uma fonte de identidade OIDC. ``` "User": { "shape": { "type": "Record", "attributes": { "email": { "type": "String" }, "email_verified": { "type": "Boolean" }, "name": { "type": "String", "required": true }, "phone_number": { "type": "String" }, "phone_number_verified": { "type": "Boolean" } } } } ``` Para obter um exemplo de política que será validada em relação a esse esquema, consulte. [Reflete os atributos do token de ID OIDC](policies-examples.md#policies-examples-oidc-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. A maioria dos tokens de acesso de provedores externos do OIDC se alinha estreitamente aos Amazon Cognito tokens de acesso. Um token de acesso OIDC é 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 OIDC a seguir inclui exemplos de declarações básicas. ``` { "sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e", "groups": [ "Store-Owner-Role", "Customer" ], "iss": "https://auth.example.com", "client_id": "1example23456789", "aud": "https://myapplication.example.com" "scope": "MyAPI-Read", "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 acesso OIDC](policies-examples.md#policies-examples-oidc-access) ## 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](#oidc-map-access-token). **Os grupos do OIDC afirmam que suporta vários formatos** Ao adicionar um provedor OIDC, você pode escolher o nome da reivindicação do grupo em ID ou tokens de acesso que deseja mapear para a associação de um usuário ao grupo em seu repositório de políticas. As permissões verificadas reconhecem as reivindicações de grupos nos seguintes formatos: 1. Cadeia de caracteres sem espaços: `"groups": "MyGroup"` 1. Lista delimitada por espaço:. `"groups": "MyGroup1 MyGroup2 MyGroup3"` Cada string é um grupo. 1. Lista JSON (delimitada por vírgula): `"groups": ["MyGroup1", "MyGroup2", "MyGroup3"]` **nota** As Permissões verificadas interpretam cada string em uma declaração de grupos separados por espaço como um grupo separado. Para interpretar um nome de grupo com um caractere de espaço como um único grupo, substitua ou remova o espaço na declaração. Por exemplo, formate um grupo chamado `My Group` como`MyGroup`. **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 OIDC, você deve escolher um tipo de token ao adicionar a fonte de identidade. Você pode escolher ID ou token de acesso, e sua escolha exclui que o tipo de token não escolhido seja processado em seu repositório de políticas. 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 fornecedores de OIDC 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. Os tokens de ID do OIDC têm uma `aud` reivindicação que contém o cliente IDs, como. `1example23456789` Os tokens de acesso do OIDC têm uma `aud` declaração que contém a URL do público do token, como`https://myapplication.example.com`, e uma `client_id` afirmação que contém o cliente IDs, como. `1example23456789` Ao configurar seu repositório de políticas, insira um ou mais valores para **validação de público** que seu armazenamento de políticas usa para validar o público de um token. + **Tokens de ID** — As permissões verificadas validam o ID do cliente verificando se pelo menos um membro do cliente IDs na `aud` reivindicação corresponde a um valor de validação de público. + **Tokens de acesso** — as permissões verificadas validam o público verificando se o URL na `aud` declaração corresponde a um valor de validação do público. Se nenhuma `aud` reivindicação existir, o público poderá ser validado usando as `client_id` reivindicações `cid` ou. Verifique com seu provedor de identidade a afirmação e o formato corretos do público. ## 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.