Les API jouent un rôle essentiel dans la connectivité des applications, mais elles sont également vulnérables aux attaques. Auparavant, avec les applications monolithiques, il n’y avait qu’un seul point d’entrée à sécuriser. Dans les architectures de microservices, une même application se compose souvent de nombreux microservices connectés par des API, chacune de ces API pouvant comporter des centaines de points de terminaison. La surface d’attaque potentielle des API est donc considérable, chaque nouvelle API créant un point d’entrée dans votre périmètre de sécurité.
Il existe de nombreuses stratégies pour sécuriser vos API. L’une des plus fondamentales est le contrôle d’accès. En termes simples, vous devez vérifier l’identité de l’utilisateur (authentification, ou AuthN) et confirmer qu’il est autorisé à accéder à certaines ressources (autorisation, ou AuthZ). La mise en œuvre d’OpenID Connect (OIDC) est l’une des approches de contrôle d’accès les plus couramment utilisées pour les API. Vous pouvez la déployer en quelques minutes avec API Connectivity Manager, qui fait partie de F5 NGINX Management Suite.
Dans ce tutoriel, vous apprendrez à mettre en œuvre la partie autorisation du processus OIDC en configurant la validation des jetons web JSON (JWT) avec API Connectivity Manager et Azure Active Directory (Azure AD).
Qu’est-ce qu’OpenID Connect ?
OpenID Connect (OIDC) est un protocole d’identité basé sur le protocole OAuth 2.0. OIDC permet aux clients de vérifier l’identité de l’utilisateur final ou de l’appareil. Il s’agit d’un aspect du contrôle d’accès, qui comprend à la fois l’authentification et l’autorisation :
- Authentification vérifie qu’un utilisateur ou un appareil est bien celui qu’il prétend être
- Autorisation détermine les ressources auxquelles un utilisateur ou un appareil vérifié peut accéder
Il existe de nombreuses implémentations différentes d’OIDC, notamment Azure AD, que vous utiliserez dans ce tutoriel. Vous pouvez également utiliser d’autres solutions OIDC, telles que F5 BIG-IP Access Policy Manager (APM), Okta, Auth0, Ping Identity et bien d’autres, avec API Connectivity Manager.
Ce dont vous avez besoin pour commencer
Assurez-vous de disposer des prérequis suivants :
- API Connectivity Manager installé et configuré dans votre environnement
- Un compte Microsoft Azure actif
- Un client REST (Postman est utilisé dans ce tutoriel)
Vous pouvez vous inscrire pour bénéficier d’un essai gratuit de 30 jours de NGINX Management Suite si vous avez besoin d’accéder à API Connectivity Manager.
Créer une application Azure AD
Ouvrez un navigateur et connectez-vous à votre portail Azure.
Cliquez sur « Inscriptions d’applications » dans le menu de gauche.
Figure 1 : page d’accueil du portail Azure AD
Cliquez sur le bouton « Nouvelle inscription ».
Figure 2 : inscription d’une application dans Azure AD
Pour créer une nouvelle application, indiquez un nom, un URI de redirection, puis cliquez sur le bouton Inscrire. Dans cette démonstration, vous utiliserez Postman, et donc l’URI de redirection OIDC de Postman.
Figure 3 : Créer une nouvelle application Azure AD
Maintenant que votre application est créée, vous devez créer des étendues OAuth pour permettre l’accès à l’API. Cliquez sur le lien « Exposer une API » dans le menu de gauche.
Figure 4 : Exposer une API
Cliquez sur « Ajouter une étendue ».
Figure 5 : Ajouter une portée
Acceptez l’URI d’ID d’application par défaut ou créez la vôtre, puis cliquez sur le bouton « Enregistrer et continuer ». Si vous souhaitez créer votre propre URI d’ID d’application, vous devez enregistrer le domaine souhaité auprès d’Azure AD.
Figure 6 : URL de l’ID d’application
Pour cette démonstration, votre étendue est basée sur un exemple de Microsoft. Remplissez le formulaire avec les informations suivantes, puis cliquez sur le bouton « Ajouter une étendue » :
Nom de l’étendue : Employees.Read.All
Qui peut donner son consentement ? : Administrateurs et utilisateurs
Nom d’affichage du consentement administrateur : Accès en lecture seule aux dossiers des employés
Description du consentement administrateur : Autoriser l’accès en lecture seule à toutes les données des employés.
Nom d’affichage du consentement utilisateur : Accès en lecture seule à vos dossiers d’employé
Description du consentement utilisateur : Autoriser l’accès en lecture seule à vos données d’employé.
Figure 7 : Ajouter une portée
Vous devez ensuite autoriser l’application cliente. Pour ce faire, récupérez l’ID client. Cliquez sur le lien « Vue d’ensemble » dans le menu de gauche, puis copiez l’ID d’application (client).
Figure 8 : ID client de l’application
Cliquez à nouveau sur le lien « Exposer une API », puis cliquez sur le bouton « Ajouter une application cliente ».
Figure 9 : Ajouter une application cliente
Collez l’ID client de l’application dans le champ ID client et cochez la case située à côté de l’URI de votre ID d’application. Cliquez ensuite sur le bouton « Ajouter une application ».
Figure 10 : Ajouter une application cliente
Ensuite, pour cette démonstration, vous utiliserez un code d’autorisation avec le « flux de code d’autorisation ». Un secret client sera donc nécessaire pour Postman. Cliquez sur le lien « Certificats et secrets » dans le menu de gauche, puis sur le bouton « Nouveau secret client ».
Figure 11 : Nouveau secret client
Nommez votre secret et conservez la durée d’expiration par défaut.
Figure 12 : Nom secret
Ensuite, copiez votre secret client et stockez-le dans un coffre-fort de mots de passe afin de pouvoir l’utiliser ultérieurement.
Figure 13 : Secret client
Configurer l’assertion JWT dans API Connectivity Manager
Maintenant que votre application Azure AD est configurée, vous pouvez configurer le cluster de passerelles API dans API Connectivity Manager afin qu’il effectue une assertion de jeton web JSON pour le service que vous avez défini. Pour cette étape, vous devrez déterminer l’URI des ensembles de clés web JSON (JWK) de votre locataire Azure AD.
Vous pouvez obtenir l’URI de votre JWKS à partir du point de terminaison bien connu de votre locataire Azure AD:
https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration
Cette page fournit une charge utile JSON contenant la clé jwks_uri. Vous devrez copier sa valeur.
Figure 14 : point de terminaison Well-Known du locataire Azure AD
Maintenant que vous disposez de votre URI JWKS, ouvrez la console API Connectivity Manager et accédez à la configuration de votre proxy de service. Cliquez sur « Ajouter une stratégie » pour la stratégie « Assertion de jeton Web JSON ».
Figure 15 : stratégies de proxy du service de passerelle
Ensuite, collez l’URI JKWS de votre locataire Azure AD dans le champ « Emplacement de l’URI », puis cliquez sur le bouton « Ajouter ».
Figure 16 : stratégie d’assertion JSON Web Token
Cliquez sur le bouton « Enregistrer et publier » pour déployer cette politique sur votre cluster de passerelles API.
Figure 17 : politique de passerelle de services
Et voilà ! Votre instance d’API Connectivity Manager est désormais configurée pour effectuer une assertion JWT sur la passerelle de services configurée.
Tester avec Postman
Il est maintenant temps de tester votre configuration et de vous assurer qu’elle fonctionne comme prévu. Pour commencer, vous devrez récupérer quelques informations dans votre application Azure AD :
- Secret client de l’application (que vous avez enregistré précédemment)
- Portée OAuth
- Point de terminaison d’autorisation OAuth
- Point de terminaison de jeton OAuth
Pour obtenir l’étendue OAuth, ouvrez votre portail Azure et revenez à la page d’inscription de votre application. Cliquez ensuite sur le lien « Exposer une API » dans le menu de gauche, puis sur l’icône « Copier » correspondant à votre étendue. Enregistrez cette valeur afin de pouvoir l’utiliser dans quelques minutes.
Figure 18 : portées de l’API
Pour obtenir les points de terminaison d’autorisation et de jeton OAuth, cliquez sur le lien « Vue d’ensemble » dans le menu de gauche, puis sur le bouton « Points de terminaison ». Copiez ensuite les URI des points de terminaison d’autorisation et de jeton.
Figure 19 : points de terminaison de l’application Azure AD
Figure 20 : URL des points de terminaison de l’application Azure AD
Ouvrez Postman et cliquez sur le menu « Environments ». Cliquez ensuite sur le lien « Create Environment ».
Figure 21 : création d’un environnement Postman
Nommez votre environnement et ajoutez six variables avec les valeurs (enregistrées lors des étapes précédentes) dans la colonne « Valeur initiale » et dans la colonne « Valeur actuelle », puis cliquez sur le bouton « Enregistrer ».
- client_id: ID client de l’application Azure AD
- client_secret:secret client de l’application Azure AD
- auth_url: URL d’autorisation OAuth du locataire Azure AD
- token_url: URL du jeton OAuth du locataire Azure AD
- tenant_id: ID de l’annuaire Azure AD (locataire)
- scope: étendue de l’API de l’application Azure AD avec l’URL de l’ID d’application
Figure 22 : variables d’environnement Postman
Ouvrez un nouvel onglet dans Postman et suivez les étapes ci-dessous :
- Sélectionnez l’environnement « ACM » en haut à droite
- Ajoutez l’URL de votre API dans la barre d’adresse
- Cliquez sur l’onglet « Auth »
- Définissez le Type sur OAuth 2.0
- Faites défiler la configuration de l’authentification vers le bas et définissez les variables suivantes :
- URL d’authentification : {{auth_url}}
- URL du jeton d’accès : {{token_url}}
- ID client : {{client_id}}
- Secret client : {{client_secret}}
- Cliquez sur le bouton « Obtenir un nouveau jeton d’accès »
Figure 23 : requête Postman
Figure 24 : configuration de l’authentification dans Postman
Une fenêtre de navigateur s’ouvrira et vous serez invité à vous connecter à l’aide de vos identifiants Azure AD. Une fois l’authentification réussie, vous serez redirigé vers Postman et la fenêtre suivante s’affichera. Cliquez sur le bouton « Use Token ».
Figure 25 : utilisation du jeton dans Postman
Maintenant que vous disposez de votre jeton d’accès OAuth, vous pouvez enfin effectuer votre appel d’API. Cliquez sur le bouton « Enregistrer », puis sur le bouton « Envoyer ».
Si tout est correctement configuré, vous devriez obtenir une réponse 200 OK.
Figure 26 : requête Postman réussie
Conclusion
Vous disposez désormais d’API Connectivity Manager pour protéger vos API à l’aide de jetons d’accès OAuth Azure AD. Les prochaines étapes consisteraient à ajouter des étendues OAuth supplémentaires et à configurer le cluster de passerelles API dans API Connectivity Manager afin de transmettre ces étendues à vos API protégées, mais ce sera le sujet d’un autre article !
Commencez dès aujourd’hui
Commencez un essai gratuit de 30 jours de NGINX Management Suite, qui comprend API Connectivity Manager et Instance Manager.
Une version de cet article a été publiée pour la première fois sur codygreen.com. Elle est reproduite ici dans une version modifiée avec l’autorisation de l’auteur.
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.