Scenari comuni - AWS Identity and Access Management
Amazon Cognito per applicazioni per dispositivi mobiliFederazione OIDC per applicazioni per dispositivi mobili

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

Scenari comuni

Nota

Consigliamo di richiedere agli utenti di utilizzare credenziali temporanee per l'accesso a AWS. Hai preso in considerazione l'utilizzo di AWS IAM Identity Center? Puoi utilizzare IAM Identity Center per gestire centralmente l'accesso a più Account AWS e fornire agli utenti un accesso Single Sign-On protetto da MFA a tutti gli account assegnati da un'unica posizione. Con IAM Identity Center puoi creare e gestire le identità degli utenti in IAM Identity Center o connetterti facilmente al tuo attuale gestore dell'identità digitale (IdP) compatibile con SAML 2.0. Per ulteriori informazioni, consulta Cos'è IAM Identity Center? nella Guida per l'utente di AWS IAM Identity Center.

Puoi utilizzare un gestore dell'identità digitale (IdP) esterno per gestire le identità degli utenti al di fuori di AWS e dell'IdP esterno. Un IdP esterno può fornire informazioni sull'identità ad AWS utilizzando OpenID Connect (OIDC) o Security Assertion Markup Language (SAML). L'OIDC viene comunemente utilizzato quando un'applicazione che non viene eseguito su AWS richiede l'accesso alle risorse AWS.

Se desideri configurare la federazione con un IdP esterno, crea un gestore dell'identità digitale IAM per comunicare ad AWS le informazioni sull'IdP esterno e sulla relativa configurazione. In questo modo si definisce la fiducia tra il tuo Account AWS e l'IdP esterno. I seguenti argomenti forniscono scenari comuni per l'utilizzo dei provider di identità IAM.

Amazon Cognito per applicazioni per dispositivi mobili

Il modo migliore per utilizzare la federazione OIDC è utilizzare Amazon Cognito. Ad esempio, Adele sta sviluppando un gioco per un dispositivo mobile in cui i dati dell'utente, quali punteggi e profili, vengono memorizzati in Amazon S3 e Amazon DynamoDB. Adele potrebbe archiviare questi dati anche in locale sul dispositivo e utilizzare Amazon Cognito per mantenerli sincronizzati su tutti i dispositivi. Tuttavia, Adele è consapevole che, per motivi di sicurezza e manutenzione, le credenziali di sicurezza AWS a lungo termine non dovrebbero essere distribuite con il gioco. Adele sa anche che il gioco potrebbe avere un gran numero di utenti. Per tutti questi motivi, non desidera creare nuove identità utente in IAM per ciascun giocatore. In alternativa, decide di sviluppare il gioco in modo che gli utenti possano effettuare l'accesso utilizzando un'identità già stabilita con un noto gestore dell'identità digitale (IdP) esterno, ad esempio Accedi con Amazon, Facebook, Google o qualsiasi provider di identità compatibile con OpenID Connect (OIDC). Il suo gioco può sfruttare il meccanismo di autenticazione di uno di questi provider per convalidare l'identità dell'utente.

Per consentire all'applicazione per dispositivi mobili di accedere alle risorse AWS, Adele registra innanzitutto un ID sviluppatore con i provider di identità scelti. Configura anche l'applicazione con ciascuno di questi provider. Nel suo Account AWS che contiene il bucket Amazon S3 e la tabella DynamoDB per il gioco, Adele utilizza Amazon Cognito per creare ruoli IAM che definiscono con precisione le autorizzazioni necessarie per il gioco. Se sta utilizzando un gestore dell'identità digitale (IdP) OIDC, crea anche un'entità IdP dell'OIDC IAM per stabilire l'attendibilità tra un pool di identità di Amazon Cognito nel suo Account AWS e l'IdP.

Nel codice dell'app, Adele chiama l'interfaccia di accesso per il provider di identità che ha configurato in precedenza. Il provider di identità gestisce tutti i dettagli relativi all'accesso dell'utente e l'app riceve un token di accesso OAuth o un token ID OIDC dal provider. L'app di Adele può scambiare queste informazioni di autenticazione con una serie di credenziali di sicurezza temporanee composte da un ID chiave di accesso AWS, una chiave di accesso segreta e un token di sessione. L'app può quindi utilizzare queste credenziali per accedere ai servizi Web offerti da AWS. L'app è limitata alle autorizzazioni definite nel ruolo che assume.

La figura riportata di seguito mostra un flusso semplificato su come questo processo potrebbe funzionare, usando Login with Amazon come provider di identità. Per la fase 2, l'app può anche utilizzare Facebook, Google o qualsiasi altro IdP compatibile con OIDC, ma ciò non è mostrato qui.

