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

Creare un ruolo per un provider di identità di terze parti

Puoi utilizzare provider di identità invece di creare utenti IAM nel tuo Account AWS. Con un provider di identità (IdP), puoi gestire le tue identità utente all'esterno AWS e concedere a queste identità utente esterne le autorizzazioni per accedere AWS alle risorse del tuo account. Per ulteriori informazioni sulla federazione e sui provider di identità, consultare Provider di identità e federazione.

Creazione di un ruolo per i presidi federati OIDC e SAML (console)

Le procedure per la creazione di un ruolo dipendono dalla scelta dei fornitori terzi:

Creazione di un ruolo per l'accesso federato (AWS CLI)

Le procedure per creare un ruolo per il provider di identità supportato (OIDC o SAML) dalla AWS CLI sono identiche. La differenza consiste nel contenuto della policy di affidabilità creata in passaggi preliminari. Inizia seguendo le fasi descritte nella sezione dei prerequisiti per il tipo di provider in uso:

La creazione di un ruolo da AWS CLI richiede più passaggi. Quando si utilizza la console per creare un ruolo, molti passaggi vengono eseguiti automaticamente, ma con la console AWS CLI è necessario eseguire esplicitamente ogni passaggio da soli. È necessario creare il ruolo e quindi assegnargli una policy di autorizzazione. Puoi anche scegliere di impostare il limite delle autorizzazioni per il ruolo.

L'esempio seguente mostra i primi due passaggi, più comuni, per la creazione di un ruolo del provider di identità in un ambiente semplice. Questo esempio permette agli utenti dell'account 123456789012 di assumere il ruolo e visualizzare il bucket example_bucket di Amazon S3. Questo esempio presuppone inoltre che tu stia eseguendo Windows AWS CLI su un computer che esegue Windows e che lo abbia già configurato AWS CLI con le tue credenziali. Per ulteriori informazioni, consultare la pagina relativa alla configurazione di AWS Command Line Interface.

La policy di attendibilità di esempio riportata di seguito è progettata per un'app per dispositivi mobili in cui l'utente accede tramite Amazon Cognito. In questo esempio, us-east:12345678-ffff-ffff-ffff-123456 rappresenta l'ID del pool di identità assegnato da Amazon Cognito.

JSON

{
    "Version": "2012-10-17",
    "Statement": {
        "Sid": "RoleForCognito",
        "Effect": "Allow",
        "Principal": {"Federated": "cognito-identity.amazonaws.com"},
        "Action": "sts:AssumeRoleWithWebIdentity",
        "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
    }
}

La policy delle autorizzazioni seguente consente agli utenti che assumono il ruolo di eseguire solo l'operazione ListBucket sul bucket example_bucket di Amazon S3.

JSON

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::example_bucket"
  }
}

Per creare questo ruolo Test-Cognito-Role, è prima necessario salvare la policy di attendibilità precedente con il nome trustpolicyforcognitofederation.json e la policy di autorizzazione precedente con il nome permspolicyforcognitofederation.json nella cartella policies dell'unità C: locale. È quindi possibile utilizzare i comandi seguenti per creare il ruolo e collegare la policy inline.

# Create the role and attach the trust policy that enables users in an account to assume the role.
$ aws iam create-role --role-name Test-Cognito-Role --assume-role-policy-document file://C:\policies\trustpolicyforcognitofederation.json

# Attach the permissions policy to the role to specify what it is allowed to do.
aws iam put-role-policy --role-name Test-Cognito-Role --policy-name Perms-Policy-For-CognitoFederation --policy-document file://C:\policies\permspolicyforcognitofederation.json

Creazione di un ruolo per l'accesso federato (API)AWS

Le procedure per creare un ruolo per il provider di identità supportato (OIDC o SAML) dalla AWS CLI sono identiche. La differenza consiste nel contenuto della policy di affidabilità creata in passaggi preliminari. Inizia seguendo le fasi descritte nella sezione dei prerequisiti per il tipo di provider in uso: