Integrate 2022 : Azure API Management – Tips & Tricks

Dans le cadre de la Modern Integration, les intégrations par APIs prennent de plus en plus de place. C’est pourquoi Microsoft a intégré comme outil de management Azure APIM à sa suite AIS (Azure Integration Service) pour gérer les APIs et leurs contraintes (sécurité, exposition…).

Lors du salon Integration 2022, qui s’est déroulé au mois de juin, de nombreux intervenants sont venus parler de ce service de la suite Azure. Pour en savoir plus sur cet événement, consultez notre article Integrate 2022 : retour sur les grandes annonces

Dans cet article, nous allons voir ensemble les nouveautés annoncées et conclurons sur les Tips & Tricks qui ont été donnés, sans oublier de vous donner notre avis basé sur notre expérience du terrain.

Les nouvelles fonctionnalités d’API Management

Lors de leur conférence, Elizabeth Barnitt et Adrian Hall ont présenté les nouvelles fonctionnalités de l’APIM sorties ou qui sont en preview publique actuellement.

Tout d’abord, voyons les fonctionnalités qui viennent de sortir dans les mois précédents :

• Integration avec EventGrid : EventGrid peut maintenant souscrire à des évènements provenant de l’APIM.
• Gestion des WebSockets APIs: Exposition des WebSocket APIs dans l’APIM.
• Policy fragments : Création des policies complexes pouvant être réutilisées partout.
• GraphQL APIs: Publication et exposition des GraphQL APIs dans l’APIM.
  A NOTER : nous publierons prochainement un nouvel article présentant le concept des GraphQL APIs et ses bénéfices.
• SOAP et XML: Validation du format des messages entrants et sortants XML et SOAP.
• Developer Portal : Injection d’HTML custom dans le portail de management avec de nouveaux widgets. Amélioration du support d’OPEN API dans les pages des APIs.
• Self-Hosted Gateway v2: CodeBase unifié supporté par Open Telemetry pour la configuration de nouveau endpoint.
• Integration avec Power Platform: Exporter des APIs comme connecteurs custom pour l’utiliser dans Power Apps et Automate Flows.

Il y a également des nouveautés actuellement en preview publique :

• Autorisation : Simplification du management des tokens pour les backends sécurisés avec le protocole OAuth sans avoir à exposer l’API avec une clé de souscription.
• Integration des Private Link : Simplification de la configuration de la connectivité entre les instances APIM et les API Gateways (Front Door, Api Gateway).
• Management des certificats: APIM offre la possibilité de provisionner et renouveler un certificat gratuit pour la sécurisation des domaines customs.
• GraphQL APIs: Créer une API GraphQL à partir d’une API SOAP ou REST existante.

Découvrons à présent les 10 Tips & Tricks présentés par Toon Vanhoutte lors d’Integrate 2022. Pour plus de visibilité, nous avons découpé par thématiques les sujets que nous allons aborder : gouvernance, sécurité et monitoring.

Les Tips & Tricks

Gouvernance

Reprise après sinistre : le backup planifié

Comme dans tout projet la question de comment s’assurer de la restauration d’une instance en cas de problème se pose lors de la mise en place de l’APIM. Pour cela, nous pouvons templatiser toutes les installations, mais ceci ne permet pas de récupérer les données (produits, souscription…).

Ce Trick s’appuie sur l’API de restauration proposé par APIM, déclenché par une LogicApp toutes les nuits et qui va stocker le fichier dans un storage account.

Cette solution est intéressante, car elle permet de restaurer comme telle une instance avec ses données même si elle comporte plusieurs limitations :

• L’opération de backup prend une dizaine de minutes.
• Les backups ne restaurent que les services APIM du même tier.
• Les backups expirent au bout de 30 jours.
• Cette fonctionnalité n’est pas disponible pour les instances en Consumption tier.

A noter : depuis peu, Microsoft propose une option de soft-delete qui permet de récupérer dans un laps de temps court après la suppression (encore en preview).

Exposition dynamique des Open API définitions via une API publique

Ce Trick répond à la question de comment communiquer les définitions (ou Swagger) des APIs exposées afin que les consommateurs puissent les appeler, en proposant d’exposer une API permettant de récupérer dynamiquement les open définitions des APIs en s’appuyant sur API Export de l’APIM.

Pour aller plus loin techniquement, nous vous invitons à consulter la documentation Microsoft sur API Export.

