Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Proteggi le tue applicazioni con fonti di identità e token Proteggi rapidamente le tue applicazioni creando una *fonte di identità* per rappresentare un provider di identità esterno (IdP) in Amazon Verified Permissions. Le fonti di identità forniscono informazioni su un utente che si è autenticato con un IdP che ha una relazione di fiducia con il tuo policy store. Quando l'applicazione effettua una richiesta di autorizzazione con un token proveniente da una fonte di identità, il policy store può prendere decisioni di autorizzazione sulla base delle proprietà dell'utente e delle autorizzazioni di accesso. Puoi aggiungere un pool di utenti Amazon Cognito o un IdP OpenID Connect (OIDC) personalizzato come fonte di identità. Puoi utilizzare i provider di identità [OpenID Connect (OIDC) ()](https://openid.net/specs/openid-connect-core-1_0.html) con autorizzazioni IdPs verificate. La tua applicazione può generare richieste di autorizzazione con token web JSON (JWTs) generati da un provider di identità conforme a OIDC. L'identità dell'utente nel token è mappata all'ID principale. Con i token ID, Verified Permissions associa le rivendicazioni degli attributi agli attributi principali. [Con i token di accesso, queste affermazioni vengono mappate in base al contesto.](context.md) Con entrambi i tipi di token, puoi mappare un claim come se fosse `groups` un gruppo principale e creare policy che valutino il controllo degli accessi basato sui ruoli (RBAC). **Nota** Verified Permissions prende decisioni di autorizzazione sulla base delle informazioni di un token IdP ma non interagisce direttamente con l'IdP in alcun modo. *Per una step-by-step procedura dettagliata che crea una logica di autorizzazione per Amazon API Gateway REST APIs utilizzando un pool di Amazon Cognito utenti o un provider di identità OIDC, consulta Autorizza [utilizzando API Gateway APIs Amazon Verified Permissions with Amazon Cognito or bring your own](https://aws.amazon.com/blogs/security/authorize-api-gateway-apis-using-amazon-verified-permissions-and-amazon-cognito/) identity provider sul Security Blog.AWS * **Topics** + [Scelta del provider di identità giusto](#choosing-identity-source) + [Lavorare con le fonti di Amazon Cognito identità](identity-sources-cognito.md) + [Utilizzo delle fonti di identità OIDC](identity-sources-oidc.md) ## Scelta del provider di identità giusto Sebbene Verified Permissions funzioni con una varietà di autorizzazioni IdPs, tieni presente quanto segue quando decidi quale utilizzare nella tua applicazione: Da utilizzare quando Amazon Cognito : + Stai creando nuove applicazioni senza l'infrastruttura di identità esistente + Desideri pool AWS di utenti gestiti con funzionalità di sicurezza integrate + È necessaria l'integrazione con un provider di identità social + Desideri una gestione semplificata dei token Utilizza i provider OIDC quando: + Hai un'infrastruttura di identità esistente (Auth0, Okta, Azure AD) + È necessario mantenere una gestione centralizzata degli utenti + Hai requisiti di conformità per specifici IdPs # Lavorare con le fonti di Amazon Cognito identità Verified Permissions lavora a stretto contatto con i pool di utenti di Amazon Cognito. Amazon Cognito JWTs hanno una struttura prevedibile. Verified Permissions riconosce questa struttura e trae il massimo beneficio dalle informazioni in essa contenute. Ad esempio, è possibile implementare un modello di autorizzazione per il controllo degli accessi basato sui ruoli (RBAC) con token ID o token di accesso. Una nuova fonte di identità per i pool di utenti di Amazon Cognito richiede le seguenti informazioni: + Il Regione AWS. + L'ID pool di utenti. + Il tipo di entità principale che desideri associare alla fonte della tua identità, ad esempio`MyCorp::User`. + Il tipo di entità di gruppo principale che desideri associare alla tua fonte di identità, ad esempio`MyCorp::UserGroup`. + Il client IDs del tuo pool di utenti che desideri autorizzare a effettuare richieste al tuo policy store. Poiché Verified Permissions funziona solo con i pool di utenti di Amazon Cognito nello Account AWS stesso account, non puoi specificare una fonte di identità in un altro account. Verified Permissions imposta il *prefisso dell'entità*, l'identificatore dell'identità e della fonte a cui devi fare riferimento nelle politiche che agiscono sui principali del pool di utenti, all'ID del tuo pool di utenti, ad esempio. `us-west-2_EXAMPLE` In questo caso, faresti riferimento a un utente in quel pool di utenti con ID come `a1b2c3d4-5678-90ab-cdef-EXAMPLE22222` `us-west-2_EXAMPLE|a1b2c3d4-5678-90ab-cdef-EXAMPLE22222` Le *dichiarazioni relative* ai token del pool di utenti possono contenere attributi, ambiti, gruppi IDs, client e dati personalizzati. [Amazon Cognito JWTs](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)hanno la capacità di includere una varietà di informazioni che possono contribuire alle decisioni di autorizzazione nelle autorizzazioni verificate. Ciò include: 1. Nome utente e affermazioni di gruppo con prefisso `cognito:` 1. [Attributi utente personalizzati](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-custom-attributes) con un `custom: prefix` 1. Affermazioni personalizzate aggiunte in fase di esecuzione 1. Dichiarazioni standard OIDC come e `sub` `email` Tratteremo in dettaglio queste affermazioni e come gestirle nelle politiche sulle autorizzazioni verificate, in. [Mappatura dei Amazon Cognito token sullo schema](cognito-map-token-to-schema.md) **Importante** Sebbene sia possibile revocare Amazon Cognito i token prima della scadenza, JWTs sono considerati risorse stateless, autonome e dotate di firma e validità. I servizi conformi [al token Web JSON RFC 7519 dovrebbero convalidare i token](https://datatracker.ietf.org/doc/html/rfc7519) in remoto e non sono tenuti a convalidarli con l'emittente. Ciò significa che è possibile che Verified Permissions conceda l'accesso in base a un token revocato o rilasciato a un utente che è stato successivamente eliminato. Per mitigare questo rischio, ti consigliamo di creare i token con la durata di validità più breve possibile e di revocare i token di aggiornamento quando desideri rimuovere l'autorizzazione a continuare la sessione di un utente. [Per ulteriori informazioni, consulta Terminare le sessioni utente con revoca dei token](https://docs.aws.amazon.com/cognito/latest/developerguide/token-revocation.html) L'esempio seguente mostra come creare una policy che faccia riferimento ad alcune delle dichiarazioni dei pool di utenti di Amazon Cognito associate a un'entità principale. ``` permit( principal, action, resource == ExampleCo::Photo::"VacationPhoto94.jpg" ) when { principal["cognito:username"]) == "alice" && principal["custom:department"]) == "Finance" }; ``` L'esempio seguente mostra come creare una politica che faccia riferimento a un principale che è un utente in un pool di utenti di Cognito. Nota che l'ID principale assume la forma di`"|"`. ``` permit( principal == ExampleCo::User::"us-east-1_example|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", action, resource == ExampleCo::Photo::"VacationPhoto94.jpg" ); ``` Le politiche Cedar per le fonti di identità del pool di utenti in Verified Permissions utilizzano una sintassi speciale per i nomi delle rivendicazioni che contengono caratteri diversi da quelli alfanumerici e dal carattere di sottolineatura (). `_` Ciò include le dichiarazioni di prefisso del pool di utenti che contengono un carattere, come e. `:` `cognito:username` `custom:department` Per scrivere una condizione politica che faccia riferimento al `custom:department` claim `cognito:username` o, scrivila rispettivamente come `principal["cognito:username"]` e`principal["custom:department"]`. **Nota** Se un token contiene un'attestazione con un `custom:` prefisso `cognito:` or e un nome di attestazione con valore letterale `cognito` o`custom`, una richiesta di autorizzazione con [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)un. `ValidationException` Per ulteriori informazioni sulla mappatura delle attestazioni, consulta. [Mappatura dei Amazon Cognito token sullo schema](cognito-map-token-to-schema.md) Per ulteriori informazioni sull'autorizzazione per Amazon Cognito gli utenti, consulta [Authorization with Amazon Verified Permissions](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) nella *Amazon Cognito* Developer Guide. **Topics** + [Creazione di fonti di Amazon Cognito identità Amazon Verified Permissions](cognito-create.md) + [Modifica delle fonti di Amazon Cognito identità di Amazon Verified Permissions](cognito-edit.md) + [Mappatura dei Amazon Cognito token sullo schema](cognito-map-token-to-schema.md) + [Convalida di clienti e destinatari per Amazon Cognito](cognito-validation.md) # Creazione di fonti di Amazon Cognito identità Amazon Verified Permissions La procedura seguente aggiunge un'origine di identità a un archivio di politiche esistente. È inoltre possibile creare un'origine di identità quando si [crea un nuovo archivio di politiche](policy-stores-create.md) nella console Autorizzazioni verificate. In questo processo, puoi importare automaticamente le attestazioni contenute nei token di origine dell'identità negli attributi dell'entità. Scegli l'opzione **Configurazione guidata** o **Configura con API Gateway e un provider di identità**. Queste opzioni creano anche politiche iniziali. **Nota** **Le fonti di identità** non sono disponibili nel riquadro di navigazione a sinistra fino a quando non è stato creato un archivio delle politiche. Le fonti di identità create sono associate al policy store corrente. Puoi omettere il tipo di entità principale quando crei una fonte di identità con AWS CLI o [create-identity-source[CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)](https://docs.aws.amazon.com/cli/latest/reference/verifiedpermissions/create-identity-source.html)nell'API Verified Permissions. Tuttavia, un tipo di entità vuoto crea una fonte di identità con un tipo di entità di`AWS::Cognito`. Questo nome di entità non è compatibile con lo schema dell'archivio delle politiche. Per integrare Amazon Cognito le identità con lo schema dell'archivio delle politiche, è necessario impostare il tipo di entità principale su un'entità dell'archivio delle politiche supportata. ------ #### [ Console di gestione AWS ] **Per creare una fonte di identità per pool di utenti Amazon Cognito** 1. Apri la console delle [autorizzazioni verificate](https://console.aws.amazon.com/verifiedpermissions/). Scegli il tuo negozio di polizze. 1. Nel riquadro di navigazione a sinistra, scegli **Identity sources**. 1. Scegli **Crea fonte di identità**. 1. Nei **dettagli del pool di utenti di Cognito**, seleziona Regione AWS e inserisci l'**ID del pool di utenti** per la tua origine di identità. 1. Nella **configurazione principale**, per **Tipo principale**, scegli il tipo di entità per i principali da questa fonte. Le identità dei pool di utenti Amazon Cognito connessi verranno mappate sul tipo principale selezionato. 1. Nella **configurazione del gruppo**, seleziona **Usa il gruppo Cognito** se desideri mappare il claim del pool `cognito:groups` di utenti. Scegli un tipo di entità che sia padre del tipo principale. 1. In **Convalida dell'applicazione client**, scegli se convalidare l'applicazione client. IDs + Per convalidare l'applicazione client IDs, scegli **Accetta solo token con** l'applicazione client corrispondente. IDs Scegli **Aggiungi nuovo ID dell'applicazione client per ogni ID dell'**applicazione client da convalidare. Per rimuovere un ID dell'applicazione client che è stato aggiunto, scegli **Rimuovi** accanto all'ID dell'applicazione client. + Scegliete **Non convalidare l'applicazione client IDs** se non desiderate convalidare l'applicazione client. IDs 1. Scegli **Crea origine di identità**. 1. (Facoltativo) Se il vostro policy store dispone di uno schema, prima di poter fare riferimento agli attributi estratti dall'identità o dai token di accesso nelle policy Cedar, dovete aggiornare lo schema per rendere Cedar consapevole del tipo di principale creato dalla vostra fonte di identità. Tale aggiunta allo schema deve includere gli attributi a cui desiderate fare riferimento nelle vostre politiche Cedar. Per ulteriori informazioni sulla mappatura degli attributi dei Amazon Cognito token agli attributi principali di Cedar, vedere. [Mappatura dei Amazon Cognito token sullo schema](cognito-map-token-to-schema.md) **Nota** Quando crei un [policy store collegato all'API](policy-stores-api-userpool.md) o utilizzi **Set up with API Gateway e un provider di identità** durante la creazione di policy store, Verified Permissions interroga il pool di utenti per gli attributi utente e crea uno schema in cui il tipo principale è popolato con gli attributi del pool di utenti. 1. Crea politiche che utilizzano le informazioni dei token per prendere decisioni di autorizzazione. Per ulteriori informazioni, consulta [Creazione di politiche statiche di Amazon Verified Permissions](policies-create.md). Ora che hai creato una fonte di identità, aggiornato lo schema e creato le politiche, consenti `IsAuthorizedWithToken` alle Autorizzazioni Verificate di prendere decisioni di autorizzazione. Per ulteriori informazioni, consulta [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)la *guida di riferimento dell'API Amazon Verified Permissions*. ------ #### [ AWS CLI ] **Per creare una fonte di identità per pool di utenti Amazon Cognito** Puoi creare una fonte di identità utilizzando l'[CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)operazione. L'esempio seguente crea un'origine di identità in grado di accedere alle identità autenticate da un pool di Amazon Cognito utenti. 1. Crea un `config.txt` file che contenga i seguenti dettagli del pool di Amazon Cognito utenti da utilizzare con il `--configuration` parametro del comando. `create-identity-source` ``` { "cognitoUserPoolConfiguration": { "userPoolArn": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_1a2b3c4d5", "clientIds":["a1b2c3d4e5f6g7h8i9j0kalbmc"], "groupConfiguration": { "groupEntityType": "MyCorp::UserGroup" } } } ``` 1. Esegui il comando seguente per creare una fonte di Amazon Cognito identità. ``` $ 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. (Facoltativo) Se il vostro policy store dispone di uno schema, prima di poter fare riferimento agli attributi che estraete dall'identità o dai token di accesso nelle vostre policy Cedar, dovete aggiornare lo schema per rendere Cedar consapevole del tipo di principale creato dalla vostra fonte di identità. Tale aggiunta allo schema deve includere gli attributi a cui desiderate fare riferimento nelle vostre politiche Cedar. Per ulteriori informazioni sulla mappatura degli attributi dei Amazon Cognito token agli attributi principali di Cedar, vedere. [Mappatura dei Amazon Cognito token sullo schema](cognito-map-token-to-schema.md) **Nota** Quando crei un [policy store collegato all'API](policy-stores-api-userpool.md) o utilizzi **Set up with API Gateway e un provider di identità** durante la creazione di policy store, Verified Permissions interroga il pool di utenti per gli attributi utente e crea uno schema in cui il tipo principale è popolato con gli attributi del pool di utenti. 1. Crea politiche che utilizzano le informazioni dei token per prendere decisioni di autorizzazione. Per ulteriori informazioni, consulta [Creazione di politiche statiche di Amazon Verified Permissions](policies-create.md). Ora che hai creato una fonte di identità, aggiornato lo schema e creato le politiche, consenti `IsAuthorizedWithToken` alle Autorizzazioni Verificate di prendere decisioni di autorizzazione. Per ulteriori informazioni, consulta [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)la *guida di riferimento dell'API Amazon Verified Permissions*. ------ *Per ulteriori informazioni sull'utilizzo dei token di accesso e identità di Amazon Cognito per gli utenti autenticati in Autorizzazioni verificate, consulta Authorization [with Amazon Verified Permissions nella Amazon Cognito Developer](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) Guide.* # Modifica delle fonti di Amazon Cognito identità di Amazon Verified Permissions Puoi modificare alcuni parametri della tua fonte di identità dopo averla creata. Non puoi cambiare il tipo di fonte di identità, devi eliminare l'origine dell'identità e crearne una nuova da cui passare Amazon Cognito a OIDC o OIDC. Amazon Cognito Se lo schema del policy store corrisponde agli attributi della fonte di identità, tieni presente che devi aggiornare lo schema separatamente per riflettere le modifiche apportate alla tua origine di identità. ------ #### [ Console di gestione AWS ] **Per aggiornare una fonte di Amazon Cognito identità** 1. Apri la [console delle autorizzazioni verificate](https://console.aws.amazon.com/verifiedpermissions/). Scegli il tuo negozio di polizze. 1. Nel riquadro di navigazione a sinistra, scegli **Identity sources**. 1. Scegli l'ID della fonte di identità da modificare. 1. Scegli **Modifica**. 1. Nei **dettagli del pool di utenti di Cognito**, seleziona Regione AWS e digita l'**ID del pool di utenti** per la tua origine di identità. 1. Nei **dettagli del principale**, puoi aggiornare il **tipo di Principal** per la fonte dell'identità. Le identità dei pool di utenti Amazon Cognito connessi verranno mappate sul tipo principale selezionato. 1. Nella **configurazione del gruppo**, seleziona **Usa i gruppi di Cognito** se desideri mappare la dichiarazione del pool `cognito:groups` di utenti. Scegli un tipo di entità che sia padre del tipo principale. 1. In **Convalida dell'applicazione client**, scegli se convalidare l'applicazione client. IDs + Per convalidare l'applicazione client IDs, scegli **Accetta solo token con** l'applicazione client corrispondente. IDs Scegli **Aggiungi nuovo ID dell'applicazione client per ogni ID dell'**applicazione client da convalidare. Per rimuovere un ID dell'applicazione client che è stato aggiunto, scegli **Rimuovi** accanto all'ID dell'applicazione client. + Scegliete **Non convalidare l'applicazione client IDs** se non desiderate convalidare l'applicazione client. IDs 1. Scegli **Save changes** (Salva modifiche). 1. Se hai modificato il tipo principale per l'origine dell'identità, devi aggiornare lo schema in modo che rifletta correttamente il tipo principale aggiornato. È possibile eliminare una fonte di identità scegliendo il pulsante di opzione accanto a una fonte di identità e quindi scegliendo **Elimina fonte di identità**. Digita `delete` nella casella di testo, quindi scegli **Elimina fonte di identità** per confermare l'eliminazione della fonte di identità. ------ #### [ AWS CLI ] **Per aggiornare una fonte di Amazon Cognito identità** È possibile aggiornare una fonte di identità utilizzando l'[UpdateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_UpdateIdentitySource.html)operazione. L'esempio seguente aggiorna l'origine di identità specificata per utilizzare un pool di Amazon Cognito utenti diverso. 1. Create un `config.txt` file che contenga i seguenti dettagli del pool di Amazon Cognito utenti da utilizzare con il `--configuration` parametro del `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. Esegui il comando seguente per aggiornare una fonte di Amazon Cognito identità. ``` $ 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 si modifica il tipo principale per l'origine dell'identità, è necessario aggiornare lo schema in modo che rifletta correttamente il tipo principale aggiornato. ------ # Mappatura dei Amazon Cognito token sullo schema Potresti scoprire di voler aggiungere una fonte di identità a un archivio delle politiche e mappare le attestazioni, o token, del provider allo schema del tuo archivio delle politiche. È possibile automatizzare questo processo utilizzando la [configurazione guidata](policy-stores-create.md) per creare il proprio Policy Store con una fonte di identità o aggiornare lo schema manualmente dopo la creazione del Policy Store. Dopo aver mappato i token allo schema, è possibile creare policy che vi fanno riferimento. Questa sezione della guida per l'utente contiene le seguenti informazioni: + Quando è possibile compilare automaticamente gli attributi in uno schema di policy store + Come utilizzare le attestazioni relative ai Amazon Cognito token nelle politiche relative alle autorizzazioni verificate + Come creare manualmente uno schema per una fonte di identità Gli archivi di [policy collegati alle API](policy-stores-api-userpool.md) e gli archivi di policy con una fonte di identità creati tramite la [configurazione guidata](policy-stores-create.md) non richiedono la mappatura manuale degli attributi del token di identità (ID) allo schema. Puoi fornire autorizzazioni verificate con gli attributi del tuo pool di utenti e creare uno schema popolato con attributi utente. Nell'autorizzazione con token ID, Verified Permissions associa le rivendicazioni agli attributi di un'entità principale. Potrebbe essere necessario mappare manualmente Amazon Cognito i token allo schema nelle seguenti condizioni: + È stato creato un policy store o un policy store vuoto a partire da un esempio. + Desiderate estendere l'uso dei token di accesso oltre il controllo degli accessi basato sui ruoli (RBAC). + Puoi creare archivi di policy con l'API REST di Verified Permissions, un SDK o il. AWS AWS CDK Per utilizzarli Amazon Cognito come fonte di identità nel tuo archivio di policy per le autorizzazioni verificate, devi avere gli attributi del provider nello schema. Lo schema è fisso e deve corrispondere alle entità create dai token del provider [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)o alle richieste [BatchIsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_BatchIsAuthorizedWithToken.html)API. Se hai creato il tuo archivio delle politiche in modo da compilare automaticamente lo schema con le informazioni del provider in un token ID, sei pronto per scrivere le policy. Se crei un policy store senza uno schema per la tua origine di identità, devi aggiungere gli attributi del provider allo schema che corrispondono alle entità create utilizzando le richieste API. È quindi possibile scrivere politiche utilizzando gli attributi del token del provider. *Per ulteriori informazioni sull'utilizzo dell'ID Amazon Cognito e dei token di accesso per gli utenti autenticati in Autorizzazioni verificate, consulta Authorization [with Amazon Verified Permissions nella Amazon Cognito Developer](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) Guide.* **Topics** + [Mappatura dei token ID allo schema](#cognito-map-id-token) + [Mappatura dei token di accesso](#cognito-map-access-token) + [Notazione alternativa per Amazon Cognito affermazioni delimitate da due punti](#cognito-colon-claims) + [Cose da sapere sulla mappatura degli schemi](#cognito-map-token-to-schema-things-to-know) ## Mappatura dei token ID allo schema Verified Permissions elabora le dichiarazioni relative ai token ID come attributi dell'utente: nomi e titoli, appartenenza al gruppo, informazioni di contatto. I token ID sono molto utili in un modello di autorizzazione ABAC (*Attribute-Based Access Control*). Se desideri che le autorizzazioni verificate analizzino l'accesso alle risorse in base a chi effettua la richiesta, scegli i token ID come fonte della tua identità. Amazon Cognito I token ID funzionano con la maggior parte delle librerie relying-party [OIDC](https://openid.net/developers/certified-openid-connect-implementations/). Estendono le funzionalità di OIDC con affermazioni aggiuntive. L'applicazione può autenticare l'utente con le operazioni API di autenticazione dei pool di utenti di Amazon Cognito o con l'interfaccia utente ospitata dal pool di utenti. *Per ulteriori informazioni, consulta [Using the API and endpoints](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pools-API-operations.html) nella Developer Guide.Amazon Cognito *Dichiarazioni utili nei token Amazon Cognito ID *`cognito:username` e `preferred_username`* Varianti del nome utente dell'utente. *`sub`* L'identificatore utente univoco (UUID) dell'utente *Affermazioni con un prefisso `custom:`* Un prefisso per attributi personalizzati del pool di utenti come. `custom:employmentStoreCode` *Affermazioni standard* Dichiarazioni OIDC standard come `email` e. `phone_number` Per ulteriori informazioni, consulta [Dichiarazioni standard](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) in *OpenID Connect Core 1.0 che incorporano il set di errata 2*. *`cognito:groups`* Appartenenze ai gruppi di un utente. In un modello di autorizzazione basato sul controllo degli accessi basato sui ruoli (RBAC), questa dichiarazione presenta i ruoli che è possibile valutare nelle politiche. *Reclami transitori* Affermazioni che non sono di proprietà dell'utente, ma vengono aggiunte in fase di esecuzione da un trigger [Lambda prima della generazione di token](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html) del pool di utenti. Le affermazioni transitorie assomigliano alle affermazioni standard ma non rientrano nello standard, ad esempio o. `tenant` `department` Nelle politiche che fanno riferimento Amazon Cognito agli attributi che dispongono di un `:` separatore, fate riferimento agli attributi nel formato. `principal["cognito:username"]` L'affermazione dei ruoli `cognito:groups` è un'eccezione a questa regola. Verified Permissions associa il contenuto di questa dichiarazione alle entità principali dell'entità utente. *Per ulteriori informazioni sulla struttura dei token ID dei pool di utenti di Amazon Cognito, [consulta Using the ID](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html) token nella Amazon Cognito Developer Guide.* Il seguente esempio di token ID ha ciascuno dei quattro tipi di attributi. Include l' Amazon Cognito attestazione specifica`cognito:username`, l'attestazione personalizzata`custom:employmentStoreCode`, l'attestazione standard e l'`email`attestazione transitoria. `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" } ``` Quando crei una fonte di identità con il tuo pool di Amazon Cognito utenti, specifichi il tipo di entità principale con cui Verified Permissions genera le richieste di autorizzazione. `IsAuthorizedWithToken` Le tue politiche possono quindi testare gli attributi di tale principale come parte della valutazione della richiesta. Lo schema definisce il tipo e gli attributi principali per una fonte di identità, quindi è possibile farvi riferimento nelle politiche Cedar. Specificate anche il tipo di entità di gruppo che desiderate derivare dal claim ID Token Groups. Nelle richieste di autorizzazione, Verified Permissions associa ogni membro della dichiarazione di gruppo a quel tipo di entità di gruppo. Nelle politiche, puoi fare riferimento a quell'entità di gruppo come principale. L'esempio seguente mostra come riflettere gli attributi del token di identità di esempio nello schema di autorizzazioni verificate. Per ulteriori informazioni sulla modifica dello schema, consulta[Modifica degli schemi di archiviazione delle politiche](schema-edit.md). Se la configurazione dell'origine dell'identità specifica il tipo principale`User`, puoi includere qualcosa di simile al seguente esempio per rendere tali attributi disponibili a 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 } } } } ``` Per un esempio di politica che verrà convalidata in base a questo schema, vedi. [Riflette gli attributi del token ID Amazon Cognito](policies-examples.md#policies-examples-cognito-id) ## Mappatura dei token di accesso *Verified Permissions elabora le dichiarazioni dei token di accesso diverse da quelle dichiarate dai gruppi come attributi dell'azione o attributi di contesto.* Oltre all'appartenenza al gruppo, i token di accesso del tuo IdP potrebbero contenere informazioni sull'accesso alle API. I token di accesso sono utili nei modelli di autorizzazione che utilizzano il controllo degli accessi basato sui ruoli (RBAC). I modelli di autorizzazione che si basano su richieste di token di accesso diverse dall'appartenenza al gruppo richiedono uno sforzo aggiuntivo nella configurazione dello schema. Amazon Cognito i token di accesso hanno affermazioni che possono essere utilizzate per l'autorizzazione:Affermazioni utili nei token di Amazon Cognito accesso *`client_id`* L'ID dell'applicazione client di un relying party dell'OIDC. Con l'ID client, Verified Permissions può verificare che la richiesta di autorizzazione provenga da un client autorizzato per il policy store. Nell'autorizzazione machine-to-machine (M2M), il sistema richiedente autorizza una richiesta con un segreto del cliente e fornisce l'ID e gli ambiti del client come prova dell'autorizzazione. *`scope`* Gli [ambiti OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) che rappresentano i permessi di accesso del portatore del token. *`cognito:groups`* Appartenenze ai gruppi di un utente. In un modello di autorizzazione basato sul controllo degli accessi basato sui ruoli (RBAC), questa dichiarazione presenta i ruoli che è possibile valutare nelle politiche. *Reclami transitori* Affermazioni che non sono un'autorizzazione di accesso, ma vengono aggiunte in fase di esecuzione da un trigger [Lambda di generazione precedente al token](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html) di un pool di utenti. Le affermazioni transitorie assomigliano alle affermazioni standard ma non rientrano nello standard, ad esempio o. `tenant` `department` La personalizzazione dei token di accesso aggiunge costi alla bolletta. AWS *Per ulteriori informazioni sulla struttura dei token di accesso dei pool di utenti di Amazon Cognito, [consulta Using the access](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html) token nella Amazon Cognito Developer Guide.* Un token di Amazon Cognito accesso viene mappato su un oggetto di contesto quando viene passato a Verified Permissions. È possibile fare riferimento agli attributi del token di accesso utilizzando. `context.token.attribute_name` Il token di accesso di esempio seguente include sia le `client_id` `scope` attestazioni che. ``` { "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" } ``` L'esempio seguente mostra come riflettere gli attributi del token di accesso di esempio nello schema di autorizzazioni verificate. Per ulteriori informazioni sulla modifica dello schema, consulta[Modifica degli schemi di archiviazione delle politiche](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" } } } } ``` Per un esempio di politica che verrà convalidata in base a questo schema, vedi[Riflette gli attributi dei token di accesso Amazon Cognito](policies-examples.md#policies-examples-cognito-access). ## Notazione alternativa per Amazon Cognito affermazioni delimitate da due punti Al momento del lancio di Verified Permissions, lo schema consigliato per le attestazioni dei Amazon Cognito token includeva `cognito:groups` e `custom:store` convertiva queste stringhe delimitate da due punti in modo che utilizzassero il carattere come delimitatore gerarchico. `.` *Questo* formato è chiamato notazione a punti. Ad esempio, un riferimento a `cognito:groups` became `principal.cognito.groups` nelle tue politiche. Sebbene sia possibile continuare a utilizzare questo formato, si consiglia di creare lo schema e le politiche utilizzando la [notazione tra parentesi](#cognito-map-token-to-schema-things-to-know). In questo formato, un riferimento a `cognito:groups` diventa `principal["cognito:groups"]` nelle tue politiche. Gli schemi generati automaticamente per i token ID del pool di utenti dalla console Verified Permissions utilizzano la notazione tra parentesi. Puoi continuare a utilizzare la notazione a punti negli schemi e nelle policy creati manualmente per le fonti di identità. Amazon Cognito Non puoi utilizzare la notazione a punti con `:` o qualsiasi altro carattere non alfanumerico nello schema o nelle politiche per nessun altro tipo di IdP OIDC. Uno schema per la notazione a punti annida ogni istanza di un `:` carattere come elemento secondario della frase `cognito` o `custom` iniziale, come illustrato nell'esempio seguente: ``` "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 } } } } ``` Per un esempio di politica che verrà convalidata in base a questo schema e utilizzerà la notazione a punti, vedere. [Utilizza la notazione a punti per fare riferimento agli attributi](policies-examples.md#policies-examples-dot) ## Cose da sapere sulla mappatura degli schemi **La mappatura degli attributi differisce tra i tipi di token** [Nell'autorizzazione del token di accesso, Verified Permissions mappa le rivendicazioni in base al contesto.](context.md) Nell'autorizzazione tramite token ID, Verified Permissions associa le rivendicazioni agli attributi principali. Per i policy store creati nella console Verified Permissions, solo gli archivi di policy **vuoti** e di **esempio** non lasciano alcuna fonte di identità e richiedono di compilare lo schema con gli attributi del pool di utenti per l'autorizzazione del token ID. L'autorizzazione dei token di accesso si basa sul controllo degli accessi basato sui ruoli (RBAC) con attestazioni di appartenenza al gruppo e non associa automaticamente altre attestazioni allo schema del policy store. **Gli attributi di origine dell'identità non sono obbligatori** Quando crei una fonte di identità nella console Autorizzazioni verificate, nessun attributo viene contrassegnato come obbligatorio. In questo modo si evita che le attestazioni mancanti causino errori di convalida nelle richieste di autorizzazione. È possibile impostare gli attributi come obbligatori in base alle esigenze, ma devono essere presenti in tutte le richieste di autorizzazione. **RBAC non richiede attributi nello schema** Gli schemi per le fonti di identità dipendono dalle associazioni di entità che si creano quando si aggiunge la fonte di identità. Un'origine di identità associa un'attestazione a un tipo di entità utente e un'affermazione a un tipo di entità di gruppo. Queste mappature di entità sono il fulcro di una configurazione di origine dell'identità. Con queste informazioni minime, è possibile scrivere politiche che eseguano azioni di autorizzazione per utenti specifici e gruppi specifici di cui gli utenti potrebbero essere membri, in un modello di controllo degli accessi basato sul ruolo (RBAC). L'aggiunta di attestazioni di token allo schema estende l'ambito di autorizzazione del policy store. Gli attributi utente dei token ID contengono informazioni sugli utenti che possono contribuire all'autorizzazione del controllo degli accessi basato sugli attributi (ABAC). Gli attributi di contesto dei token di accesso contengono informazioni come gli ambiti OAuth 2.0 che possono fornire ulteriori informazioni sul controllo degli accessi fornite dal provider, ma richiedono ulteriori modifiche allo schema. Le opzioni **Configura con API Gateway e un provider di identità** e **Configurazione guidata** nella console Autorizzazioni verificate assegnano le attestazioni del token ID allo schema. Questo non è il caso delle rivendicazioni relative ai token di accesso. [Per aggiungere attestazioni di token di accesso non di gruppo allo schema, è necessario modificare lo schema in modalità JSON e aggiungere gli attributi CommonTypes.](https://docs.cedarpolicy.com/schema/json-schema.html#schema-commonTypes) Per ulteriori informazioni, consulta [Mappatura dei token di accesso](#cognito-map-access-token). **Scegli un tipo di token** Il modo in cui il policy store funziona con la fonte di identità dipende da una decisione chiave nella configurazione dell'origine dell'identità: se elaborare gli ID o i token di accesso. Con un provider di Amazon Cognito identità, puoi scegliere il tipo di token quando crei un policy store collegato all'API. Quando crei un [policy store collegato all'API](policy-stores-api-userpool.md), devi scegliere se configurare l'autorizzazione per l'ID o i token di accesso. Queste informazioni influiscono sugli attributi dello schema che Verified Permissions applica al tuo policy store e sulla sintassi dell'autorizzatore Lambda per la tua API. API Gateway Soprattutto se desideri trarre vantaggio dalla mappatura automatica delle dichiarazioni dei token ID agli attributi nella console Verified Permissions, decidi in anticipo il tipo di token che desideri elaborare prima di creare la fonte dell'identità. La modifica del tipo di token richiede uno sforzo significativo per rifattorizzare le politiche e lo schema. I seguenti argomenti descrivono l'uso degli ID e dei token di accesso con gli archivi delle politiche. **Cedar parser richiede parentesi per alcuni caratteri** Le politiche in genere fanno riferimento agli attributi dello schema in un formato simile. `principal.username` Nel caso della maggior parte dei caratteri non alfanumerici come `:``.`, o `/` che potrebbero apparire nei nomi delle rivendicazioni dei token, Verified Permissions non è in grado di analizzare un valore di condizione come o. `principal.cognito:username` `context.ip-address` È invece necessario formattare queste condizioni con la notazione tra parentesi nel formato o, rispettivamente. `principal["cognito:username"]` `context["ip-address"]` Il carattere di sottolineatura `_` è un carattere valido nei nomi delle rivendicazioni e rappresenta l'unica eccezione non alfanumerica a questo requisito. Uno schema di esempio parziale per un attributo principale di questo tipo è simile al seguente: ``` "User": { "shape": { "type": "Record", "attributes": { "cognito:username": { "type": "String", "required": true }, "custom:employmentStoreCode": { "type": "String", "required": true, }, "email": { "type": "String", "required": false } } } } ``` Uno schema di esempio parziale per un attributo di contesto di questo tipo è simile al seguente: ``` "GetOrder": { "memberOf": [], "appliesTo": { "resourceTypes": [ "Order" ], "context": { "type": "Record", "attributes": { "ip-address": { "required": false, "type": "String" } } }, "principalTypes": [ "User" ] } } ``` Per un esempio di politica che verrà convalidata rispetto a questo schema, vedi[Utilizza la notazione tra parentesi per fare riferimento agli attributi del token](policies-examples.md#policies-examples-brackets). # Convalida di clienti e destinatari per Amazon Cognito Quando si aggiunge una fonte di identità a un policy store, Verified Permissions dispone di opzioni di configurazione che verificano che l'ID e i token di accesso vengano utilizzati come previsto. Questa convalida avviene durante l'elaborazione delle richieste API`IsAuthorizedWithToken`. `BatchIsAuthorizedWithToken` Il comportamento differisce tra ID e token di accesso Amazon Cognito e tra fonti di identità OIDC. Con i provider di pool di utenti di Amazon Cognito, Verified Permissions può convalidare l'ID client sia nell'ID che nei token di accesso. Con i provider OIDC, Verified Permissions può convalidare l'ID client nei token ID e il pubblico nei token di accesso. Un *ID client* è un identificatore associato all'istanza del provider di identità utilizzata dall'applicazione, ad esempio. `1example23456789` Un *pubblico* è un percorso URL associato al *relying party*, o destinazione, previsto per il token di accesso, ad esempio. `https://mytoken.example.com` Quando si utilizzano i token di accesso, l'`aud`affermazione è sempre associata al pubblico. Amazon Cognito I token ID hanno un `aud` claim che contiene l'ID [client dell'app](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html). I token di accesso hanno un `client_id` claim che contiene anche l'ID client dell'app. Quando inserisci uno o più valori per la **convalida dell'applicazione Client** nella fonte della tua identità, Verified Permissions confronta questo elenco di client IDs dell'app con l'attestazione del token ID o l'`aud`attestazione del token di accesso. `client_id` Verified Permissions non convalida l'URL di un pubblico relying-party per le fonti di identità. Amazon Cognito ## Autorizzazione lato client per JWTs Potresti voler elaborare i token web JSON nella tua applicazione e passare le relative dichiarazioni a Verified Permissions senza utilizzare una fonte di identità del Policy Store. Puoi estrarre gli attributi della tua entità da un token Web JSON (JWT) e analizzarli in autorizzazioni verificate. Questo esempio mostra come è possibile chiamare le autorizzazioni verificate da un'applicazione che utilizza un 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]; } ``` ¹ Questo esempio di codice utilizza la [aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify)libreria per la verifica JWTs della compatibilità con OIDC. IdPs # Utilizzo delle fonti di identità OIDC Puoi anche configurare qualsiasi IdP OpenID Connect (OIDC) conforme come fonte di identità di un policy store. I provider OIDC sono simili ai pool di utenti di Amazon Cognito: JWTs producono come prodotto di autenticazione. Per aggiungere un provider OIDC, devi fornire un URL emittente Una nuova fonte di identità OIDC richiede le seguenti informazioni: + L'URL dell'emittente. Le autorizzazioni verificate devono essere in grado di rilevare un `.well-known/openid-configuration` endpoint in questo URL. + Record CNAME che non includono wild card. Ad esempio, non `a.example.com` può essere mappato su. `*.example.net` Al contrario, non `*.example.com` può essere mappato su. `a.example.net` + Il tipo di token che desideri utilizzare nelle richieste di autorizzazione. In questo caso, hai scelto **Identity token**. + Il tipo di entità utente che desideri associare alla fonte della tua identità, ad esempio`MyCorp::User`. + Il tipo di entità di gruppo che desideri associare alla tua fonte di identità, ad esempio`MyCorp::UserGroup`. + Un esempio di token ID o una definizione delle attestazioni nel token ID. + Il prefisso che desideri applicare all'entità IDs utente e di gruppo. Nella CLI e nell'API, puoi scegliere questo prefisso. Negli archivi di policy creati con l'opzione **Configura con API Gateway e un provider di identità** o l'opzione di **configurazione guidata**, Verified Permissions assegna un prefisso del nome dell'emittente meno`https://`, ad esempio. `MyCorp::User::"auth.example.com|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"` Per ulteriori informazioni sull'utilizzo delle operazioni API per autorizzare le richieste provenienti da fonti OIDC, vedere. [Operazioni API disponibili per l'autorizzazione](authorization.md#authorization-operations) L'esempio seguente mostra come è possibile creare una politica che consenta l'accesso ai report di fine anno ai dipendenti del reparto contabilità, abbiano una classificazione riservata e non lavorino in un ufficio secondario. Verified Permissions ricava questi attributi dalle attestazioni contenute nel token ID del preside. Si noti che quando si fa riferimento a un gruppo nel principale, è necessario utilizzare l'`in`operatore affinché la politica venga valutata correttamente. ``` permit( principal in MyCorp::UserGroup::"MyOIDCProvider|Accounting", action, resource in MyCorp::Folder::"YearEnd2024" ) when { principal.jobClassification == "Confidential" && !(principal.location like "SatelliteOffice*") }; ``` **Topics** + [Creazione di fonti di identità OIDC di Amazon Verified Permissions](oidc-create.md) + [Modifica delle fonti di identità OIDC di Amazon Verified Permissions](oidc-edit.md) + [Mappatura dei token OIDC sullo schema](oidc-map-token-to-schema.md) + [Convalida di clienti e destinatari per i provider OIDC](oidc-validation.md) # Creazione di fonti di identità OIDC di Amazon Verified Permissions La procedura seguente aggiunge un'origine di identità a un archivio di politiche esistente. È inoltre possibile creare un'origine di identità quando si [crea un nuovo archivio di politiche](policy-stores-create.md) nella console Autorizzazioni verificate. In questo processo, puoi importare automaticamente le attestazioni contenute nei token di origine dell'identità negli attributi dell'entità. Scegli l'opzione **Configurazione guidata** o **Configura con API Gateway e un provider di identità**. Queste opzioni creano anche politiche iniziali. **Nota** **Le fonti di identità** non sono disponibili nel riquadro di navigazione a sinistra fino a quando non è stato creato un archivio delle politiche. Le fonti di identità create sono associate al policy store corrente. Puoi omettere il tipo di entità principale quando crei una fonte di identità con AWS CLI o [create-identity-source[CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)](https://docs.aws.amazon.com/cli/latest/reference/verifiedpermissions/create-identity-source.html)nell'API Verified Permissions. Tuttavia, un tipo di entità vuoto crea una fonte di identità con un tipo di entità di`AWS::Cognito`. Questo nome di entità non è compatibile con lo schema dell'archivio delle politiche. Per integrare Amazon Cognito le identità con lo schema dell'archivio delle politiche, è necessario impostare il tipo di entità principale su un'entità dell'archivio delle politiche supportata. ------ #### [ Console di gestione AWS ] **Per creare una fonte di identità OpenID Connect (OIDC)** 1. Apri la console delle autorizzazioni [verificate](https://console.aws.amazon.com/verifiedpermissions/). Scegli il tuo negozio di polizze. 1. Nel riquadro di navigazione a sinistra, scegli **Identity sources**. 1. Scegli **Crea fonte di identità**. 1. Scegli un **provider OIDC esterno**. 1. In URL **dell'emittente, inserisci l'URL** dell'emittente OIDC. Questo è l'endpoint del servizio che fornisce, ad esempio, il server di autorizzazione, le chiavi di firma e altre informazioni sul provider. `https://auth.example.com` L'URL dell'emittente deve ospitare un documento di rilevamento OIDC presso. `/.well-known/openid-configuration` 1. In **Tipo di token**, scegli il tipo di OIDC JWT che desideri che la tua applicazione invii per l'autorizzazione. Per ulteriori informazioni, consulta [Mappatura dei token OIDC sullo schema](oidc-map-token-to-schema.md). 1. In **Mappa le rivendicazioni dei token alle entità dello schema**, scegli un'**entità utente e un'****attestazione utente** per l'origine dell'identità. L'**entità Utente** è un'entità nel tuo archivio delle politiche a cui desideri fare riferimento agli utenti del tuo provider OIDC. L'**attestazione Utente** è un reclamo, in genere`sub`, derivante dal tuo ID o token di accesso che contiene l'identificatore univoco dell'entità da valutare. Le identità dell'IdP OIDC connesso verranno mappate sul tipo principale selezionato. 1. (Facoltativo) In **Mappa le rivendicazioni dei token alle entità dello schema, scegli un'entità** di gruppo e **un'**attestazione** di gruppo** come origine dell'identità. L'**entità Gruppo** è l'entità [principale](https://docs.cedarpolicy.com/overview/terminology.html#term-group) dell'**entità Utente**. Le rivendicazioni di gruppo vengono mappate su questa entità. L'**attestazione di gruppo** è in genere `groups` un'affermazione derivante dall'ID o dal token di accesso che contiene una stringa, JSON o una stringa di nomi di gruppi di utenti delimitata da spazi per l'entità da valutare. Le identità dell'IdP OIDC connesso verranno mappate sul tipo principale selezionato. 1. In fase di **convalida: facoltativo**, inserisci il cliente IDs o il pubblico URLs che desideri che l'archivio delle politiche accetti nelle eventuali richieste di autorizzazione. 1. Scegli **Crea fonte di identità**. 1. (Facoltativo) Se il vostro policy store dispone di uno schema, prima di poter fare riferimento agli attributi che estraete dall'identità o dai token di accesso nelle vostre policy Cedar, dovete aggiornare lo schema per rendere Cedar consapevole del tipo di principale creato dalla vostra fonte di identità. Tale aggiunta allo schema deve includere gli attributi a cui desiderate fare riferimento nelle vostre politiche Cedar. Per ulteriori informazioni sulla mappatura degli attributi del token OIDC agli attributi principali di Cedar, vedere. [Mappatura dei token OIDC sullo schema](oidc-map-token-to-schema.md) 1. Crea politiche che utilizzano le informazioni dei token per prendere decisioni di autorizzazione. Per ulteriori informazioni, consulta [Creazione di politiche statiche di Amazon Verified Permissions](policies-create.md). Ora che hai creato una fonte di identità, aggiornato lo schema e creato le politiche, consenti `IsAuthorizedWithToken` alle Autorizzazioni Verificate di prendere decisioni di autorizzazione. Per ulteriori informazioni, consulta [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)la *guida di riferimento dell'API Amazon Verified Permissions*. ------ #### [ AWS CLI ] **Per creare una fonte di identità OIDC** È possibile creare una fonte di identità utilizzando l'[CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)operazione. L'esempio seguente crea un'origine di identità in grado di accedere alle identità autenticate da un provider di identità (IdP) OIDC. 1. Crea un `config.txt` file che contenga i seguenti dettagli di un IdP OIDC da utilizzare con il `--configuration` parametro del 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. Esegui il comando seguente per creare una fonte di identità 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. (Facoltativo) Se il vostro policy store dispone di uno schema, prima di poter fare riferimento agli attributi che estraete dai token di identità o di accesso nelle vostre policy Cedar, dovete aggiornare lo schema per rendere Cedar consapevole del tipo di principale creato dalla vostra fonte di identità. Tale aggiunta allo schema deve includere gli attributi a cui desiderate fare riferimento nelle vostre politiche Cedar. Per ulteriori informazioni sulla mappatura degli attributi del token OIDC agli attributi principali di Cedar, vedere. [Mappatura dei token OIDC sullo schema](oidc-map-token-to-schema.md) 1. Crea politiche che utilizzano le informazioni dei token per prendere decisioni di autorizzazione. Per ulteriori informazioni, consulta [Creazione di politiche statiche di Amazon Verified Permissions](policies-create.md). Ora che hai creato una fonte di identità, aggiornato lo schema e creato le politiche, consenti `IsAuthorizedWithToken` alle Autorizzazioni Verificate di prendere decisioni di autorizzazione. Per ulteriori informazioni, consulta [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)la *guida di riferimento dell'API Amazon Verified Permissions*. ------ # Modifica delle fonti di identità OIDC di Amazon Verified Permissions Puoi modificare alcuni parametri della tua fonte di identità dopo averla creata. Non puoi cambiare il tipo di fonte di identità, devi eliminare l'origine dell'identità e crearne una nuova da cui passare Amazon Cognito a OIDC o OIDC. Amazon Cognito Se lo schema del policy store corrisponde agli attributi della fonte di identità, tieni presente che devi aggiornare lo schema separatamente per riflettere le modifiche apportate alla tua origine di identità. ------ #### [ Console di gestione AWS ] **Per aggiornare una fonte di identità OIDC** 1. Apri la console delle [autorizzazioni verificate](https://console.aws.amazon.com/verifiedpermissions/). Scegli il tuo negozio di polizze. 1. Nel riquadro di navigazione a sinistra, scegli **Identity sources**. 1. Scegli l'ID della fonte di identità da modificare. 1. Scegli **Modifica**. 1. Nei **dettagli del provider OIDC**, modifica l'**URL dell'emittente** in base alle esigenze. 1. In **Map token claim to schema**, modifica le associazioni tra le attestazioni utente e di gruppo e i tipi di entità del Policy Store, se necessario. Dopo aver modificato i tipi di entità, è necessario aggiornare le politiche e gli attributi dello schema per applicarli ai nuovi tipi di entità. 1. Nella **convalida dell'audience**, aggiungi o rimuovi i valori di audience che desideri applicare. 1. Scegli **Save changes** (Salva modifiche). Puoi eliminare una fonte di identità scegliendo il pulsante di opzione accanto a una fonte di identità e quindi scegliendo **Elimina fonte di identità**. Digita `delete` nella casella di testo, quindi scegli **Elimina fonte di identità** per confermare l'eliminazione della fonte di identità. ------ #### [ AWS CLI ] **Per aggiornare una fonte di identità OIDC** È possibile aggiornare una fonte di identità utilizzando l'[UpdateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_UpdateIdentitySource.html)operazione. L'esempio seguente aggiorna l'origine di identità specificata per utilizzare un provider OIDC diverso. 1. Crea un `config.txt` file che contenga i seguenti dettagli di un IdP OIDC da utilizzare con il `--configuration` parametro del 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. Esegui il comando seguente per aggiornare una fonte di identità 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 si modifica il tipo principale per l'origine dell'identità, è necessario aggiornare lo schema in modo che rifletta correttamente il tipo principale aggiornato. ------ # Mappatura dei token OIDC sullo schema Potresti scoprire di voler aggiungere una fonte di identità a un archivio delle politiche e mappare le attestazioni, o token, del provider allo schema del tuo archivio delle politiche. È possibile automatizzare questo processo utilizzando la [configurazione guidata](policy-stores-create.md) per creare il proprio Policy Store con una fonte di identità o aggiornare lo schema manualmente dopo la creazione del Policy Store. Dopo aver mappato i token allo schema, è possibile creare policy che vi fanno riferimento. Questa sezione della guida per l'utente contiene le seguenti informazioni: + Quando è possibile compilare automaticamente gli attributi in uno schema di policy store + Come creare manualmente uno schema per una fonte di identità Gli archivi di [policy collegati alle API](policy-stores-api-userpool.md) e gli archivi di policy con una fonte di identità creati tramite la [configurazione guidata](policy-stores-create.md) non richiedono la mappatura manuale degli attributi del token di identità (ID) allo schema. Puoi fornire autorizzazioni verificate con gli attributi del tuo pool di utenti e creare uno schema popolato con attributi utente. Nell'autorizzazione con token ID, Verified Permissions associa le rivendicazioni agli attributi di un'entità principale. Per utilizzare un provider di identità (IdP) OIDC come fonte di identità nel tuo archivio di policy per le autorizzazioni verificate, devi avere gli attributi del provider nello schema. Lo schema è fisso e deve corrispondere alle entità create dai token del provider o alle richieste API. [IsAuthorizedWithToken[BatchIsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_BatchIsAuthorizedWithToken.html)](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html) Se hai creato il tuo archivio delle politiche in modo da compilare automaticamente lo schema con le informazioni del provider in un token ID, sei pronto per scrivere le policy. Se crei un policy store senza uno schema per la tua origine di identità, devi aggiungere gli attributi del provider allo schema che corrispondono alle entità create utilizzando le richieste API. Quindi puoi scrivere politiche utilizzando gli attributi del token del provider. **Topics** + [Mappatura dei token ID sullo schema](#oidc-map-id-token) + [Mappatura dei token di accesso](#oidc-map-access-token) + [Cose da sapere sulla mappatura degli schemi](#oidc-map-token-to-schema-things-to-know) ## Mappatura dei token ID sullo schema Verified Permissions elabora le dichiarazioni relative ai token ID come attributi dell'utente: nomi e titoli, appartenenza al gruppo, informazioni di contatto. I token ID sono molto utili in un modello di autorizzazione ABAC (*Attribute-Based Access Control*). Se desideri che le autorizzazioni verificate analizzino l'accesso alle risorse in base a chi effettua la richiesta, scegli i token ID come fonte della tua identità. Lavorare con i token ID di un provider OIDC è molto simile a lavorare con i token ID. Amazon Cognito La differenza sta nelle affermazioni. Il tuo IdP potrebbe presentare [attributi OIDC standard](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) o avere uno schema personalizzato. Quando crei un nuovo archivio di politiche nella console Verified Permissions, puoi aggiungere una fonte di identità OIDC con un token ID di esempio oppure puoi mappare manualmente le attestazioni dei token agli attributi utente. Poiché Verified Permissions non conosce lo schema degli attributi del tuo IdP, devi fornire queste informazioni. Per ulteriori informazioni, consulta [Creazione di archivi di policy per le autorizzazioni verificate](policy-stores-create.md). Di seguito è riportato uno schema di esempio per un policy store con una fonte di identità 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" } } } } ``` Per un esempio di politica che verrà convalidata in base a questo schema, vedere. [Riflette gli attributi del token ID OIDC](policies-examples.md#policies-examples-oidc-id) ## Mappatura dei token di accesso *Verified Permissions elabora le dichiarazioni dei token di accesso diverse da quelle dichiarate dai gruppi come attributi dell'azione o attributi di contesto.* Oltre all'appartenenza al gruppo, i token di accesso del tuo IdP potrebbero contenere informazioni sull'accesso alle API. I token di accesso sono utili nei modelli di autorizzazione che utilizzano il controllo degli accessi basato sui ruoli (RBAC). I modelli di autorizzazione che si basano su richieste di token di accesso diverse dall'appartenenza al gruppo richiedono uno sforzo aggiuntivo nella configurazione dello schema. La maggior parte dei token di accesso di fornitori OIDC esterni si allinea strettamente ai token di accesso. Amazon Cognito Un token di accesso OIDC viene mappato su un oggetto di contesto quando viene passato a Verified Permissions. È possibile fare riferimento agli attributi del token di accesso utilizzando. `context.token.attribute_name` Il seguente token di accesso OIDC include esempi di attestazioni di base. ``` { "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" } ``` L'esempio seguente mostra come riflettere gli attributi del token di accesso di esempio nello schema Verified Permissions. Per ulteriori informazioni sulla modifica dello schema, consulta[Modifica degli schemi di archiviazione delle politiche](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" } } } } ``` Per un esempio di politica che verrà convalidata rispetto a questo schema, vedi[Riflette gli attributi del token di accesso OIDC](policies-examples.md#policies-examples-oidc-access). ## Cose da sapere sulla mappatura degli schemi **La mappatura degli attributi differisce tra i tipi di token** [Nell'autorizzazione del token di accesso, Verified Permissions mappa le rivendicazioni in base al contesto.](context.md) Nell'autorizzazione tramite token ID, Verified Permissions associa le rivendicazioni agli attributi principali. Per i policy store creati nella console Verified Permissions, solo gli archivi di policy **vuoti** e di **esempio** non lasciano alcuna fonte di identità e richiedono di compilare lo schema con gli attributi del pool di utenti per l'autorizzazione del token ID. L'autorizzazione dei token di accesso si basa sul controllo degli accessi basato sui ruoli (RBAC) con attestazioni di appartenenza al gruppo e non associa automaticamente altre attestazioni allo schema del policy store. **Gli attributi di origine dell'identità non sono obbligatori** Quando crei una fonte di identità nella console Autorizzazioni verificate, nessun attributo viene contrassegnato come obbligatorio. In questo modo si evita che le attestazioni mancanti causino errori di convalida nelle richieste di autorizzazione. È possibile impostare gli attributi come obbligatori in base alle esigenze, ma devono essere presenti in tutte le richieste di autorizzazione. **RBAC non richiede attributi nello schema** Gli schemi per le fonti di identità dipendono dalle associazioni di entità che si creano quando si aggiunge la fonte di identità. Un'origine di identità associa un'attestazione a un tipo di entità utente e un'affermazione a un tipo di entità di gruppo. Queste mappature di entità sono il fulcro di una configurazione di origine dell'identità. Con queste informazioni minime, è possibile scrivere politiche che eseguano azioni di autorizzazione per utenti specifici e gruppi specifici di cui gli utenti potrebbero essere membri, in un modello di controllo degli accessi basato sul ruolo (RBAC). L'aggiunta di attestazioni di token allo schema estende l'ambito di autorizzazione del policy store. Gli attributi utente dei token ID contengono informazioni sugli utenti che possono contribuire all'autorizzazione del controllo degli accessi basato sugli attributi (ABAC). Gli attributi di contesto dei token di accesso contengono informazioni come gli ambiti OAuth 2.0 che possono fornire ulteriori informazioni sul controllo degli accessi fornite dal provider, ma richiedono ulteriori modifiche allo schema. Le opzioni **Configura con API Gateway e un provider di identità** e **Configurazione guidata** nella console Autorizzazioni verificate assegnano le attestazioni del token ID allo schema. Questo non è il caso delle rivendicazioni relative ai token di accesso. [Per aggiungere attestazioni di token di accesso non di gruppo allo schema, è necessario modificare lo schema in modalità JSON e aggiungere gli attributi CommonTypes.](https://docs.cedarpolicy.com/schema/json-schema.html#schema-commonTypes) Per ulteriori informazioni, consulta [Mappatura dei token di accesso](#oidc-map-access-token). **L'affermazione dei gruppi OIDC supporta più formati** Quando aggiungi un provider OIDC, puoi scegliere il nome della dichiarazione di gruppo in ID o i token di accesso che desideri associare all'appartenenza al gruppo di un utente nel tuo archivio delle politiche. Le autorizzazioni verificate riconoscono le dichiarazioni dei gruppi nei seguenti formati: 1. Stringa senza spazi: `"groups": "MyGroup"` 1. Elenco delimitato da spazi:. `"groups": "MyGroup1 MyGroup2 MyGroup3"` Ogni stringa è un gruppo. 1. Elenco JSON (delimitato da virgole): `"groups": ["MyGroup1", "MyGroup2", "MyGroup3"]` **Nota** Verified Permissions interpreta ogni stringa contenuta in una dichiarazione di gruppi separati da spazi come un gruppo separato. Per interpretare il nome di un gruppo con un carattere di spazio come un singolo gruppo, sostituisci o rimuovi lo spazio nell'attestazione. Ad esempio, formatta un gruppo denominato `My Group` come`MyGroup`. **Scegli un tipo di token** Il modo in cui il policy store funziona con la fonte di identità dipende da una decisione chiave nella configurazione dell'origine dell'identità: se elaborare gli ID o i token di accesso. Con un provider OIDC, è necessario scegliere un tipo di token quando si aggiunge la fonte di identità. Puoi scegliere ID o token di accesso e la tua scelta esclude che il tipo di token non scelto venga elaborato nel tuo archivio delle politiche. Soprattutto se desideri trarre vantaggio dalla mappatura automatica delle rivendicazioni dei token ID agli attributi nella console Verified Permissions, decidi in anticipo il tipo di token che desideri elaborare prima di creare la tua fonte di identità. La modifica del tipo di token richiede uno sforzo significativo per rifattorizzare le politiche e lo schema. I seguenti argomenti descrivono l'uso degli ID e dei token di accesso con gli archivi delle politiche. **Cedar parser richiede parentesi per alcuni caratteri** Le politiche in genere fanno riferimento agli attributi dello schema in un formato simile. `principal.username` Nel caso della maggior parte dei caratteri non alfanumerici come `:``.`, o `/` che potrebbero apparire nei nomi delle rivendicazioni dei token, Verified Permissions non è in grado di analizzare un valore di condizione come o. `principal.cognito:username` `context.ip-address` È invece necessario formattare queste condizioni con la notazione tra parentesi nel formato o, rispettivamente. `principal["cognito:username"]` `context["ip-address"]` Il carattere di sottolineatura `_` è un carattere valido nei nomi delle rivendicazioni e rappresenta l'unica eccezione non alfanumerica a questo requisito. Uno schema di esempio parziale per un attributo principale di questo tipo è simile al seguente: ``` "User": { "shape": { "type": "Record", "attributes": { "cognito:username": { "type": "String", "required": true }, "custom:employmentStoreCode": { "type": "String", "required": true, }, "email": { "type": "String", "required": false } } } } ``` Uno schema di esempio parziale per un attributo di contesto di questo tipo è simile al seguente: ``` "GetOrder": { "memberOf": [], "appliesTo": { "resourceTypes": [ "Order" ], "context": { "type": "Record", "attributes": { "ip-address": { "required": false, "type": "String" } } }, "principalTypes": [ "User" ] } } ``` Per un esempio di politica che verrà convalidata rispetto a questo schema, vedi[Utilizza la notazione tra parentesi per fare riferimento agli attributi del token](policies-examples.md#policies-examples-brackets). # Convalida di clienti e destinatari per i provider OIDC Quando si aggiunge una fonte di identità a un policy store, Verified Permissions dispone di opzioni di configurazione che verificano che l'ID e i token di accesso vengano utilizzati come previsto. Questa convalida avviene durante l'elaborazione delle richieste API`IsAuthorizedWithToken`. `BatchIsAuthorizedWithToken` Il comportamento differisce tra ID e token di accesso Amazon Cognito e tra fonti di identità OIDC. Con i provider di pool di utenti di Amazon Cognito, Verified Permissions può convalidare l'ID client sia nell'ID che nei token di accesso. Con i provider OIDC, Verified Permissions può convalidare l'ID client nei token ID e il pubblico nei token di accesso. Un *ID client* è un identificatore associato all'istanza del provider di identità utilizzata dall'applicazione, ad esempio. `1example23456789` Un *pubblico* è un percorso URL associato al *relying party*, o destinazione, previsto per il token di accesso, ad esempio. `https://mytoken.example.com` Quando si utilizzano i token di accesso, l'`aud`affermazione è sempre associata al pubblico. I token ID OIDC hanno un `aud` claim che contiene client IDs, ad esempio. `1example23456789` I token di accesso OIDC hanno un'`aud`attestazione che contiene l'URL del pubblico per il token, ad esempio, e un'`client_id`attestazione che contiene client`https://myapplication.example.com`, ad esempio. IDs `1example23456789` Quando configuri il tuo policy store, inserisci uno o più valori per la **convalida dell'audience** che il tuo policy store utilizzerà per convalidare il pubblico di un token. + **Token ID**: Verified Permissions convalida l'ID client verificando che almeno un membro del client IDs nell'`aud`attestazione corrisponda a un valore di convalida del pubblico. + **Token di accesso**: le autorizzazioni verificate convalidano il pubblico verificando che l'URL nell'attestazione corrisponda a un valore di convalida del `aud` pubblico. Se non esiste alcuna `aud` affermazione, il pubblico può essere convalidato utilizzando le attestazioni o. `cid` `client_id` Rivolgiti al tuo provider di identità per conoscere la dichiarazione e il formato corretti relativi al pubblico. ## Autorizzazione lato client per JWTs Potresti voler elaborare i token web JSON nella tua applicazione e passare le relative dichiarazioni a Verified Permissions senza utilizzare una fonte di identità del Policy Store. Puoi estrarre gli attributi della tua entità da un token Web JSON (JWT) e analizzarli in autorizzazioni verificate. Questo esempio mostra come è possibile chiamare le autorizzazioni verificate da un'applicazione che utilizza un 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]; } ``` ¹ Questo esempio di codice utilizza la [aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify)libreria per la verifica JWTs della compatibilità con OIDC. IdPs