Esempio di flusso di lavoro con utilizzo di Amazon Cognito per effettuare la federazione degli utenti per un'applicazione per dispositivi mobili

  1. Un cliente avvia l'app su un dispositivo mobile. L'app richiede all'utente di effettuare l'accesso.

  2. L'app utilizza il login con le risorse di Login with Amazon per accettare le credenziali dell'utente.

  3. L'app utilizza le operazioni dell'API Amazon Cognito GetId e GetCredentialsForIdentity per scambiare il token ID di Login with Amazon con un token di Amazon Cognito. Amazon Cognito, che è stato configurato per rendere attendibile il tuo progetto Login with Amazon, genera un token che scambia con credenziali di sessione temporanee per AWS STS.

  4. L'app riceve le credenziali di sicurezza temporanee da Amazon Cognito. La tua app può utilizzare anche il flusso di lavoro Basic (Classic) in Amazon Cognito per recuperare i token da AWS STS utilizzando AssumeRoleWithWebIdentity. Per ulteriori informazioni, consulta Flusso di autenticazione dei pool di identità (identità federate) nella Guida per gli sviluppatori di Amazon Cognito.

  5. Le credenziali di sicurezza temporanee possono essere utilizzate dall'app per accedere alle risorse AWS richieste dall'applicazione per funzionare. Il ruolo associato alle credenziali di sicurezza temporanee e alle relative policy assegnate determina a quali elementi è possibile accedere.

Utilizza il seguente processo per configurare l'app in modo che utilizzi Amazon Cognito per autenticare gli utenti e consentire all'app di accedere alle risorse AWS. Per le operazioni specifiche per realizzare questo scenario, consulta la documentazione di Amazon Cognito.

  1. (Facoltativo) Registrati come sviluppatore con Login with Amazon, Facebook, Google o qualsiasi altro provider di identità compatibile con OpenID Connect (OIDC) e configura una o più app con il provider. Questa fase è facoltativa poiché Amazon Cognito supporta anche l'accesso non autenticato (guest) per gli utenti.

  2. Passa ad Amazon Cognito nella Console di gestione AWS. Utilizza la procedura guidata di Amazon Cognito per creare un pool di identità, ovvero un container che Amazon Cognito utilizza per mantenere le identità degli utenti finali organizzate per le app. Puoi condividere i pool di identità tra le app. Quando configuru un pool di identità, Amazon Cognito crea uno o due ruoli IAM (uno per le identità autenticate e uno per le identità "guest" non autenticate) che definiscono le autorizzazioni per gli utenti di Amazon Cognito.

  3. Integra AWS Amplify con l'app e importa i file necessari per utilizzare Amazon Cognito.

  4. Crea un'istanza del provider di credenziali di Amazon Cognito, passando l'ID del pool di identità, il numero del tuo Account AWS e l'Amazon Resource Name (ARN) dei ruoli associati al pool di identità. La procedura guidata di Amazon Cognito nella Console di gestione AWS fornisce un codice di esempio per aiutarti a iniziare.

  5. Quando l'app accede a una risorsa AWS, passa l'istanza del provider di credenziali all'oggetto client, che passa le credenziali di sicurezza temporanee al client. Le autorizzazioni per le credenziali si basano sul ruolo o sui ruoli definiti in precedenza.

Per ulteriori informazioni, consulta gli argomenti seguenti:

Federazione OIDC per applicazioni per dispositivi mobili

Per risultati ottimali, utilizza Amazon Cognito come gestore di identità per quasi tutti gli scenari di federazione OIDC. Amazon Cognito è semplice da utilizzare e fornisce funzionalità aggiuntive quali l'accesso anonimo (non autenticato) e la sincronizzazione dei dati degli utenti tra più dispositivi e provider. Tuttavia, se hai già creato un'app che utilizza la federazione OIDC chiamando manualmente l'API AssumeRoleWithWebIdentity, puoi continuare a utilizzarla e le app funzioneranno comunque correttamente.

