Seleziona le tue preferenze relative ai cookie

Utilizziamo cookie essenziali e strumenti simili necessari per fornire il nostro sito e i nostri servizi. Utilizziamo i cookie prestazionali per raccogliere statistiche anonime in modo da poter capire come i clienti utilizzano il nostro sito e apportare miglioramenti. I cookie essenziali non possono essere disattivati, ma puoi fare clic su \"Personalizza\" o \"Rifiuta\" per rifiutare i cookie prestazionali.

Se sei d'accordo, AWS e le terze parti approvate utilizzeranno i cookie anche per fornire utili funzionalità del sito, ricordare le tue preferenze e visualizzare contenuti pertinenti, inclusa la pubblicità pertinente. Per continuare senza accettare questi cookie, fai clic su \"Continua\" o \"Rifiuta\". Per effettuare scelte più dettagliate o saperne di più, fai clic su \"Personalizza\".

Federazione SAML 2.0

Modalità Focus
Federazione SAML 2.0 - 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à.

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

AWS supporta la federazione delle identità con SAML 2.0 (Security Assertion Markup Language 2.0), uno standard aperto utilizzato da molti provider di identità (IdPs). Questa funzionalità abilita il single sign-on (SSO) federato, in modo che gli utenti possano accedere AWS Management Console o chiamare le operazioni AWS API senza che tu debba creare un utente IAM per tutti i membri dell'organizzazione. Utilizzando SAML, puoi semplificare il processo di configurazione della federazione AWS, poiché puoi utilizzare il servizio dell'IdP invece di scrivere un codice proxy di identità personalizzato.

La federazione IAM supporta i casi d'uso indicati di seguito.

Utilizzo della federazione basata su SAML per l'accesso API ad AWS

Supponi di voler fornire ai dipendenti un modo per copiare i dati dai loro computer a una cartella di backup. È possibile creare un'applicazione che gli utenti possono eseguire sui propri computer. Sul backend, l'applicazione legge e scrive oggetti in un bucket Amazon S3. Gli utenti non hanno accesso diretto a. AWS viene utilizzato invece il seguente processo:

  1. Un utente dell'organizzazione utilizza un'app client per richiedere l'autenticazione dal provider di identità della propria organizzazione.

  2. Il provider di identità autentica l'utente rispetto all'archivio identità organizzazione.

  3. Il provider di identità crea un'asserzione SAML con informazioni sull'utente e invia l'asserzione all'app client.

  4. L'app client chiama l' AWS STS AssumeRoleWithSAMLAPI, passando l'ARN del provider SAML, l'ARN del ruolo da assumere e l'asserzione SAML di IdP.

  5. La risposta dell'API all'app client include credenziali di sicurezza temporanee.

  6. L'app client utilizza le credenziali di sicurezza temporanee per chiamare le operazioni dell'API di Amazon S3.

Panoramica della configurazione della federazione basata su SAML 2.0

Prima di poter utilizzare la federazione basata su SAML 2.0 come descritto nello scenario e nel diagramma precedenti, devi configurare l'IdP dell'organizzazione e il tuo in modo che si fidino l'uno dell'altro. Account AWS Di seguito è descritta la procedura generale per la configurazione di questo tipo di attendibilità. All'interno dell'organizzazione, è necessario disporre di un provider di identità che supporti SAML 2.0, come Microsoft Active Directory Federation Service (ADFS, parte di Windows Server), Shibboleth o di un altro provider compatibile con SAML 2.0.

Nota

Per migliorare la resilienza della federazione, ti consigliamo di configurare l'IdP e la federazione AWS per supportare più endpoint di accesso SAML. Per i dettagli, consulta l'articolo del AWS Security Blog Come utilizzare gli endpoint SAML regionali per il failover.

