View a markdown version of this page

Configuration unique d'une application de fédération IAM directe dans Okta - AWS IAM Identity Center

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 unique d'une application de fédération IAM directe dans Okta

  1. Connectez-vous à votre Okta compte en tant qu'utilisateur disposant d'autorisations administratives.

  2. Dans la Okta console d'administration, sous Applications, sélectionnez Applications.

  3. Choisissez Parcourir le catalogue d'applications. Recherchez et choisissez AWS Account Federation. Choisissez ensuite Ajouter une intégration.

  4. Configurez la fédération IAM directe avec AWS en suivant les étapes décrites dans Comment configurer SAML 2.0 pour la fédération de AWS comptes. Pour gérer les scénarios de défaillance régionaux, lorsque vous configurez le point de terminaison de connexion, nous vous recommandons d'activer à la fois le point de terminaison non régional et plusieurs points de terminaison régionaux pour toutes les régions dans lesquelles vous opérez afin d'améliorer la résilience de la fédération. Lorsque vous configurez l'URL ACS pour cet accès d'urgence, nous vous recommandons d'utiliser le point de terminaison régional d'une région différente de celle dans laquelle votre centre d'identité IAM est déployé. Reportez-vous à la section Points de terminaison de connexion dans le manuel de référence AWS général pour obtenir la liste des points de terminaison régionaux.

  5. Dans l'onglet Options de connexion, sélectionnez SAML 2.0 et entrez les paramètres du filtre de groupe et du modèle de valeur des rôles. Le nom du groupe pour l'annuaire des utilisateurs dépend du filtre que vous configurez.

    Deux options : accountid et role dans le filtre de groupe ou le modèle de valeur du rôle.

    Dans la figure ci-dessus, la role variable concerne le rôle des opérations d'urgence dans votre compte d'accès d'urgence. Par exemple, si vous créez le EmergencyAccess_Role1_RO rôle (comme décrit dans le tableau de mappage) dans Compte AWS 123456789012, et si votre paramètre de filtre de groupe est configuré comme indiqué dans la figure ci-dessus, le nom de votre groupe doit êtreaws#EmergencyAccess_Role1_RO#123456789012.

  6. Dans votre répertoire (par exemple, votre répertoire dans Active Directory), créez le groupe d'accès d'urgence et attribuez un nom au répertoire (par exemple,aws#EmergencyAccess_Role1_RO#123456789012). Affectez vos utilisateurs à ce groupe en utilisant votre mécanisme de provisionnement existant.

  7. Dans le compte d'accès d'urgence, configurez une politique de confiance personnalisée qui fournit les autorisations requises pour que le rôle d'accès d'urgence soit assumé lors d'une interruption. Vous trouverez ci-dessous un exemple de déclaration pour une politique de confiance personnalisée attachée au EmergencyAccess_Role1_RO rôle. Pour une illustration, voir le compte d'urgence dans le schéma ci-dessousComment concevoir un mappage des rôles, des comptes et des groupes en cas d'urgence. Remplacez l'exemple d'ARN du fournisseur SAML par le bon ARN que vous avez créé dans le compte d'accès d'urgence. Remplacez les points de terminaison régionaux dans l'exemple par les régions de votre choix.

    JSON
    {
    "Version":"2012-10-17",
    "Statement": [
      {
         "Effect":"Allow",
         "Principal":{
            "Federated":"arn:aws:iam::123456789012:saml-provider/[SAML PROVIDER NAME]"
         },
         "Action":[
            "sts:AssumeRoleWithSAML",
            "sts:TagSession"
         ],
         "Condition":{
            "StringEquals":{
               "SAML:aud": [
                        "https://signin.aws.amazon.com/saml",
                        "https://us-west-2.signin.aws.amazon.com/saml",
                        "https://us-west-1.signin.aws.amazon.com/saml",
                        "https://us-east-2.signin.aws.amazon.com/saml"
               ]
            }
         }
      },
      {
         "Effect":"Allow",
         "Principal":{
         "Federated":"arn:aws:iam::123456789012:saml-provider/Okta"
         },
         "Action":"sts:SetSourceIdentity"
       }
   ]
}

  8. Voici un exemple de déclaration pour une politique d'autorisation attachée au EmergencyAccess_Role1_RO rôle. Pour une illustration, voir le compte d'urgence dans le schéma ci-dessousComment concevoir un mappage des rôles, des comptes et des groupes en cas d'urgence.

    JSON
    {
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::111122223333:role/EmergencyAccess_RO",
                "arn:aws:iam::444455556666:role/EmergencyAccess_RO"
            ]
        }
    ]
}

  9. Sur les comptes de charge de travail, configurez une politique de confiance personnalisée. Vous trouverez ci-dessous un exemple de déclaration pour une politique de confiance attachée au EmergencyAccess_RO rôle. Dans cet exemple, le compte 123456789012 est le compte d'accès d'urgence. Pour une illustration, voir le compte de charge de travail dans le schéma ci-dessousComment concevoir un mappage des rôles, des comptes et des groupes en cas d'urgence.

    JSON
    {
    "Version":"2012-10-17",
    "Statement":[
      {
         "Effect":"Allow",
         "Principal":{
            "AWS":"arn:aws:iam::123456789012:root"
         },
         "Action":"sts:AssumeRole"
      }
   ]
}
    Note

    La plupart vous IdPs permettent de désactiver l'intégration d'une application jusqu'à ce que vous en ayez besoin. Nous vous recommandons de laisser l'application de fédération IAM directe désactivée dans votre IdP jusqu'à ce qu'elle soit requise pour un accès d'urgence.