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é avec SAML 2.0 (Security Assertion Markup Language 2.0), un standard ouvert utilisé 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 de l' AWS API AWS Management Console 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 de la fédération SAML pour l'accès à 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 le back-end, l'application lit et écrit des objets dans un compartiment Amazon S3. Les utilisateurs n'ont pas un 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 de manière à ce qu'ils se fassent mutuellement confiance. Compte AWS 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 permettant d'autoriser l'accès fédéré par SAML à vos ressources AWS

Les rôles que vous créez dans IAM définissent les actions que les utilisateurs fédérés 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, il est possible de spécifier que seuls les utilisateurs dont l'affiliation SAML est staff (comme stipulé sur https://openidp.feide.no) sont autorisés à accéder au rôle, comme illustré dans l'exemple de politique suivant :

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

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

Vous pouvez inclure des points de terminaison régionaux pour l'attribut saml:aud à l'adresse https://region-code.signin.aws.amazon.com/static/saml-metadata.xml. Pour obtenir la liste des valeurs possibles de region-code, consultez la colonne Region (Région) des AWS Sign-In endpoints (Points de terminaison de connexion).

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 explicitement autoriser les actions Amazon EC2 dans la politique d'autorisation, telles que celles figurant dans la politique gérée d'Amazon FullAccess EC2.

Identification unique des utilisateurs dans la fédération SAML

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 :

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

Vous pouvez créer le compartiment (myBucket) et le dossier (app1) via la console Amazon S3 ou le AWS CLI, car il s'agit de valeurs statiques. Toutefois, les dossiers spécifiques aux utilisateurs (utilisateur1, utilisateur2, utilisateur3, etc.) doivent être créés à l'aide de code lors de l'exécution, car la valeur qui identifie l'utilisateur n'est pas connue jusqu'à la première authentification de l'utilisateur 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.

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

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