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

Federazione SAML 2.0

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 back-end, 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:

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.

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

Il ruolo o i ruoli creati in IAM definiscono ciò che gli utenti federati dell'organizzazione possono fare in 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://signin.aws.amazon.com/saml",
        "saml:iss": "https://openidp.feide.no"
      },
      "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]}
    }
  }]
}

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

Puoi includere endpoint regionali per l'attributo saml:aud in https://region-code.signin.aws.amazon.com/static/saml-metadata.xml. Per un elenco dei possibili valori di region-code, consulta la colonna Region (Regione) in Endpoint di accesso AWS.

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

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:

myBucket/app1/user1
myBucket/app1/user2
myBucket/app1/user3

Puoi creare il bucket (myBucket) 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 e così via) devono essere create in fase di runtime utilizzando il codice, poiché il valore che identifica l'utente non è noto fino al primo accesso dell'utente 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.

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:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws:s3:::exampleorgBucket/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.