Jeton daccès à la passerelle aws api

par Kevin Hakanson, Edward Sun et Sowjanya Rajavaramon dans Amazon API Gateway, Amazon Cognito, Amazon Verified Permissions, Intermédiaire (200), Sécurité, identité et conformité, Guide techniquePermalink Commentaires partager

le 9 août 2024 : Cet article a été mis à jour pour refléter une nouvelle fonctionnalité d’Amazon Verified Permissions qui prend en charge les fournisseurs d’identité conformes à OpenID Connect (OIDC) en tant que source d’identité

---

L’externalisation de la logique d’autorisation pour les API d’application peut offrir de multiples avantages aux clients Amazon Web Services (AWS). Ces avantages peuvent inclure la libération des équipes de développement pour qu’elles se concentrent sur la logique d’application, la simplification des audits d’accès aux applications et aux ressources et l’amélioration de la sécurité des applications en utilisant autorisation continue. Amazon Verified Permissions est un service évolutif de gestion des autorisations et d’autorisation affinée que vous pouvez utiliser pour externaliser l’autorisation d’application. En plus de contrôler l’accès aux ressources de l’application, vous pouvez utiliser les autorisations vérifiées pour restreindre l’accès à l’API aux utilisateurs autorisés à l’aide des politiques Cedar. Cependant, l’un des principaux défis de l’adoption d’un système d’autorisation externe tel que les autorisations vérifiées est l’effort nécessaire pour définir la logique de politique et l’intégration à votre API. Cet article de blog montre comment les autorisations vérifiées accélèrent le processus de sécurisation des API REST hébergées sur Amazon API Gateway pour les clients utilisant Amazon Cognito ou un fournisseur d’identité (IdP) compatible OpenID Connect (OIDC).

Configuration de l’autorisation d’API à l’aide d’Amazon Verified Permissions

En tant que développeur, vous devez effectuer plusieurs tâches afin d’utiliser les autorisations vérifiées pour stocker et évaluer les politiques qui définissent les API auxquelles un utilisateur est autorisé à accéder. Bien que les autorisations vérifiées vous permettent de découpler la logique d’autorisation du code de votre application, vous devrez peut-être passer du temps à apprendre le langage de politique Cedar, à définir un schéma de politique, à créer des stratégies et à intégrer les autorisations vérifiées dans vos applications. Enfin, vous devrez peut-être consacrer plus de temps au développement et au test de la logique de la fonction d’autorisation AWS Lambda qui génère la demande d’autorisation pour les autorisations vérifiées et applique la décision d’autorisation. Cela peut être une tâche ardue pour un développeur qui découvre le service.

Mise en route de l’assistant simplifié

Amazon

Verified Permissions inclut désormais un assistant basé sur une console que vous pouvez utiliser pour créer rapidement des blocs de construction afin de configurer la passerelle API de votre application pour utiliser les autorisations vérifiées pour l’autorisation. Autorisations vérifiées génère un modèle d’autorisation basé sur vos API et vos politiques qui autorise uniquement les groupes d’utilisateurs autorisés à accéder à vos API. En outre, il déploie un mécanisme d’autorisation Lambda, que vous attachez aux API que vous souhaitez sécuriser. Une fois l’autorisateur attaché, les demandes d’API sont autorisées par les autorisations vérifiées. Les politiques et le schéma Cedar générés aplatissent la courbe d’apprentissage, tout en vous permettant un contrôle total pour modifier et vous aider à respecter vos exigences de sécurité.

Vue d’ensemble de l’exemple d’application

Dans ce billet de blog, nous montrons comment vous pouvez simplifier la sécurisation des autorisations d’accès à un exemple d’API d’application à l’aide de l’Assistant basé sur la console Autorisations vérifiées. Nous utilisons un exemple d’application d’animalerie qui comporte deux ressources :

1. PetStore  – Une API REST Amazon API Gateway dérivée de l’importation de l’exemple d’API PetStore et de son extension à l’aide d’une simulation intégration pour l’administration. Cette intégration fictive renvoie un message avec un chemin d’URI qui utilise  comme demande d’intégration et  comme réponse d’intégration.
2. Annuaire  d’utilisateurs : source d’identité qui peut être utilisée pour définir les utilisateurs et leurs propriétés lorsque ceux-ci demandent l’accès aux ressources de l’application. Nous utiliserons un groupe d’utilisateurs Amazon Cognito appelé avec des utilisateurs dans l’un des trois groupes suivants : clients, employés et propriétaires. Alternativement, vous pouvez apporter votre propre IdP conforme à l’OIDC avec les trois groupes d’utilisateurs ci-dessus.

Le PetStore a les quatre exigences d’autorisation suivantes qui permettent l’accès aux ressources associées. Tous les autres comportements doivent être niés.

1. Les  utilisateurs authentifiés  et  non authentifiés  sont autorisés à accéder à l’URL racine.
2. Tous les  utilisateurs authentifiés  sont autorisés à obtenir la liste des animaux de compagnie, ou à obtenir un animal de compagnie par son identifiant.
   • GET /pets
   • GET /pets/{petid}
3. Le  groupe des employés  et  des propriétaires  est autorisé à ajouter de nouveaux animaux de compagnie.
4. Seul le groupe propriétaires    est autorisé à effectuer des fonctions d’administration. Celles-ci sont définies à l’aide d’une ressource proxy API Gateway qui permet à une seule intégration d’implémenter un ensemble de ressources API.

Procédure pas à pas

: les autorisations vérifiées incluent un assistant de configuration qui connecte un groupe d’utilisateurs Amazon Cognito ou un fournisseur d’identité OIDC à une API REST d’API Gateway API et sécurise les ressources en fonction des appartenances aux groupes. Dans cette section, nous allons fournir une procédure pas à pas de l’assistant qui génère la génération de l’autorisation pour notre exemple d’application.

Pour configurer l’autorisation d’API en fonction des groupes

1. d’utilisateurs Sur la page Autorisations vérifiées d’Amazon dans AWS Management Console, choisissez  Créer un nouveau magasin de politiques .
2. Dans la page Spécifier les détails du magasin de stratégies, sous Options de démarrage , sélectionnez Configurer avec API Gateway et un fournisseur d’identité , puis choisissez  Suivant .

   Figure 1 : options de démarrage

Importer des ressources et des actions

1. d’API Sur la page Importer des ressources et des actions, sous Détails d’API Gateway , sélectionnez l’étape d’API et de déploiement dans les listes déroulantes. (Une étape d’API REST est une référence nommée à un déploiement.) Pour cet exemple, nous avons sélectionné l’API  PetStore  et l’étape de  démonstration  .

   Figure 2 : API Gateway et étape de déploiement

2. Choisissez  Importer l’API pour générer une carte des ressources et actions importées . Pour notre exemple, cette liste comprend  pour obtenir la liste des animaux de compagnie,  pour obtenir un seul animal de compagnie et  pour ajouter un nouvel animal de compagnie. Choisissez Suivant .

   Figure 3 : Carte des ressources et actions importées

Choisir la source d’identité

Dans cette étape, vous allez configurer la source d’identité utilisée par votre application pour authentifier et gérer les utilisateurs. Vous pouvez vous connecter à votre groupe d’utilisateurs Amazon Cognito existant ou ajouter un fournisseur d’identité OIDC externe. Lors de l’utilisation d’un groupe d’utilisateurs Cognito existant, vérifié Permissions récupère automatiquement la configuration de votre pool d’utilisateurs et vous permet d’attribuer des autorisations en fonction de groupes Cognito. Lorsque vous utilisez un fournisseur d’identité OIDC externe, vous devez fournir l’URL de l’émetteur OIDC et spécifier manuellement les configurations de groupe. L’URL de l’émetteur OIDC est utilisée par l’autorisation vérifiée pour vérifier la signature et l’expiration du jeton.

Option 1 : Utiliser un groupe d’utilisateurs Amazon Cognito existant

1. Sur la page Choisir la source d’identité , sous la section Configurer le fournisseur, sélectionnez Amazon Cognito .

   Figure 4 : choix d’un groupe d’utilisateurs Cognito comme fournisseur d’identité

2. Dans la section Source de l’identité, sélectionnez un groupe d’utilisateurs Cognito (PetStorePool  dans notre exemple). Pour Type de jeton à transmettre à l’API , sélectionnez un type de jeton. Pour notre Par exemple, nous avons choisi la valeur par défaut, Jeton d’accès , car Cognito recommande d’utiliser le jeton d’accès pour autoriser les opérations d’API. Les revendications supplémentaires disponibles dans un jeton d’id peuvent prendre en charge un contrôle d’accès plus précis. Pour la validation de l’application cliente , nous avons également spécifié la valeur par défaut pour ne pas valider que les jetons correspondent à un ID client d’application d’application configuré. Envisagez la validation lorsque vous avez plusieurs clients d’application de pool d’utilisateurs configurés avec des autorisations différentes.

   Figure 5 : sélection du groupe d’utilisateurs Cognito PetStorePool comme source d’identité

3. Choisissez Suivant .
4. Sur la page Attribuer des actions à des groupes, sous Sélection de groupe , choisissez les groupes de groupes d’utilisateurs Cognito qui peuvent effectuer des actions dans l’application. Cette solution utilise le groupe Cognito natif pour contrôler les autorisations. Dans la figure 6, étant donné que le groupe customers n’est pas utilisé pour le contrôle d’accès, nous l’avons désélectionné et il n’est pas inclus dans les stratégies générées. Au lieu de cela, l’accès à  get /pets  et  get/pets/{petId}  est accordé à tous les utilisateurs authentifiés à l’aide d’un mécanisme d’autorisation différent que nous définissons plus loin dans cet article.

   Figure 6 : Attribuer des actions à des groupes

5. Pour chacun des groupes, choisissez les actions autorisées. Dans notre exemple,  post /pets  est la seule action sélectionnée pour le groupe employés. Pour le groupe propriétaires, toutes les actions /admin/{proxy+} sont également sélectionnées. Choisissez Suivant .

   Figure 7 : Cognito regroupe les employés et les propriétaires

Option 2 : Utiliser un fournisseur d’identité OIDC externe

1. Sur la page Choisir la source d’identité , sélectionnez Fournisseur OIDC externe .

   Figure 8 : Choisir un fournisseur OIDC externe comme source d’identité

2. Pour obtenir les détails du fournisseur OIDC , entrez l’URL de l’émetteur . Veuillez noter que l’URL de votre émetteur doit héberger un document de découverte OIDC à l’adresse . Pour notre exemple, nous avons utilisé une instance de conteneur Keycloak open source. Vous pouvez consulter et télécharger le document de découverte Keycloak IdP OIDC pour trouver l’URL de l’émetteur. Dans notre exemple, l’URL de l’émetteur est .

   Figure 9 : Saisie des détails du fournisseur OIDC externe

