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.

SAMLfédération 2.0

AWS prend en charge la fédération d'identité avec SAML2.0 (Security Assertion Markup Language 2.0), une norme ouverte utilisée par de nombreux fournisseurs d'identité (IdPs). Cette fonctionnalité active l'authentification unique fédérée (SSO), afin que les utilisateurs puissent se connecter au AWS Management Console ou appelez AWS APIopérations sans que vous ayez à créer un IAM utilisateur pour tous les membres de votre organisation. En utilisantSAML, 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 de la fédération basée pour API accéder à 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 d'accès direct à AWS. Au lieu de cela, le processus suivant est utilisé :

Présentation de la configuration de la fédération basée sur la SAML version 2.0

Avant de pouvoir utiliser la fédération 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 votre Compte AWS de se faire confiance. La procédure suivante décrit le processus général permettant de configurer cette relation d'approbation. Au sein de votre organisation, vous devez disposer d'un IdP compatible avec la SAML version 2.0, comme Microsoft Active Directory Federation Service (AD FS, intégré à Windows Server), Shibboleth ou un autre fournisseur 2.0 compatible. SAML

Vue d'ensemble du rôle permettant d'autoriser l'accès SAML fédéré à votre AWS resources

Le ou les rôles que vous créez dans IAM définissent ce que les utilisateurs fédérés de votre organisation sont autorisés à faire dans AWS. Lorsque vous créez la politique de confiance pour le rôle, vous spécifiez le SAML fournisseur que vous avez créé précédemment en tant quePrincipal. Vous pouvez également définir la politique de confiance avec un Condition pour autoriser uniquement les utilisateurs correspondant à certains SAML attributs à accéder au rôle. Par exemple, vous pouvez spécifier que seuls les utilisateurs dont l'SAMLaffiliation est staff (telle qu'affirmée par https://openidp.feide.no) sont autorisés à accéder au rôle, comme l'illustre 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 SAML clés que vous pouvez enregistrer dans une politique, consultezClés disponibles pour la AWS STS fédération SAML basée.

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 une liste des possibilités region-code valeurs, voir la colonne Région dans AWS 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 EC2 actions d'Amazon dans la politique d'autorisation, telles que celles figurant dans la politique EC2FullAccess gérée par Amazon.

Identification unique des utilisateurs dans le cadre SAML d'une fédération basée

Lorsque vous créez des politiques d'accès dansIAM, il est souvent utile de pouvoir spécifier des autorisations en fonction de l'identité des utilisateurs. Par exemple, pour les utilisateurs qui ont été fédérés à l'aide deSAML, une application peut souhaiter conserver des informations dans Amazon S3 en utilisant une structure comme 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 le AWS CLI, car il s'agit de valeurs statiques. Toutefois, les dossiers spécifiques à l'utilisateur (user1, user2, user3, etc.) doivent être créés au moment de l'exécution à l'aide de code, car la valeur identifiant l'utilisateur n'est connue que lors de sa première connexion dans le cadre du processus de fédération.

Pour écrire des politiques qui font référence à des informations spécifiques à l'utilisateur dans le cadre du nom d'une ressource, l'identité de l'utilisateur doit être disponible dans des SAML clés pouvant être utilisées dans des conditions de politique. Les clés suivantes sont disponibles pour la fédération SAML basée sur la version 2.0 à utiliser dans IAM les politiques. 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:::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"}}
  }
}

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