Utilizzo delle fonti di identità OIDC - Autorizzazioni verificate da Amazon

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

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 esempioMyCorp::User.

  • Il tipo di entità di gruppo che desideri associare alla tua fonte di identità, ad esempioMyCorp::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 menohttps://, 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

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'inoperatore 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*")
};
Argomenti