3. Pour Type de jeton , choisissez le type de JWT que votre application doit soumettre pour autorisation. Nous vous suggérons d’utiliser le jeton d’accès en tant que revendications de jeton seront mappées au contexte, comme dans la demande d’autorisation pour prendre en charge les modèles de contrôle d’accès en fonction du rôle (RBAC). Vous pouvez choisir d’utiliser le jeton d’ID si votre application autorise l’utilisateur en fonction de ses attributs d’identité. Pour en savoir plus sur l’utilisation des sources d’identité et le mappage des attributs de jeton dans le schéma et les stratégies.
4. Pour Revendications de jeton d’utilisateur et de groupe , saisissez la revendication représentée par votre fournisseur d’identité. L’Assistant Autorisations vérifiées crée des stratégies basées sur ce mappage de revendications, et votre magasin de stratégies autorise les demandes basées sur cette revendication dans les jetons. Si vous n’êtes pas sûr de la façon dont votre fournisseur d’identité externe représente les revendications d’utilisateur et de groupe dans le jeton, décodez un JWT et examinez la charge utile. Dans notre exemple, la revendication de l’utilisateur est mappée à sub et la revendication de groupe est mappée à .

   Figure 10 : Saisir les détails des revendications de jeton du fournisseur OIDC externe

5. Choisissez Suivant .
6. Sur la page Attribuer des actions à des groupes, entrez le nom du groupe et sélectionnez l’action autorisée. Dans notre exemple, nous avons créé le groupe des employés et autorisé l’action post /pets.
7. Choisissez Ajouter d’autres groupes pour créer un autre groupe pour les propriétaires et autoriser en plus toutes les actions /admin/{proxy+}. Choisissez Suivant .

   Figure 11 : Groupes d’IDP OIDC, employés et propriétaires

Déployer l’intégration

1. de l’application Sur la page Déployer l’intégration de l’application, passez en revue les détails de l’intégration d’API Gateway, puis choisissez Maintenant sous Commencer à autoriser l’API dans la section. Choisissez  Créer une stratégie magasin .

   Figure 12 : Activer l’intégration d’API Gateway

2. Sur la page de résumé de la création d’un magasin de stratégies, vérifiez la progression de l’installation. Choisissez Vérifier le déploiement pour vérifier la progression de l’autoriseur Lambda.

   Figure 13 : Création d’un magasin de stratégies

L’assistant d’installation déploie une pile CloudFormation avec un mécanisme d’autorisation Lambda. Cela autorise l’accès aux ressources API Gateway pour les groupes d’employés et de propriétaires.

Pour le deuxième cas d’utilisation où les ressources doivent être autorisées pour tous les utilisateurs authentifiés, un mécanisme d’autorisation de pool d’utilisateurs Cognito distinct est requis pour effectuer l’autorisation. Vous pouvez utiliser la commande apigateway create-authorizer de l’AWS CLI suivante pour créer le mécanisme d’autorisation.

Si vous utilisez votre propre fournisseur d’identité OIDC, vous pouvez modifier votre politique pour accorder l’accès à tous les groupes d’utilisateurs et ignorez les étapes précédentes pour configurer un mécanisme d’autorisation Cognito.

Une fois le déploiement de la pile CloudFormation terminé et le deuxième mécanisme d’autorisation Cognito créé, deux mécanismes d’autorisation peuvent être attachés aux ressources d’API PetStore, comme illustré à la figure 14.

Dans la figure 14, Cognito-PetStorePool est un mécanisme d’autorisation de groupe d’utilisateurs Cognito. Étant donné que cet exemple utilise un jeton d’accès, une étendue d’autorisation (par exemple, une étendue personnalisée telle que ) est spécifiée lorsqu’elle est attachée aux  ressources et  .

AVPAuthorizer-XXX est un mécanisme d’autorisation  Lambda basé sur  des paramètres de demande , qui détermine l’identité de l’appelant à partir des sources d’identité configurées. Dans la figure 14, ces sources sont Autorisation (en-tête) , httpMethod (Context) et path (Context) . Ce mécanisme d’autorisation  est attaché aux ressources et  .

Cette combinaison de plusieurs mécanismes d’autorisation et de mise en cache réduit le nombre de demandes d’autorisation vers les autorisations vérifiées. Pour les appels d’API qui sont disponibles pour tous les utilisateurs authentifiés, l’utilisation du mécanisme d’autorisation Cognito-PetStorePool au lieu d’une stratégie autorisant le groupe de clients permet d’éviter les demandes d’autorisation facturables aux autorisations vérifiées.

