Passer au contenu principal
Cette fonctionnalité utilise la délégation. Par défaut, la délégation est désactivée pour les locataires sans module complémentaire en cours d’utilisation depuis le 8 juin 2017. Les anciens locataires qui utilisent actuellement un module complémentaire nécessitant une délégation peuvent continuer à utiliser cette fonction. Si la fonctionnalité de délégation est modifiée ou supprimée à un moment donné, les clients qui l’utilisent seront informés à l’avance et disposeront d’un délai suffisant pour migrer. Par ailleurs, notez que la délégation ne prend pas en charge l’utilisation de domaines personnalisés, si bien que toutes les fonctionnalités qui en dépendent risquent de ne pas être pleinement fonctionnelles avec un domaine personnalisé.

​
Étape 2 - Sécuriser et déployer la Passerelle API Amazon

Maintenant que votre API fonctionne, vous devez ajouter un niveau de sécurité. Au cours de cette étape, vous allez :
  • Sécurisez l’API de mise à jour pour limiter l’accès aux utilisateurs authentifiés ayant un rôle IAM AWS spécifique;
  • Configurez la délégation Auth0 pour utiliser les fonctionnalités de la fédération IAM AWS;
  • Obtenez un jeton d’accès AWS qui utilise le rôle IAM AWS.
Une fois que votre API est sécurisée, vous créerez une application à page unique (SPA) sans serveur. La SPA s’appuiera sur les identités fédérées pour déterminer quels utilisateurs disposent d’une autorisation d’accès. En combinant l’intégration IAM AWS pour la Passerelle API AWS, la fédération d’identité IAM AWS pour et la délégation Auth0 pour AWS, vous pouvez donner accès à vos API à des utilisateurs provenant de nombreuses sources différentes, y compris des fournisseurs sociaux ou des connexions d’entreprise. Le diagramme suivant présente un exemple de flux qui utilise un fournisseur d’identité basé sur SAML, ainsi que la fédération et délégation Auth0 SAML pour AWS. Il existe deux façons de mettre en œuvre ce flux :
  1. En utilisant la délégation Auth0 avec IAM AWS;
  2. En ajoutant un jeton d’ID pour acheminer l’identité vers la fonction Lambda.
La délégation facilite l’obtention des jetons à partir de AWS pour accéder à tous les services d’AWS dans votre application.

​
Procédures de sécurisation de la Passerelle API Amazon

La Passerelle API AWS offre différentes méthodes pour sécuriser vos API :
  1. Les clés API;
  2. IAM;
  3. Amazon Cognito.
L’utilisation de clés API est généralement appropriée pour une interaction entre services, comme illustré ci-dessous. Cependant, cette approche présente plusieurs inconvénients :
  • L’attribution d’un secret de longue durée sur l’application est risquée (cette dernière est plus facile à compromettre);
  • La création d’un cadre d’applications pour émettre et gérer des clés API nécessite une mise en œuvre sécurisée parfois complexe.
Dans cette section du tutoriel, nous utiliserons les rôles et les politiques IAM pour sécuriser votre API dans Passerelle API, mais vous pouvez également avoir recours aux groupes d’utilisateurs dans Amazon Cognito. Pour obtenir des instructions détaillées sur la sécurisation de votre API AWS, lisez la section Secure AWS API Gateway Using Cognito (Sécuriser la Passerelle API AWS à l’aide de Cognito). Pour en savoir plus sur l’utilisation des rôles et des règles IAM, lisez l’article d’Amazon intitulé Control access to an API with IAM permissions (Contrôle de l’accès à une API avec des autorisations IAM). Pour de plus amples informations sur les groupes d’utilisateurs dans Cognito, visitez la page Amazon Cognito user pool (Groupes d’utilisateurs Amazon Cognito).

​
1. Configuration d’IAM et d’Auth0 pour intégrer SAML avec la Passerelle API

Vous pouvez spécifier le rôle IAM AWS pour le jeton SAML que vous échangez contre un jeton AWS. Le jeton reçu bénéficie des mêmes autorisations que celles attribuées au rôle IAM en question (qui sont définies par votre fournisseur d’identité). En émettant différents jetons SAML, chacun avec son propre rôle IAM AWS, vous pouvez contrôler les niveaux d’accès de vos utilisateurs. Par exemple, le fournisseur d’identité peut indiquer le rôle IAM en fonction de l’appartenance à un groupe (p.ex. : un administrateur dans Active Directory) ou de la source d’authentification (p.ex. : une connexion à une base de données ou un fournisseur social comme Facebook). Cette approche vous permet de différencier les autorisations d’accès des utilisateurs à vos méthodes de Passerelle API Amazon lorsque ces dernières sont sécurisées à l’aide d’IAM AWS.

​
Configuration d’Auth0

Connectez-vous à votre compte Auth0. Vous accéderez au Management Dashboard. Cliquez sur le bouton + Nouvelle application, situé dans le coin supérieur droit de la page. Nommez votre nouvelle application Passerelle API AWS, et indiquez qu’il s’agira d’une application à page unique. Cliquez sur Créer. Accédez à l’onglet modules complémentaires de l’application que vous venez de créer. Cliquez sur la diapositive appropriée pour activer Amazon Web Services. Cela active la délégation AWS.

​
Configurer AWS

Suivez le tutoriel intitulé Comment configurer AWS pour l’authentification déléguée afin de configurer l’accès délégué à AWS par le biais du protocole SAML. Quelques mises en garde :
  • Suivez les instructions ci-dessous pour associer la politique de permissions à votre rôle et non à celui indiqué dans le tutoriel ;
  • Nommez le fournisseur SAML que vous avez créé comme suit : auth0;
  • Nommez le rôle IAM AWS comme suit : auth0-api-role.
Définissez la politique d’autorisation en fonction de votre rôle IAM AWS.
Une fois que vous avez configuré le rôle IAM AWS, vous ajouterez une politique à auth0-api-role qui vous permettra d’exécuter vos méthodes Passerelle API. Pour plus d’informations sur cette procédure, veuillez consulter User Access Permissions for Amazon API Gateway (Autorisations d’accès des utilisateurs à la Passerelle API Amazon).

​
Récupération de l’ARN de la Passerelle API.

Avant de commencer, vous aurez besoin de l’ARN de votre Passerelle API :
  1. Accédez à la Console de Passerelle API Amazon et connectez-vous.
  2. Sélectionnez l’API appropriée.
  3. Cliquez sur n’importe quelle méthode associée à l’API pour afficher la page exécution de la méthode.
  4. Sur cette dernière, l’ARN de l’API se trouve dans le champ requête de méthode, bien qu’il inclut le nom de méthode suivant :
arn:aws:execute-api:us-east-2:484857107747:97i1dwv0j4/*/POST/ Vous devez supprimer le nom de la méthode pour obtenir l’ARN de base de l’API : arn:aws:execute-api:us-east-2:484857107747:97i1dwv0j4/* Le caractère de remplacement (*) dans l’ARN ci-dessus permet d’autoriser l’accès à votre API à toutes les étapes, mais vous pouvez déployer les différentes étapes individuellement (par exemple, la phase de développement d’abord, puis de test, et de production). Sélectionnez le rôle auth0-api-role que vous venez de créer pour ouvrir la page Résumé qui lui est associée. Agrandissez la section Politiques en ligne et cliquez sur cliquer ici. Sélectionnez Politique personnalisée et cliquez sur Sélectionner. Modifiez le document de politique. Vous pouvez définir le Nom de la politique à ce que vous voulez, mais nous suggérons quelque chose comme api-gateway-policy. Pour autoriser l’accès aux méthodes de l’API pour le rôle en question, appliquez cette politique après avoir mis à jour l’ARN avec celui de votre API. 
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "execute-api:*"
            ],
            "Resource": [
                "arn:[{yourArn}]"
            ]
        }
    ]
}
Cliquez sur Appliquer la politique. Étant donné que la Passerelle de l’API assumera ce rôle au nom de l’utilisateur, la politique de confiance doit autoriser cette action. Pour ce faire, modifiez les Relations de confiance du rôle en accédant à l’onglet correspondant sur la page Résumé. La relation de confiance finale devrait ressembler à celle illustrée ci-dessous : 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "auth0",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::012345670:saml-provider/auth0-api"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:iss": "urn:{yourDomain}"
        }
      }
    },
    {
      "Sid": "gateway",
      "Effect": "Allow",
      "Principal": {
        "Service": "apigateway.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
À ce stade, vous devez définir les paramètres d’autorisation sur API Gateway (Passerelle API). Dans la fenêtre Ressources, sélectionnez la méthode POST sous /pets. Cliquez sur le lien Requête de méthode. Cliquez sur l’icône de modification à côté du Authorization Type (Type d’autorisation), et sélectionnez AWS_IAM. Cliquez maintenant sur le bouton Check (Vérifier) à côté du champ pour enregistrer ce paramètre.

​
2. Configuration du partage des ressources inter-origines (CORS) et déploiement de l’API

Notre application à page unique (SPA) accédera aux méthodes de l’API web à partir d’un domaine différent de celui de la page. La configuration du partage des ressources inter-origines doit explicitement autoriser cette action pour que le navigateur permette l’accès à la Passerelle API AWS. En règle générale, le navigateur envoie d’abord une requête OPTIONS pour voir quelles sont les actions autorisées par le site. Sélectionnez /pets sous Ressources et cliquez sur Créer la méthode. Dans le menu déroulant, sélectionnez OPTIONS et cliquez sur la coche pour enregistrer la configuration. Le navigateur utilise la méthode Options pour obtenir les en-têtes HTTP requis, mais la fonction a besoin d’instructions supplémentaires pour s’exécuter correctement. Sous l’écran de configuration OPTIONS, définissez les variables et paramètres suivants :
  • Type d’intégration : Fonction Lambda;
  • Utiliser l’intégration Proxy Lambda : ne pas cocher;
  • Région Lambda : sélectionnez votre région;
  • Fonction Lambda : NoOp.
Cliquez sur Enregistrer. Dans la fenêtre suivante, accordez à votre fonction Lambda les autorisations dont elle a besoin. Vous serez alors automatiquement dirigé vers la page OPTIONS Méthode d’exécution. Ouvrez la page Réponse de méthode. Élargissez la section 200 située sous la barre d’état HTTP et ajoutez les en-têtes de réponse suivants :
  • Access-Control-Allow-Headers;
  • Access-Control-Allow-Methods;
  • Access-Control-Allow-Origin.
Ensuite, associez les valeurs appropriées à chacun des en-têtes de réponse. Une fois de retour à la page Exécution de méthode, cliquez sur Integration Response (Réponse d’intégration). Après avoir développé la ligne associée à l’état de réponse de la méthode 200, agrandissez les Mappages d’en-tête et appliquez les mappages suivants :
  • Access-Control-Allow-Headers : 'Content-Type,X-Amz-Date,Authorization,x-api-key,x-amz-security-token';
  • Access-Control-Allow-Origin : '*'
  • Access-Control-Allow-Methods : 'POST, GET, OPTIONS'
Enfin, répétez les étapes ci-dessus pour activer le partage des ressources inter-origines pour les méthodes POST et GET. Toutefois, pour ces deux méthodes, vous ajouterez l’en-tête Access-Control-Allow-Origin, dont la valeur doit être fixée à '*'.

​
Déployer l’API

Retournez sur la page Ressources de votre API. Cliquez sur Actions, et sélectionnez DÉPLOYER L’API. Sélectionnez New Stage (Nouvelle étape) pour l’état de déploiement et nommez l’étape Test. Cliquez sur le bouton Deploy (Déployer). Sur la page des résultats, allez à la section Génération d’une trousse SDK. Sélectionnez JavaScript en tant que Plateforme. Cliquez sur le bouton Générer trousse SDK. Enregistrez le fichier zip téléchargé pour une utilisation ultérieure.
⌘I