Configura l'IdP della tua organizzazione e fidati AWS l'uno dell'altro
  1. Registrati AWS come fornitore di servizi (SP) con l'IdP della tua organizzazione. Utilizzo del documento dei metadati SAML generato da https://region-code.signin.aws.amazon.com/static/saml-metadata.xml

    Per un elenco dei region-code valori possibili, consulta la colonna Regione negli endpoint di AWS accesso.

    Se lo desideri, puoi utilizzare il documento dei metadati SAML generati da https://signin.aws.amazon.com/static/saml-metadata.xml .

  2. Utilizzando l'IdP della tua organizzazione, generi un file XML di metadati SAML equivalente che può descrivere il tuo IdP come provider di identità IAM in. AWS Deve includere il nome dell'emittente, una data di creazione, una data di scadenza e le chiavi che AWS possono essere utilizzate per convalidare le risposte di autenticazione (asserzioni) dell'organizzazione.

    Nota

    Come definito dal profilo di interoperabilità dei metadati SAML V2.0 versione 1.0, IAM non valuta né interviene sulla scadenza dei certificati X.509 nei documenti di metadati SAML. Se sei preoccupato per i certificati X.509 scaduti, ti consigliamo di monitorare le date di scadenza dei certificati e di ruotare i certificati in base alle politiche di governance e sicurezza della tua organizzazione.

  3. Nella console IAM, crea un'entità provider di identità SAML. Come parte di questo processo, è possibile caricare il documento dei metadati SAML prodotto dal provider di identità nell'organizzazione in Passo 2. Per ulteriori informazioni, consulta Creare un provider di identità SAML in IAM.

  4. In IAM, vengono creati uno o più ruoli IAM. Nella politica di fiducia del ruolo, imposti il provider SAML come principale, che stabilisce una relazione di fiducia tra la tua organizzazione e. AWS La policy di autorizzazione del ruolo stabilisce le operazioni che gli utenti dell'organizzazione possono effettuare in AWS. Per ulteriori informazioni, consulta Creare un ruolo per un provider di identità di terza parte (federazione).

    Nota

    SAML IDPs utilizzato in una politica di fiducia per i ruoli deve trovarsi nello stesso account in cui si trova il ruolo.

  5. Nel provider di identità dell'organizzazione, si definiscono asserzioni che associano utenti o gruppi dell'organizzazione ai ruoli IAM. Nota che i diversi utenti e gruppi dell'organizzazione potrebbero essere mappati a diversi ruoli IAM. La procedura per eseguire la mappatura dipende dal provider di identità che si sta utilizzando. Nello scenario precedente che utilizza una cartella Amazon S3 per gli utenti, è possibile che tutti gli utenti dispongano della mappatura allo stesso ruolo che fornisce le autorizzazioni Amazon S3. Per ulteriori informazioni, consulta Configurare le asserzioni SAML per la risposta di autenticazione.

    Se il tuo IdP abilita l'SSO AWS sulla console, puoi configurare la durata massima delle sessioni della console. Per ulteriori informazioni, consulta Consentire agli utenti federati SAML 2.0 di accedere a AWS Management Console.

  6. Nell'applicazione che stai creando, chiami l' AWS Security Token Service AssumeRoleWithSAMLAPI, passandole l'ARN del provider SAML in cui hai creato, Passo 3 l'ARN del ruolo da assumere in cui hai creato e l'asserzione SAML sull'utente corrente che ricevi dal tuo IdP. Passo 4 AWS si assicura che la richiesta di assunzione del ruolo provenga dall'IdP a cui si fa riferimento nel provider SAML.

    Per ulteriori informazioni, consulta AssumeRoleWithSAML nell'API Reference.AWS Security Token Service

  7. Se la richiesta ha esito positivo, l'API restituisce una serie di credenziali di sicurezza temporanee, che l'applicazione può utilizzare per inviare richieste firmate ad AWS. L'applicazione contiene informazioni sull'utente corrente e può accedere a cartelle specifiche dell'utente in Amazon S3, come descritto nello scenario precedente.

Panoramica del ruolo per consentire l'accesso federato SAML alle tue risorse AWS

I ruoli che crei in IAM definiscono ciò che gli utenti federati della tua organizzazione possono fare. AWS Quando si creano policy di affidabilità per il ruolo, è necessario specificare il provider SAML creato in precedenza come Principal. È inoltre possibile estendere la policy di affidabilità con un elemento Condition per permettere solo agli utenti che corrispondono ad alcuni attributi SAML di accedere al ruolo. Ad esempio, è possibile specificare che solo gli utenti con l'affiliazione SAML staff (come affermato da https://openidp.feide.no) possono accedere al ruolo, come illustrato dalla seguente policy di esempio:

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Federated": "arn:aws:iam::account-id:saml-provider/ExampleOrgSSOProvider"}, "Action": "sts:AssumeRoleWithSAML", "Condition": { "StringEquals": { "saml:aud": "https://us-west-2.signin.aws.amazon.com/saml", "saml:iss": "https://openidp.feide.no" }, "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]} } }] }
Nota

SAML IDPs utilizzato in una politica di fiducia dei ruoli deve trovarsi nello stesso account in cui si trova il ruolo.

La chiave di saml:aud contesto nella politica specifica l'URL visualizzato dal browser quando si accede alla console. L'URL dell'endpoint di accesso deve corrispondere all'attributo destinatario del provider di identità. Puoi includere l'accesso URLs all'interno di aree geografiche particolari. AWS consiglia di utilizzare gli endpoint regionali anziché l'endpoint globale per migliorare la resilienza della federazione. Se hai configurato un solo endpoint, non sarai in grado di eseguire la federazione AWS nell'improbabile eventualità che l'endpoint diventi non disponibile. Per un elenco dei region-code valori possibili, consulta la colonna Regione negli AWS endpoint di accesso.

L'esempio seguente mostra il formato dell'URL di accesso con l'opzione. region-code

https://region-code.signin.aws.amazon.com/saml

Se è richiesta la crittografia SAML, l'URL di accesso deve includere l'identificatore univoco AWS assegnato al provider SAML, che puoi trovare nella pagina dei dettagli del provider di identità. Nell'esempio seguente, l'URL di accesso include l'identificatore univoco IdP, che richiede l'aggiunta di /acs/ al percorso di accesso.