La mise en cache d’autorisation est initialement définie à 120 secondes et peut être configurée à l’aide de la console API Gateway. Les applications où les utilisateurs lancent la même action plusieurs fois ou ont une séquence d’actions prévisible connaîtront des taux d’accès au cache élevés. Pour les appels d’API répétés qui utilisent le même jeton, la mise en cache AVPAuthorizer-XXX entraîne une latence plus faible, Moins de requêtes par seconde et moins de coûts liés aux requêtes facturables. Veuillez noter que l’utilisation de la mise en cache peut retarder le délai entre les mises à jour de la stratégie et l’application de la politique, ce qui signifie que les mises à jour de la stratégie vers les autorisations vérifiées ne sont pas réalisées tant que le délai d’expiration ou l’API FlushStageAuthorizersCache n’est pas appelé.

La

figure 15 illustre l’architecture d’exécution une fois que vous avez utilisé l’Assistant d’installation des autorisations vérifiées pour effectuer les étapes de déploiement et de configuration. Une fois que les utilisateurs sont authentifiés avec Cognito PetStorePool ou l’IdP OIDC externe, les appels d’API à l’API PetStore sont autorisés avec le jeton d’accès. L’autorisation affinée est effectuée par les autorisations vérifiées à l’aide d’un mécanisme d’autorisation Lambda. L’Assistant crée automatiquement pour vous les quatre éléments suivants, qui sont étiquetés à la figure 15 :

1. Un magasin de stratégies d’autorisations vérifiées connecté à une source d’identité (pool d’utilisateurs Cognito ou IdP OIDC externe).
2. Un schéma Cedar qui définit les entités User et UserGroup, ainsi qu’une action pour chaque ressource API Gateway.
3. Stratégies Cedar qui attribuent des autorisations pour les groupes d’employés et de propriétaires aux actions associées.
4. Un mécanisme d’autorisation Lambda configuré sur API Gateway.

   Figure 15 : Schéma d’architecture après déploiement

Les autorisations vérifiées utilisent le langage de politique Cedar pour définir des autorisations précises. La décision par défaut pour une réponse d’autorisation est . Les stratégies Cedar générées par l’assistant d’installation peuvent déterminer une décision. Le principal de chaque stratégie est une entité UserGroup avec un format d’ID d’entité lors de l’utilisation de  Cognito comme source d’identité, ou un format d’ID d’entité lors de l’utilisation d’un IdP OIDC. ID d’action pour chaque stratégie représentent l’ensemble des méthodes HTTP et des chemins d’accès aux ressources API Gateway sélectionnés. Notez que c’est  permis pour les employés et les propriétaires. La ressource dans l’étendue de la stratégie n’est pas spécifiée, car elle est implicitement l’application.

Validation de la sécurité de l’API

Vous pouvez valider vos stratégies et l’accès à l’API pour les utilisateurs autorisés et non autorisés à l’aide de différents jetons d’accès avec des commandes cURL basées sur un terminal. Pour des raisons de lisibilité, un ensemble de variables d’environnement est utilisé pour représenter les valeurs réelles. , et contiennent des jetons d’accès valides pour les utilisateurs respectifs des groupes clients, employés et propriétaires. est l’URL de base de l’API PetStore et de l’étape de démonstration que nous avons sélectionnée précédemment.

Pour tester qu’un utilisateur non authentifié est autorisé à utiliser le chemin d’accès  racine (Exigence 1 comme décrit dans la section Vue d’ensemble de cet article), mais qu’il n’est pas autorisé à appeler l’API   (Exigence 2), exécutez les commandes curl suivantes. Le mécanisme d’autorisation Cognito-PetStorePool doit renvoyer .

