Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Fédération SAML 2.0

AWS prend en charge la fédération d'identités avec SAML 2.0 (Security Assertion Markup Language 2.0), une norme ouverte utilisée par de nombreux fournisseurs d'identité (IdPs). Cette fonctionnalité permet l'authentification unique fédérée (SSO), afin que les utilisateurs puissent se connecter aux opérations d' AWS API Console de gestion AWS ou les appeler sans que vous ayez à créer un utilisateur IAM pour tous les membres de votre organisation. En utilisant SAML, vous pouvez simplifier le processus de configuration de la fédération avec AWS, car vous pouvez utiliser le service de l'IdP au lieu d'écrire un code proxy d'identité personnalisé.

La fédération IAM prend en charge les cas d'utilisation suivants :

Utilisation SAML-based de la fédération pour accéder à l'API AWS

Supposons que vous voulez permettre aux employés de copier les données de leurs ordinateurs dans un dossier de sauvegarde. Vous créez une application que les utilisateurs peuvent exécuter sur leurs ordinateurs. Sur l’instance principale, l’application lit et écrit les objets dans un compartiment Amazon S3. Les utilisateurs n'ont pas d'accès direct à AWS. À la place, le processus suivant est utilisé :

Présentation de la configuration de la fédération SAML 2.0

Avant de pouvoir utiliser la fédération basée sur SAML 2.0 comme décrit dans le scénario et le schéma précédents, vous devez configurer l'IdP de votre organisation et le vôtre Compte AWS pour qu'ils se fassent mutuellement confiance. La procédure suivante décrit le processus général permettant de configurer cette relation d'approbation. Votre organisation doit utiliser un IdP prenant en charge SAML 2.0, comme Microsoft Active Directory Federation Service (services ADFS qui font partie de Windows Server), Shibboleth, ou tout autre fournisseur compatible avec SAML 2.0.

Vue d'ensemble du rôle pour autoriser SAML-federated l'accès à votre AWS resources

Les rôles que vous créez dans IAM définissent ce que les principaux fédérés SAML de votre organisation sont en mesure d’effectuer dans AWS. Lorsque vous créez la politique d'approbation pour le rôle, vous spécifiez le fournisseur d'identité SAML créé précédemment en tant que Principal. Vous pouvez également ajouter une Condition à la politique d'approbation, afin d'autoriser uniquement les utilisateurs correspondant à certains attributs SAML à accéder au rôle. Par exemple, vous pouvez spécifier que seuls les utilisateurs dont l'affiliation SAML est staff (telle qu'affirmée parhttps://openidp.feide.no) sont autorisés à accéder au rôle, comme illustré par l'exemple de politique suivant :

JSON

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

JSON

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws-cn:iam::111122223333:saml-provider/ExampleOrgSSOProvider"
            },
            "Action": "sts:AssumeRoleWithSAML",
            "Condition": {
                "StringEquals": {
                    "saml:aud": "https://cn-north-1.signin.amazonaws.cn/saml",
                    "saml:iss": "https://openidp.feide.no"
                },
                "ForAllValues:StringLike": {
                    "saml:edupersonaffiliation": [
                        "staff"
                    ]
                }
            }
        }
    ]
}

La clé contextuelle saml:aud dans la politique spécifie l’URL que votre navigateur affiche lorsque vous vous connectez à la console. Cette URL de point de terminaison de connexion doit correspondre à l’attribut du destinataire de votre fournisseur d’identité. Vous pouvez inclure des URL de connexion dans des régions spécifiques. AWS recommande d'utiliser des points de terminaison régionaux au lieu du point de terminaison global pour améliorer la résilience de la fédération. Si vous n'avez configuré qu'un seul point de terminaison, vous ne pourrez pas vous fédérer AWS dans le cas peu probable où le point de terminaison deviendrait indisponible. Pour obtenir la liste des region-code valeurs possibles, consultez la colonne Région dans les AWS Sign-In points de .

L'exemple suivant montre le format de l'URL de connexion avec l'option region-code

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

Si le chiffrement SAML est obligatoire, l’URL de connexion doit inclure l’identifiant unique qu’ AWS attribue à votre fournisseur SAML, que vous trouverez sur la page de détails du fournisseur d’identité. Dans l’exemple suivant, l’URL de connexion comprend un identifiant unique d’IdP, qui nécessite l’ajout de /acs/ au chemin d’accès de connexion.

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

Vous spécifiez la politique d'autorisation dans le rôle comme pour tout autre rôle. Par exemple, si les utilisateurs de votre organisation sont autorisés à administrer des instances Amazon Elastic Compute Cloud, vous devez autoriser explicitement les actions Amazon EC2 dans la politique d'autorisations, comme celles figurant dans la politique AmazonEC2FullAccess gérée.

Pour plus d'informations sur les clés SAML que vous pouvez utiliser dans une politique, consultez Clés disponibles pour SAML-based AWS STS fédération.

Identification unique des utilisateurs au sein de SAML-based la fédération

Lors de la création de politiques d'accès dans IAM, il est souvent utile de pouvoir spécifier des autorisations en fonction de l'identité des utilisateurs. Par exemple, dans le cas d'utilisateurs fédérés à l'aide de SAML, une application peut conserver les informations dans Amazon S3 à l'aide d'une structure similaire à celle-ci :

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

Vous pouvez créer le compartiment (amzn-s3-demo-bucket) et le dossier (app1) via la console Amazon S3 ou via le AWS CLI, car il s'agit de valeurs statiques. Cependant, les dossiers spécifiques à l'utilisateur (user1user2,user3, etc.) doivent être créés au moment de l'exécution à l'aide de code, car la valeur qui identifie l'utilisateur n'est connue que lors de sa première connexion via le processus de fédération.

Pour créer des politiques qui référencent des détails spécifiques à l'utilisateur dans le nom d'une ressource, l'identité de l'utilisateur doit figurer dans des clés SAML pouvant être utilisées dans les conditions des politiques. Les clés suivantes sont disponibles pour la fédération basée sur SAML 2.0 à utiliser dans les politiques IAM. Vous pouvez utiliser les valeurs retournées par les clés suivantes pour créer des identifiants utilisateur uniques pour des ressources comme des dossiers Amazon S3.

L'exemple suivant illustre une politique d'autorisation qui utilise les clés précédentes pour accorder des autorisations à un dossier spécifique à un utilisateur dans Amazon S3. La politique suppose que les objets Amazon S3 sont identifiés à l'aide d'un préfixe qui inclut à la fois saml:namequalifier et saml:sub. Notez que l'élément Condition inclut un test pour vérifier que la valeur de saml:sub_type est définie sur persistent. Si la valeur est transient, l'élément saml:sub de l'utilisateur peut être différent pour chaque session et vous ne devez pas combiner les valeurs pour identifier des dossiers spécifiques aux utilisateurs.

JSON

{
  "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"}}
  }
}

JSON

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

Pour plus d'informations sur le mappage d'assertions de l'IdP et les clés de politique, consultez Configuration d’assertions SAML pour la réponse d’authentification.