Comme toute exposition de swagger, celui-ci entraine certains risques de sécurité. Il est donc nécessaire, en amont, de penser à mettre en place certains mécanismes d’authentification (Oauth2, clé de souscription…).

Microsoft propose un portail (Developer Portal) permettant de faire automatiquement cette exposition de swagger et bien d’autres fonctionnalités qui permettent aux consommateurs de facilement s’interfacer avec une API.

Designer les APIs en layer

Ce Tip revient sur la nécessité de décomposer les APIs en plusieurs couches afin de décorréler au maximum les différentes étapes du flux :

• Les APIs Business qui seront appelées par tous les services souhaitant consommer les services et qui porteront les Business Model associés aux APIs.
• Les APIs Orchestration qui seront responsables de faire toutes les actions nécessaires au déroulement d’un flux (transformation, agrégation, enchainement d’appels par exemple).
• Les APIs Services qui permettront de faire la liaison avec les partenaires sortants : CRM, SAP, base de données…

Ce Tip reprend un grand principe de l’intégration qui est de décomposer les flux en demi-flux (entrant et sortant) afin d’empêcher les adhérences de changement de format (voire de partenaire) ou de pouvoir rajouter des demi-flux facilement à un flux existant.

Cependant, ce que nous faisons principalement auprès de nos clients n’est pas de créer des APIs Orchestrations pour effectuer les actions d’orchestration du flux, mais de s’appuyer sur des composants tels que LogicApp ou Azure Function qui sont plus indiqués pour effectuer ces actions.

L’importance de l’élément <base/> dans les policy APIM

Ce Tip revient sur un point très souvent méconnu ou sous-estimé par les développeurs d’API :  l’importance de l’élément <base /> dans l’exécution des policy globales lors de l’appel des APIs. En effet, cet élément est le garant de l’ordre d’exécution des policies héritées des niveaux supérieurs.

Notons que dans l’APIM, il est possible de définir des policies à quatre niveaux : All APIs (au niveau de l’instance, des produits, de l’API et de l’opération).

Ici, il est proposé de sécuriser la présence de l’élément <base /> de deux façons différentes (qui peuvent être combinées) à partir de script PowerShell :

• En validant les policies dans le pipeline de build.
• En validant les policies dans l’instance APIM directement.

Sécurité

Enforce HTTPS with Azure Policy

Ce Tip reprend une des problématiques que nous rencontrons régulièrement lors de nos missions : comment s’assurer (et être certain) que toutes les APIs d’une plateforme n’autorisent que les appels HTTPS. Bien entendu, c’est au niveau de chaque API qu’il faut le configurer, soit via le portail soit via ARM template. Mais lorsque plusieurs développeurs (voire équipes) travaillent sur la même instance APIM, il est difficile de contrôler en permanence que cette configuration soit bien faite.

Ce Tip nous propose l’utilisation d’Azure policy pour s’assurer qu’à chaque exposition d’une API, un contrôle de cette configuration soit fait ou que l’exposition soit refusée dans le cas inverse.

Les Azure policies sont un bon outil que nous utilisons également chez nos clients pour mettre en place des règles de gouvernance généralisées pour gérer nos plateformes APIM.

Sécurisation des APIs avec des RBAC (Role Base Access Control)

Dans une plateforme d’API où de nombreux utilisateurs seront amenés à consommer les APIs, il est important de pouvoir contrôler (et sécuriser) ces consommations. APIM propose un système de souscription (Suscription key), mais dans la majorité des cas, ce n’est pas suffisant pour protéger de façon satisfaisante. Pour cela, une des solutions les plus récurrentes consiste à le combiner avec le protocole OAuth2 (supporté par n’importe quel Identity Provider).

La solution apportée dans cet exemple est de créer une identité (App Registration) pour l’instance APIM où tous les rôles seront déclarés (pour un découpage plus fin, le choix d’une identité par API est aussi possible). Chaque API a deux rôles : un rôle de lecture et un rôle d’écriture. Chaque consommateur devra lui aussi être enregistré dans l’IdP (obligatoire pour générer le token) et dans son identity où seront déclarés tous les droits dont il a besoin pour consommer la ou les APIs.

Dans le cadre de nos missions chez nos clients, nous utilisons également cette méthode qui permet un contrôle optimal de la consommation des APIs exposées sur nos plateformes. Cependant, nous proposons de configurer non pas deux mais trois rôles pour chaque API : un en écriture, un en lecture et un autre en lecture/écriture. Cela a pour but de différencier dans l’APIM les consommateurs ayant le droit d’appeler les APIs dans les deux modes et ceux qui appellent sur l’un des deux, notamment pour des besoins de monitoring.