Pour vérifier qu’un utilisateur authentifié est autorisé à appeler l’API  (Exigence 2) à l’aide d’un jeton d’accès (en raison du mécanisme d’autorisation Cognito-PetStorePool), exécutez les commandes cURL suivantes. L’utilisateur doit recevoir un message d’erreur lorsqu’il tente d’appeler l’API  (Exigence 3), en raison de l’AVPAuthorizer. Il n’y a pas de politiques Cedar définies pour le groupe de clients avec l’action.

Les commandes suivantes permettent de vérifier qu’un utilisateur du groupe employés est autorisé à effectuer l’action de publication (Exigence 3).

Les commandes suivantes permettent de vérifier qu’un utilisateur du groupe employees n’est pas autorisé à utiliser les API d’administration, mais qu’un utilisateur du groupe owners est autorisé (Exigence 4).

Essayez-le vous-même

: comment cela pourrait-il fonctionner avec votre groupe d’utilisateurs et l’API REST ? Avant d’essayer la solution, assurez-vous que les conditions préalables suivantes sont en place, qui sont requises par l’assistant d’installation des autorisations vérifiées :

1. Un pool d’utilisateurs Cognito ou apportez votre propre fournisseur d’identité conforme à OIDC, ainsi que des groupes d’utilisateurs qui contrôlent l’autorisation aux points de terminaison d’API.
2. Une API REST API API Gateway dans la région AWS où vous souhaitez créer le magasin de politiques d’autorisation vérifiée, ainsi que dans la même région que le pool d’utilisateurs Cognito.

Lorsque vous passez en revue les ressources générées par la solution, tenez compte des rubriques suivantes :

• Les jetons d’accès ou les jetons d’ID sont-ils préférables pour votre API ? Y a-t-il des réclamations personnalisées sur vos jetons que vous utiliseriez dans les futures polices de Cedar pour une autorisation à grain fin ?
• Plusieurs mécanismes d’autorisation correspondent-ils à votre modèle ou disposez-vous d’un groupe « tous les utilisateurs » à utiliser dans les politiques Cedar ?
• Comment pourriez-vous étendre le schéma Cedar, permettant de nouvelles politiques Cedar qui incluent des paramètres de chemin d’URL, tels que l’exemple ?

Conclusion

Cet article a montré comment l’assistant de configuration d’Amazon Verified Permissions vous fournit un processus étape par étape pour créer une logique d’autorisation pour les API REST d’API Gateway à l’aide d’un pool d’utilisateurs Cognito ou de votre fournisseur d’identité OIDC. L’Assistant génère un magasin de stratégies, un schéma et des stratégies Cedar pour gérer l’accès aux points de terminaison d’API en fonction de la spécification des API déployées. En outre, l’Assistant crée un mécanisme d’autorisation Lambda qui autorise l’accès aux ressources API Gateway en fonction des groupes d’utilisateurs configurés. Cela supprime l’effort de modélisation requis pour la configuration initiale de la logique d’autorisation de l’API et la configuration des autorisations vérifiées pour recevoir les demandes d’autorisation. Vous pouvez utiliser l’Assistant pour configurer et tester les contrôles d’accès à vos API en fonction des groupes d’utilisateurs en dehors de la production Comptes. Vous pouvez étendre davantage le schéma de stratégie et les stratégies pour prendre en charge des contrôles d’accès précis ou basés sur des attributs, en fonction des exigences spécifiques de l’application, sans apporter de modifications au code.

Pour en savoir plus sur la façon dont Verified Permissions fournit des autorisations précises avec les principaux fournisseurs d’identité, tels que CyberArk, Okta, Ping Identity, Transmit Security, consultez la page Partenaires Amazon Verified Permissions.

Si vous avez des commentaires sur cet article, soumettez-les dans la section Commentaires ci-dessous. Si vous avez des questions sur cet article, lancez un nouveau fil de discussion sur les autorisations vérifiées Amazon re :Post ou contactez AWS Support.

étiquettes: Amazon API Gateway, Amazon Cognito, Amazon Verified Permissions, blog sur la sécurité