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)
La federazione IAM supporta i casi d'uso indicati di seguito.
-
Accesso federato per consentire a un utente o a un'applicazione dell'organizzazione di chiamare le operazioni AWS API. Questo caso d'uso è discusso nella sezione seguente. viene utilizzata un'asserzione SAML (come parte della risposta di autenticazione) generata nell'organizzazione per ottenere credenziali di sicurezza temporanee. Questo scenario è analogo ad altri scenari di federazione supportati da IAM, come descritto in Richiedere credenziali di sicurezza temporanee e Federazione OIDC. Tuttavia, la soluzione basata su SAML 2.0 dell'organizzazione gestisce molti dettagli IdPs in fase di esecuzione per eseguire il controllo dell'autenticazione e delle autorizzazioni.
-
Single Sign-On (SSO) basato sul Web da e verso l'organizzazione. AWS Management Console Gli utenti possono accedere a un portale dell'organizzazione ospitato da un IdP compatibile con SAML 2.0, selezionare un'opzione a cui accedere ed essere reindirizzati AWS alla console senza dover fornire ulteriori informazioni di accesso. Puoi utilizzare un IdP SAML di terze parti per stabilire l'accesso SSO alla console o creare un IdP personalizzato per consentire l'accesso alla console per utenti esterni. Per ulteriori informazioni sulla creazione di un provider di identità personalizzato, consulta Abilita l'accesso personalizzato del broker di identità alla AWS console.
Argomenti
- Utilizzo della federazione basata su SAML per l'accesso API ad AWS
- Panoramica della configurazione della federazione basata su SAML 2.0
- Panoramica del ruolo per consentire l'accesso federato SAML alle tue risorse AWS
- Identificazione univoca degli utenti nella federazione basata su SAML
- Creare un provider di identità SAML in IAM
- Configurare il provider di identità SAML 2.0 con una relazione di attendibilità della parte affidabile e aggiunta di attestazioni
- Integra fornitori di soluzioni SAML di terze parti con AWS
- Configurare le asserzioni SAML per la risposta di autenticazione
- Consentire agli utenti federati SAML 2.0 di accedere a AWS Management Console
- Visualizzare una risposta SAML nel browser
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:
-
Un utente dell'organizzazione utilizza un'app client per richiedere l'autenticazione dal provider di identità della propria organizzazione.
-
Il provider di identità autentica l'utente rispetto all'archivio identità organizzazione.
-
Il provider di identità crea un'asserzione SAML con informazioni sull'utente e invia l'asserzione all'app client.
-
L'app client chiama l' AWS STS
AssumeRoleWithSAML
API, passando l'ARN del provider SAML, l'ARN del ruolo da assumere e l'asserzione SAML di IdP. -
La risposta dell'API all'app client include credenziali di sicurezza temporanee.
-
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
-
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.xmlPer 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
. -
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. -
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.
-
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.
-
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.
-
Nell'applicazione che stai creando, chiami l' AWS Security Token Service
AssumeRoleWithSAML
API, 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
-
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
,, user2
user3
, 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 rispostaIssuer
(saml:iss
) e una stringa con l'ID accountAWS
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 chiavesaml: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 chiavesaml:doc
in Chiavi disponibili per la AWS STS federazione SAML basata.La combinazione di
NameQualifier
eSubject
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 eBase64
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ò esserepersistent
,transient
o l'URIFormat
completo degli elementiSubject
eNameID
utilizzati nell'asserzione SAML. Il valorepersistent
indica che il valore insaml:sub
è lo stesso per un utente in tutte le sessioni. Se il valore ètransient
, l'utente dispone di un valoresaml:sub
diverso per ogni sessione. Per ulteriori informazioni sull'attributoFormat
dell'elementoNameID
, 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.