https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID

Per la policy di autorizzazione nel ruolo, è necessario specificare le autorizzazioni come per qualsiasi ruolo. Ad esempio, se gli utenti della tua organizzazione sono autorizzati ad amministrare istanze di Amazon Elastic Compute Cloud, devi consentire esplicitamente le azioni di EC2 Amazon nella politica delle autorizzazioni, come quelle nella policy gestita di Amazon. EC2 FullAccess

Per ulteriori informazioni sulle chiavi SAML che è possibile verificare in una policy, consulta Chiavi disponibili per la AWS STS federazione SAML basata.

Identificazione univoca degli utenti nella federazione basata su SAML

Quando si creano policy di accesso in IAM, spesso è utile poter specificare le autorizzazioni in base all'identità degli utenti. Ad esempio, per gli utenti che sono stati federati tramite SAML, un'applicazione potrebbe voler mantenere le informazioni in Amazon S3 utilizzando una struttura come questa:

amzn-s3-demo-bucket/app1/user1 amzn-s3-demo-bucket/app1/user2 amzn-s3-demo-bucket/app1/user3

Puoi creare il bucket (amzn-s3-demo-bucket) e la cartella (app1) tramite la console Amazon S3 o AWS CLI il, poiché si tratta di valori statici. Tuttavia, le cartelle specifiche dell'utente (user1,, user2user3, ecc.) devono essere create in fase di esecuzione utilizzando il codice, poiché il valore che identifica l'utente non è noto fino alla prima volta che l'utente accede tramite il processo di federazione.

Per scrivere policy che fanno riferimento ai dettagli specifici dell'utente come parte di un nome di risorsa, l'identità dell'utente deve essere disponibile nelle chiavi SAML che possono essere utilizzate nelle condizioni di policy. Le seguenti chiavi sono disponibili per la federazione basata su SAML 2.0 da utilizzare nelle policy IAM. È possibile utilizzare i valori restituiti dalle chiavi seguenti per creare identificativi utente univoci per risorse come le cartelle Amazon S3.

  • saml:namequalifier. Un valore hash basato sulla concatenazione del valore della risposta Issuer (saml:iss) e una stringa con l'ID account AWS e il nome descrittivo (l'ultima parte dell'ARN) del provider SAML in IAM. La concatenazione dell'ID account e del nome descrittivo del provider SAML è disponibile per le policy IAM sotto forma di chiave saml:doc. L'ID account e il nome del provider devono essere separati da una barra "/" come in "123456789012/provider_name". Per ulteriori informazioni, consulta la chiave saml:doc in Chiavi disponibili per la AWS STS federazione SAML basata.

    La combinazione di NameQualifier e Subject può essere utilizzata per identificare in modo univoco un utente federato. Il seguente pseudocodice mostra come viene calcolato questo valore. In questo pseudocodice + indica la concatenazione, SHA1 rappresenta una funzione che produce un digest del messaggio utilizzando SHA-1 e Base64 rappresenta una funzione che genera una versione con codificazione Base-64 dell'output hash.

    Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )

    Per ulteriori informazioni sulle chiavi di policy disponibili quando si utilizza la federazione basata su SAML, consulta Chiavi disponibili per la AWS STS federazione SAML basata.

  • saml:sub (Stringa). Questo è l'oggetto della richiesta, che include un valore che identifica in modo univoco un singolo utente in un'organizzazione (ad esempio, _cbb88bf52c2510eabe00c1642d4643f41430fe25e3).

  • saml:sub_type (Stringa). Questa chiave può essere persistent, transient o l'URI Format completo degli elementi Subject e NameID utilizzati nell'asserzione SAML. Il valore persistent indica che il valore in saml:sub è lo stesso per un utente in tutte le sessioni. Se il valore è transient, l'utente dispone di un valore saml:sub diverso per ogni sessione. Per ulteriori informazioni sull'attributo Format dell'elemento NameID, consulta Configurare le asserzioni SAML per la risposta di autenticazione.

L'esempio seguente mostra una policy di autorizzazione che utilizza le chiavi precedenti per concedere le autorizzazioni a una cartella specifica per utente in Amazon S3. La policy presuppone che gli oggetti Amazon S3 vengano identificati utilizzando un prefisso che include sia saml:namequalifier che saml:sub. Si noti che l'elemento Condition include un test per assicurarsi che saml:sub_type sia impostato su persistent. Se è impostato su transient, il valore saml:sub per l'utente può essere diverso per ogni sessione e la combinazione di valori non deve essere utilizzata per identificare le cartelle specifiche dell'utente.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}", "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*" ], "Condition": {"StringEquals": {"saml:sub_type": "persistent"}} } }

Per ulteriori informazioni sulle asserzioni di mappatura dal provider di identità alle chiavi di policy, consulta Configurare le asserzioni SAML per la risposta di autenticazione.

PrivacyCondizioni del sitoPreferenze cookie
© 2025, Amazon Web Services, Inc. o società affiliate. Tutti i diritti riservati.