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.
Configuration de la fédération sur la console AMS (SALZ)
Les rôles IAM et le fournisseur d'identité SAML (entité de confiance) détaillés dans le tableau suivant ont été fournis dans le cadre de l'intégration de votre compte. Ces rôles vous permettent de soumettre et de surveiller RFCs les demandes de service et les rapports d'incidents, ainsi que d'obtenir des informations sur vous VPCs et vos stocks.
| Rôle | Fournisseur d'identité | Autorisations |
|---|---|---|
Client_ _Rôle ReadOnly |
SAML |
Pour les comptes AMS standard. Vous permet de soumettre RFCs pour apporter des modifications à l'infrastructure gérée par AMS, ainsi que de créer des demandes de service et des incidents. |
customer_managed_ad_user_role |
SAML |
Pour les comptes Active Directory gérés par AMS. Vous permet de vous connecter à la console AMS pour créer des demandes de service et des incidents (non RFCs). |
Pour la liste complète des rôles disponibles sous différents comptes, voirRôle d'utilisateur IAM dans AMS .
Un membre de l'équipe d'intégration télécharge le fichier de métadonnées de votre solution de fédération vers le fournisseur d'identité préconfiguré. Vous utilisez un fournisseur d'identité SAML lorsque vous souhaitez établir un lien de confiance entre un IdP compatible SAML (fournisseur d'identité) tel que Shibboleth ou Active Directory Federation Services, afin que les utilisateurs de votre organisation puissent accéder aux ressources AWS. Les fournisseurs d'identité SAML dans IAM sont utilisés comme principaux dans une politique de confiance IAM avec les rôles ci-dessus.
Alors que d'autres solutions de fédération fournissent des instructions d'intégration pour AWS, AMS propose des instructions distinctes. À l'aide du billet de blog suivant, Enabling Federation to AWS Using Windows Active Directory, AD FS et SAML 2.0
Après avoir créé la confiance de la partie utilisatrice conformément au billet de blog, configurez les règles de réclamation de la manière suivante :
NameId: Suivez le billet de blog.
RoleSessionName: utilisez les valeurs suivantes :
Nom de la règle de réclamation : RoleSessionName
Magasin d'attributs : Active Directory
Attribut LDAP : SAM-Account-Name
Type de réclamation sortante : https://aws.amazon.com/SAML/ Attributs/ RoleSessionName
Obtenir des groupes AD : suivez le billet de blog.
Affirmation de rôle : suivez le billet de blog, mais pour la règle personnalisée, utilisez ceci :
c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-([^d]{12})-"] => issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "AWS-([^d]{12})-", "arn:aws:iam::$1:saml-provider/customer-readonly-saml,arn:aws:iam::$1:role/"));
Lorsque vous utilisez AD FS, vous devez créer des groupes de sécurité Active Directory pour chaque rôle au format indiqué dans le tableau suivant (customer_managed_ad_user_role est réservé aux comptes AD gérés par AMS uniquement) :
| Groupe | Rôle |
|---|---|
AWS- [AccountNo] ReadOnly -Customer_ _Role |
Client_ _Rôle ReadOnly |
AWS- [AccountNo] -customer_managed_ad_user_role |
customer_managed_ad_user_role |
Pour plus d'informations, voir Configuration des assertions SAML pour la réponse d'authentification.
Astuce
Pour vous aider à résoudre les problèmes, téléchargez le plug-in de traçage SAML pour votre navigateur.
