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)](https://wiki.oasis-open.org/security), 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é](https://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingFedTokens.html). **Note** La fédération d'identité IAM SAML prend en charge les réponses SAML cryptées provenant de fournisseurs d'identité fédérés basés sur le protocole SAML (). IdPs IAM Identity Center et Amazon Cognito ne prennent pas en charge les assertions SAML chiffrées provenant des fournisseurs d’identité SAML IAM. Vous pouvez ajouter indirectement la prise en charge des assertions SAML chiffrées à la fédération des groupes d’identités Amazon Cognito avec les groupes d’utilisateurs Amazon Cognito. Les groupes d’utilisateurs disposent d’une fédération SAML indépendante de la fédération SAML IAM et qui prend en charge la [signature et le chiffrement SAML](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-SAML-signing-encryption.html). Bien que cette fonctionnalité ne s'étende pas directement aux groupes d'identités, les groupes d'utilisateurs peuvent être destinés IdPs aux groupes d'identités. Pour utiliser le chiffrement SAML avec des groupes d’identités, ajoutez un fournisseur SAML avec chiffrement à un groupe d’utilisateurs qui est un IdP d’un groupe d’identités. Votre fournisseur SAML doit être en mesure de chiffrer les assertions SAML à l’aide d’une clé fournie par votre groupe d’utilisateurs. Les groupes d’utilisateurs n’accepteront pas les assertions chiffrées à l’aide d’un certificat fourni par IAM. La fédération IAM prend en charge les cas d'utilisation suivants : + [**Accès fédéré pour permettre à un utilisateur ou à une application de votre organisation d'appeler des opérations AWS d'API**](#CreatingSAML-configuring). Ce cas d’utilisation est traité dans la section suivante. Vous utilisez une assertion SAML (dans le cadre de la réponse d'authentification) qui est générée dans votre organisation pour l'obtention d'informations d'identification temporaires. Ce scénario est similaire à d'autres scénarios de fédération pris en charge par IAM, tels que ceux décrits dans [Demande d’identifiants de sécurité temporaires](id_credentials_temp_request.md) et [Fédération OIDC](id_roles_providers_oidc.md). Toutefois, les systèmes SAML 2.0 de votre IdPs organisation gèrent de nombreux détails lors de l'exécution de l'authentification et de la vérification des autorisations. + [**Authentification unique (SSO) basée sur le Web AWS Management Console auprès de votre organisation**](id_roles_providers_enable-console-saml.md). Les utilisateurs peuvent se AWS connecter à un portail de votre organisation hébergé par un IdP compatible SAML 2.0, sélectionner une option d'accès et être redirigés vers la console sans avoir à fournir d'informations de connexion supplémentaires. Vous pouvez utiliser un IdP SAML tiers pour établir un accès SSO à la console ou créer un IdP personnalisé pour autoriser l'accès de vos utilisateurs externes à la console. Pour plus d'informations sur la création d'un IdP personnalisé, consultez la page [Permettre à un courtier d'identité personnalisé d'accéder à la AWS console](id_roles_providers_enable-console-custom-url.md). **Topics** + [Utilisation de la fédération basée sur SAML pour l'accès à l'API AWS](#CreatingSAML-configuring) + [Présentation de la configuration de la fédération SAML 2.0](#CreatingSAML-configuring-IdP) + [Vue d'ensemble du rôle permettant d'autoriser l'accès fédéré par SAML à vos ressources AWS](#CreatingSAML-configuring-role) + [Identification unique des utilisateurs dans la fédération SAML](#CreatingSAML-userid) + [Création d’un fournisseur d’identité SAML dans IAM](id_roles_providers_create_saml.md) + [Configuration de votre IdP SAML 2.0 à l’aide d’une relation d’approbation des parties utilisatrices et ajout de demandes](id_roles_providers_create_saml_relying-party.md) + [Intégrez des fournisseurs de solutions SAML tiers avec AWS](id_roles_providers_saml_3rd-party.md) + [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md) + [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md) + [Affichage d’une réponse SAML dans votre navigateur](troubleshoot_saml_view-saml-response.md) ## Utilisation de la fédération basée sur 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 l’instance principale, l’application lit et écrit les objets dans un compartiment Amazon S3. Les utilisateurs n'ont pas un accès direct à AWS. À la place, le processus suivant est utilisé : ![Obtention d'informations d'identification de sécurité temporaires basée sur une assertion SAML](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/saml-based-federation-diagram.png) 1. A l'aide d'une application cliente, un utilisateur de l'organisation demande son authentification par l'IdP de l'organisation. 1. L'IdP authentifie l'utilisateur en le comparant à la base d'identités de l'organisation. 1. L'IdP crée une assertion SAML à l'aide des informations concernant l'utilisateur et l'envoie à l'application client. Lorsque vous activez le chiffrement SAML pour votre IdP SAML IAM, cette assertion est chiffrée par votre IdP externe. 1. L'application cliente appelle l' AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)API en transmettant l'ARN du fournisseur SAML, l'ARN du rôle à assumer et l'assertion SAML de l'IdP. Si le chiffrement est activé, l’assertion transmise via l’application cliente reste chiffrée pendant le transfert. 1. (Facultatif) AWS STS utilise la clé privée que vous avez téléchargée depuis votre IdP externe pour déchiffrer l'assertion SAML cryptée. 1. La réponse de l'API à l'application cliente inclut des informations d'identification de sécurité temporaires. 1. L'application cliente utilise ces informations d'identification de sécurité temporaires pour appeler les opérations d'API Amazon S3. ## 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](id_roles_providers_saml_3rd-party.md), comme Microsoft Active Directory Federation Service (services ADFS qui font partie de Windows Server), Shibboleth, ou tout autre fournisseur compatible avec SAML 2.0. **Note** Pour améliorer la résilience de la fédération, nous vous recommandons de configurer votre IdP et votre fédération AWS pour prendre en charge plusieurs points de terminaison de connexion SAML. Pour plus de détails, consultez l'article du blog sur la AWS sécurité [Comment utiliser les points de terminaison SAML régionaux pour](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover) le basculement. **Configurez l'IdP de votre organisation et AWS faites-vous confiance** 1. Inscrivez-vous AWS en tant que fournisseur de services (SP) auprès de l'IdP de votre organisation. Utilisez le document de métadonnées SAML à partir de `https://{{region-code}}.signin.aws.amazon.com/static/saml-metadata.xml` Pour obtenir la liste des {{region-code}} valeurs possibles, consultez la colonne **Région** dans les points de [terminaison de AWS connexion](https://docs.aws.amazon.com/general/latest/gr/signin-service.html). Vous pouvez éventuellement utiliser le document de métadonnées SAML à partir de `https://signin.aws.amazon.com/static/saml-metadata.xml` . 1. À l’aide de l’IdP de l’organisation, vous générez un fichier XML de métadonnées SAML équivalent, capable de décrire cet IdP en tant que fournisseur d’identité IAM dans AWS. Il doit inclure le nom de l'émetteur, une date de création, une date d'expiration et les clés qui AWS peuvent être utilisées pour valider les réponses d'authentification (assertions) de votre organisation. Si vous autorisez l'envoi d'assertions SAML chiffrées depuis votre IdP externe, vous devez générer un fichier de clé privée à l'aide de l'IdP de votre organisation et télécharger ce fichier dans votre configuration IAM SAML au format de fichier .pem. AWS STS a besoin de cette clé privée pour déchiffrer les réponses SAML qui correspondent à la clé publique téléchargée sur votre IdP. **Note** Comme défini par la [version 1.0 du profil d’interopérabilité des métadonnées SAML V2.0](https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-os.html), IAM n’évalue pas et ne prend aucune mesure concernant l’expiration des certificats X.509 dans les documents de métadonnées SAML. Si vous êtes préoccupé par les certificats X.509 expirés, nous vous recommandons de surveiller les dates d’expiration des certificats et de les renouveler conformément aux politiques de gouvernance et de sécurité de votre organisation. 1. Dans la console IAM, vous créez un fournisseur d’identité SAML. Au cours du processus, vous chargez le document de métadonnées SAML et la clé de déchiffrement privée générés par l’IdP de votre organisation à l’étape [Step 2](#createxml). Pour de plus amples informations, veuillez consulter [Création d’un fournisseur d’identité SAML dans IAM](id_roles_providers_create_saml.md). 1. Dans IAM, créez un ou plusieurs rôles IAM. Dans la politique de confiance du rôle, vous définissez le fournisseur SAML comme principal, ce qui établit une relation de confiance entre votre organisation et AWS. La politique d'autorisation du rôle détermine les actions que les utilisateurs de l'organisation sont autorisés à effectuer dans AWS. Pour de plus amples informations, veuillez consulter [Créer un rôle pour un fournisseur d’identité tiers](id_roles_create_for-idp.md). **Note** Le SAML IDPs utilisé dans une politique de confiance des rôles doit se trouver dans le même compte que celui dans lequel se trouve le rôle. 1. Dans l'IdP de l'organisation, vous définissez les assertions qui associent les utilisateurs et les groupes de l'organisation aux rôles IAM. Notez que différents utilisateurs et groupes de l'organisation peuvent être associés à différents rôles IAM. La procédure exacte pour leur mappage dépend de l'IdP utilisé. Dans le [scénario précédent](#CreatingSAML-configuring) d'un dossier Amazon S3 pour les utilisateurs, tous les utilisateurs peuvent être associés au rôle qui fournit les autorisations Amazon S3. Pour de plus amples informations, veuillez consulter [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md). Si votre IdP active l'authentification unique sur la AWS console, vous pouvez configurer la durée maximale des sessions de console. Pour de plus amples informations, veuillez consulter [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md). 1. Dans l'application que vous créez, vous appelez l' AWS Security Token Service `AssumeRoleWithSAML`API en lui transmettant l'ARN du fournisseur SAML dans lequel vous l'avez créé[Step 3](#samlovrcreateentity), l'ARN du rôle dans lequel vous devez supposer que vous l'avez créé et l'assertion SAML concernant l'utilisateur actuel que vous obtenez de votre IdP. [Step 4](#samlovrcreaterole) AWS s'assure que la demande pour assumer le rôle provient de l'IdP référencé dans le fournisseur SAML. Pour plus d'informations, consultez la section [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) dans la *référence de l'AWS Security Token Service API*. 1. Si la demande aboutit, l'API retourne des informations d'identification de sécurité temporaires que votre application peut utiliser pour adresser des demandes signées à AWS. Votre application dispose d'informations sur l'utilisateur actuel et peut accéder aux compartiments Amazon S3 spécifiques à celui-ci, comme décrit dans le scénario précédent. ## 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 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, 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 : ------ #### [ 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://{{ap-east-1}}.signin.amazonaws.cn/saml", "saml:iss": "https://openidp.feide.no" }, "ForAllValues:StringLike": { "saml:edupersonaffiliation": [ "staff" ] } } } ] } ``` ------ **Note** Le SAML IDPs utilisé dans une politique de confiance des rôles doit se trouver dans le même compte que celui dans lequel se trouve le rôle. 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 la connexion URLs dans certaines régions. AWS recommande d'utiliser des points de terminaison régionaux plutôt que des points de terminaison mondiaux 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 points de [terminaison de AWS connexion](https://docs.aws.amazon.com/general/latest/gr/signin-service.html). L’exemple suivant montre le format d’URL de connexion avec la `region-code` facultative. `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 explicitement autoriser les actions Amazon EC2 dans la politique d'autorisation, comme celles figurant dans la politique EC2 FullAccess gérée par **Amazon**. 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 basée sur SAML AWS STS](reference_policies_iam-condition-keys.md#condition-keys-saml). ## 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 : ``` 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. Cependant, 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 la première fois que l'utilisateur se connecte dans le cadre du 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. + `AWS`. Valeur de hachage basée sur la concaténation de la valeur de réponse `Issuer` (`saml:iss`) et d'une chaîne avec l'ID de compte `saml:namequalifier` et le nom convivial (dernière partie de l'ARN) du fournisseur SAML dans IAM. La concaténation de l'ID de compte et du nom convivial du fournisseur SAML est disponible dans les politiques IAM en tant que clé `saml:doc`. L'ID de compte et le nom du fournisseur doivent être séparés par un caractère « / », comme dans « 123456789012/provider\_name ». Pour plus d'informations, reportez-vous à la clé `saml:doc` dans [Clés disponibles pour la fédération basée sur SAML AWS STS](reference_policies_iam-condition-keys.md#condition-keys-saml). La combinaison de `NameQualifier` et `Subject` permet d’identifier de manière unique un principal fédéré SAML. L’exemple de pseudo-code suivant montre comment cette valeur est calculée. Dans ce pseudo-code, `+` indique une concaténation, `SHA1` représente une fonction qui génère un résumé de message à l'aide de SHA-1 et `Base64` représente une fonction qui génère une version encodée en Base64 de la sortie de hachage. `Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )` Pour plus d'informations sur les clés de politique disponibles pour la fédération SAML, consultez [Clés disponibles pour la fédération basée sur SAML AWS STS](reference_policies_iam-condition-keys.md#condition-keys-saml). + `saml:sub` (chaîne). Objet de la demande, qui inclut une valeur qui identifie de manière unique un utilisateur individuel au sein d'une organisation (par exemple, `_cbb88bf52c2510eabe00c1642d4643f41430fe25e3`). + `saml:sub_type` (chaîne). Cette clé peut être `persistent`, `transient` ou l'URI `Format` complet des éléments `Subject` et `NameID` utilisés dans votre assertion SAML. Une va leur `persistent` indique que la valeur de `saml:sub` reste la même pour l'utilisateur pour toutes les sessions. Si la valeur est `transient`, l'utilisateur a une valeur `saml:sub` différente pour chaque session. Pour plus d'informations sur l'attribut `NameID` de l'élément `Format`, consultez [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md). 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](id_roles_providers_create_saml_assertions.md).