Fornire l'accesso a utenti autenticati esternamente (federazione delle identità) - AWS Identity and Access Management

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

Fornire l'accesso a utenti autenticati esternamente (federazione delle identità)

I tuoi utenti potrebbero già avere identità esterne AWS, ad esempio nella tua directory aziendale. Se tali utenti devono utilizzare AWS risorse (o utilizzare applicazioni che accedono a tali risorse), devono utilizzare anche credenziali AWS di sicurezza. È possibile utilizzare un ruolo IAM per specificare le autorizzazioni per gli utenti la cui identità è federata dalla propria organizzazione o da un provider di identità di terze parti (IdP).

Nota

Come best practice di sicurezza, ti consigliamo di gestire l'accesso degli utenti in Centro identità IAM con la federazione delle identità anziché creare utenti IAM. Per informazioni su situazioni specifiche in cui è richiesto un utente IAM, consulta la sezione Quando creare un utente IAM invece di un ruolo.

Federazione di utenti di una applicazione per dispositivi mobili o basata sul Web con Amazon Cognito

Se crei un'app mobile o basata sul Web che accede alle AWS risorse, l'app necessita di credenziali di sicurezza per poter effettuare richieste programmatiche a. AWS Per la maggior parte degli scenari relativi alle applicazioni per dispositivi mobili, consigliamo di utilizzare Amazon Cognito. Puoi utilizzare questo servizio con AWS Mobile SDK per iOS e Mobile SDK per Android e AWS Fire OS per creare identità uniche per gli utenti e autenticarli per un accesso sicuro alle tue risorse. AWS Amazon Cognito supporta gli stessi provider di identità come quelli elencati nella sezione successiva e supporta anche identità autenticate dallo sviluppatore e accesso non autenticato (ospite). Amazon Cognito fornisce inoltre operazioni API per la sincronizzazione dei dati utente in modo che vengano conservati quando gli utenti passano da un dispositivo all'altro. Per ulteriori informazioni, consulta Utilizzo di Amazon Cognito per applicazioni per dispositivi mobili.

Federazione degli utenti con provider di servizi di identità pubblica o OpenID Connect

Quando possibile, utilizza Amazon Cognito per scenari di applicazioni per dispositivi mobili o basate sul Web. Amazon Cognito si occupa della maggior parte del behind-the-scenes lavoro con i servizi di provider di identità pubblici per te. Lavora con gli stessi servizi di terze parti e supporta anche gli accessi anonimi. Tuttavia, per ulteriori scenari avanzati, è possibile lavorare direttamente con un servizio di terze parti, ad esempio Login with Amazon, Facebook, Google o qualsiasi IdP compatibile con OpenID Connect (OIDC). Per ulteriori informazioni sull'utilizzo della federazione OIDC utilizzando uno di questi servizi, consulta. Federazione OIDC

Federazione degli utenti con SAML 2.0

Se la tua organizzazione utilizza già un pacchetto software per provider di identità che supporta SAML 2.0 (Security Assertion Markup Language 2.0), puoi creare fiducia tra la tua organizzazione come provider di identità (IdP) e AWS come fornitore di servizi. Puoi quindi utilizzare SAML per fornire ai tuoi utenti il Single Sign-On federato (SSO) o l'accesso federato alle operazioni dell' AWS Management Console API di chiamata. AWS Ad esempio, se la tua azienda utilizza Microsoft Active Directory e Active Directory Federation Services, puoi effettuare la federazione utilizzando SAML 2.0. Per ulteriori informazioni sulla federazione degli utenti con SAML 2.0, consulta Federazione SAML 2.0.

Federazione degli utenti creando un'applicazione personalizzata per la gestione di identità

Se il proprio archivio identità non è compatibile con SAML 2.0, è possibile creare un'applicazione personalizzata per la gestione di identità per eseguire una funzione simile. L'applicazione broker autentica gli utenti, richiede credenziali temporanee per gli utenti e quindi le fornisce all'utente per accedere alle AWS risorse. AWS

Ad esempio, Example Corp. ha molti dipendenti che devono eseguire applicazioni interne che accedono alle risorse dell'azienda. AWS I dipendenti hanno già identità nel sistema di identità e autenticazione dell'azienda ed Example Corp. non desidera creare un utente IAM separato per ogni dipendente dell'azienda.

Bob è uno sviluppatore presso Example Corp. Per consentire alle applicazioni interne di Example Corp. di accedere alle AWS risorse dell'azienda, Bob sviluppa un'applicazione di identity broker personalizzata. L'applicazione verifica che i dipendenti abbiano effettuato l'accesso nel sistema di identità e autenticazione esistente, che potrebbe utilizzare LDAP, Active Directory o un altro sistema. L'applicazione del gestore identità quindi ottiene le credenziali di sicurezza provvisorie per i dipendenti. Questo scenario è simile a quello precedente (un'app mobile che utilizza un sistema di autenticazione personalizzato), tranne per il fatto che le applicazioni che richiedono l'accesso alle AWS risorse vengono eseguite tutte all'interno della rete aziendale e l'azienda dispone di un sistema di autenticazione esistente.

Per ottenere le credenziali di sicurezza provvisorie, l'applicazione del gestore identità chiama AssumeRole o GetFederationToken per ottenere le credenziali di sicurezza provvisorie, a seconda di come Bob desidera gestire le policy per gli utenti e quando scadono le credenziali provvisorie. (Per ulteriori informazioni sulle differenze tra queste operazioni API, consultare Credenziali di sicurezza temporanee in IAM e Controllo delle autorizzazioni per le credenziali di sicurezza temporanee.) La chiamata restituisce credenziali di sicurezza temporanee costituite da un ID chiave di AWS accesso, una chiave di accesso segreta e un token di sessione. L'applicazione del gestore identità rende tali credenziali di sicurezza provvisorie disponibili all'applicazione aziendale interna. L'applicazione può quindi utilizzare le credenziali provvisorie per effettuare chiamate a AWS direttamente. L'app memorizza le credenziali finché non scadono e in seguito richiede un nuovo set di credenziali temporanee. L'immagine seguente illustra questo scenario.

Esempio di flusso di lavoro in cui viene utilizzata un'applicazione personalizzata del gestore identità

Questo scenario ha i seguenti attributi:

  • L'applicazione del gestore identità ha le autorizzazioni per accedere all'API di servizio token IAM (STS) per creare le credenziali di sicurezza temporanee.

  • L'applicazione del gestore identità è in grado di verificare che i dipendenti siano autenticati nel sistema di autenticazione esistente.

  • Gli utenti possono ottenere un URL temporaneo che consente loro di accedere alla Console di AWS gestione (denominata Single Sign-on).

Per ulteriori informazioni sulla creazione di credenziali di sicurezza provvisorie, consultare Richiesta di credenziali di sicurezza temporanee. Per ulteriori informazioni sull'accesso degli utenti federati alla console di AWS gestione, consulta. Consentire agli utenti federati SAML 2.0 di accedere a AWS Management Console