Il processo per l'utilizzo della federazione OIDC senza Amazon Cognito segue questa struttura generale:

  1. Effettuare la registrazione come sviluppatore al provider di identità (IdP) esterno e configurare l'app con tale provider, che fornisce un ID univoco per l'app. Provider diversi utilizzano una terminologia diversa per questo processo. Questa guida utilizza il termineconfigurare per il processo di identificazione dell'applicazione con il provider. Ciascun provider fornisce un ID app univoco per il provider stesso, perciò se si configura la stessa app con più provider, l'app disporrà di più ID app. È possibile configurare più app con ciascun provider.

    I seguenti collegamenti esterni forniscono informazioni sull'utilizzo di alcuni dei più comuni provider di identità (IdP):

    Importante

    Se utilizzi un provider di identità OIDC di Google, Facebook o Amazon Cognito, non creare un provider di identità IAM separato nella Console di gestione AWS. AWS dispone di questi provider di identità OIDC integrati e disponibili per l'uso. Ignora la fase seguente e passa direttamente alla creazione di nuovi ruoli utilizzando il provider di identità.

  2. Se utilizzi un IdP di identità diverso da Google, Facebook o Amazon Cognito compatibile con OIDC, crea un'entità provider di identità IAM.

  3. In IAM, crea uno o più ruoli. Per ogni ruolo, definisci chi può assumere il ruolo (policy di attendibilità) e quali autorizzazioni concedere agli utenti dell'app (policy di autorizzazione). Di solito, è necessario creare un ruolo per ogni provider di identità supportato da un'app. Ad esempio, puoi creare un ruolo che può essere assunto da un'applicazione quando l'utente effettua l'accesso tramite Login with Amazon, un secondo ruolo per la stessa applicazione in cui l'utente effettua l'accesso tramite Facebook e un terzo ruolo per l'applicazione in cui l'utente effettua l'accesso tramite Google. Per la relazione di trust, specificare il provider di identità (ad esempio Amazon.com) come Principal (l'entità attendibile) e includere un elemento Condition corrispondente all'ID app assegnato dal provider di identità. Esempi di ruoli per diversi provider sono descritti più in Creazione di un ruolo per un provider di identità di terze parti .

  4. Nell'applicazione, autenticare gli utenti con il provider di identità. Le specifiche della procedura variano sia in base al provider di identità in uso (Login with Amazon, Facebook o Google) sia in base alla piattaforma su cui viene eseguita l'app. Ad esempio, il metodo di autenticazione di un'app Android può differire da quello di un'app iOS o un'app Web basata su JavaScript.

    In genere, se l'utente non ha già effettuato l'accesso, il provider di identità si occupa di visualizzare una pagina di accesso. Dopo aver autenticato l'utente, il provider di identità restituisce all'app un token di autenticazione con le informazioni sull'utente. Le informazioni incluse dipendono dagli elementi esposti dal provider di identità e dalle informazioni che l'utente è disposto a condividere. Queste informazioni possono essere utilizzate nell'app.

  5. Nell'app, effettuare una chiamata non firmata all'operazione AssumeRoleWithWebIdentity per richiedere le credenziali di sicurezza provvisorie. Nella richiesta, viene inoltrato il token di autenticazione del provider di identità e viene specificato l'Amazon Resource Name (ARN) per il ruolo IAM creato per tale provider di identità. AWS verifica che il token sia attendibile e valido e, in caso affermativo, restituisce le credenziali di sicurezza provvisorie all'app che dispone delle autorizzazioni per il ruolo specificato nella richiesta. La risposta include anche i metadati relativi all'utente forniti dal provider di identità, ad esempio l'ID utente univoco che il provider associa all'utente.

  6. Tramite le credenziali di sicurezza provvisorie ottenute dalla risposta AssumeRoleWithWebIdentity, l'app effettua richieste firmate alle operazioni API AWS. Le informazioni sull'ID utente fornite dall'IdP possono distinguere gli utenti nella tua app. Ad esempio, è possibile inserire in cartelle Amazon S3 oggetti che includono l'ID utente come prefisso o suffisso. Ciò consente di creare policy di controllo degli accessi che bloccano la cartella in modo che solo l'utente con l'ID specificato possa accedervi. Per ulteriori informazioni, consulta AWS STS principali utente federati.

  7. L'app dovrebbe memorizzare nella cache le credenziali di sicurezza temporanee in modo da non doverne ottenere di nuove ogni volta che ha bisogno di effettuare una richiesta ad AWS. Come impostazione predefinita, le credenziali sono valide per un'ora. Quando scadono (o prima), devi effettuare un'altra chiamata ad AssumeRoleWithWebIdentity per ottenere un nuovo set di credenziali di sicurezza temporanee. A seconda del provider di identità e di come gestisce i token, potrebbe essere necessario aggiornare il token del provider prima di effettuare una nuova chiamata ad AssumeRoleWithWebIdentity, dato che anche i token di solito scadono dopo un determinato periodo di tempo. Se si utilizza AWS SDK for iOS o AWS SDK for Android, è possibile utilizzare l'operazione AmazonSTSCredentialsProvider che gestisce le credenziali provvisorie di IAM e le aggiorna in base alle esigenze.