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à.

# Utilizzo delle fonti di identità OIDC
<a name="identity-sources-oidc"></a>

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)