Note : Dans l’inbound policy, un contrôle des claims est nécessaire comme dans l’exemple ci-dessous :

Cacher les stack traces dans l’APIM

Pour des raisons de sécurité, nous sommes confrontés à la nécessité de ne pas exposer la stack trace d’une erreur en réponse d’une API. En effet, une stack trace comprend une mine d’informations sur la technologie utilisée et peut donc devenir une faille de sécurité que des personnes malveillantes pourraient utiliser. De ce fait, dans nos missions nous privilégions de retourner des exceptions génériques à la place, cette méthode pouvant rendre difficile l’analyse des anomalies.

Pour résoudre cet inconvénient, ce Tricks montre une manière intelligente de cacher la stack trace dans le retour (en erreur) des APIs exposées dans l’APIM, il est couplé avec l’utilisation du composant Application Insight.

Il consiste donc à configurer App Insights pour qu’il collecte les traces de chaque requête en attribuant à celle-ci une ID unique (propagée tout le long de son cycle de vie) et en le retournant dans un message d’erreur générique. Ainsi, le partenaire recevant ce message peut communiquer à l’équipe en charge du run de la plateforme qui pourra facilement retrouver les traces dans l’App Insight.

Communication avec les backends sans mot de passe

Il s’agit du dernier Tip donné sur la communication entre l’APIM et les backends. En effet, lors de la mise en place d’une plateforme APIM, beaucoup de questions se posent sur l’authentification des consommateurs mais très peu avec les backends.

Pour faciliter les communications avec les backends qui supportent AAD authentification, Microsoft permet d’activer le Managed Service Identity (MSI) sur l’instance d’APIM en créant un service principal explicite pour celle-ci.

Lors de nos missions, nous utilisons aussi très couramment les MSI qui assurent une authentification sûre et facile à mettre en place entre les instances APIM et les backends.

A noter : Il faut créer une policy pour utiliser la fonctionnalité MSI. Cette policy diffère en fonction du backend, voici quelques exemples en fonction des différentes ressources.

Monitoring

Reporting: émettre des métriques customisées avec APIM

Le reporting est un besoin primordial de toute plateforme d’intégration pour pouvoir monitorer mais aussi communiquer avec les partenaires sur ce qui se déroule sur la plateforme. Ce reporting inclut la possibilité de tracker des données customisées et de pouvoir les exploiter dans des ressources AppInsight, LogAnalytics, etc. pour faire du dashboarding ou de l’alerting grâce à ces données plus fines répondant aux cas d’usages de la plateforme. On peut même aller plus loin avec PowerBI pour créer des dashboards répondant aux différents besoins.

Pour ce faire, il faut rajouter dans la policy un « emit-metric » comme suit :

Note : la fonctionnalité d’alerting avec des métriques customisées est encore en public preview pour le moment.

Envoyer les API inspector traces dans AppInsight

Ce Trick aborde le sujet de comment pouvoir debugguer les APIs exposées sur les instances APIM. Il montre comment envoyer les API traces dans AppInsight afin de savoir, étape par étape (Inbound, Backend, Outbound), ce qu’il se passe au sein des policy.

Cette méthode peut s’avérer utile pour savoir exactement ce qu’il se passe, même dans un environnement de production. Cependant, en raison des coûts et du volume de traces que cela peut engendrer, nous conseillons dans les environnements de production de bien réfléchir avant de l’activer et de ne le faire que de façon ponctuelle.

A noter :  Pour configurer la verbosité en mode debug, cela ne peut être fait que par template ARM car le portail n’offre pas cette possibilité.

Vous souhaitez en savoir plus sur les Tips and Tricks évoqués ? N’hésitez pas à  consulter le blog de Toon Vanhoutte.

Au travers de cet article, nous constatons l’amélioration continue apportée par Microsoft au service API Management. Nous voyons leur volonté d’en faire un outil complet pouvant répondre au nombre grandissant de problématiques complexes que peuvent avoir les entreprises dans la gestion de leur APIs : sécurisation, uniformisation, exposition interne comme externe, protocoles de communication divers…

Et si vous êtes intéressés par le sujet, nous vous invitons à consulter nos autres articles sur les APIs.