Archives mensuelles : novembre 2017

Azure API Management 5/5 – PowerShell Time

C’est la dernière ligne droite et aussi le temps du PowerShell. Pour Parler PowerShell, tout comme pour Azure Function, cela reposera sur un Invoke-WebRequest. C’est donc presque pareil, à quelques exceptions. La première chose qui change, c’est l’URL. Pour rappel, voilà l’URL de notre Azure Function exposée via notre instance du service Azure API Management.

clip_image001

 

La seconde chose qui change, c’est la clé d’authentification. Nous ne passons plus la clé d’authentification de notre Azure Function (c’est géré au niveau des policies d’Azure API Management) mais une des deux clés dont nous disposons dans la souscription au produit qui présente notre Azure Function. En tant que consommateur, nous pouvons retrouver cette information dans le portail développeur mis à disposition par l’instance du service Azure API Management. Cette clé, nous allons la référencer sous le nom « Ocp-Apim-Subscription-Key »

clip_image003

 

Nous avons toutes les informations, ne nous reste plus qu’à construire notre requête.

$url = « https://tpapimanagement.azure-api.net/AzuretableValetKeyAPI/api/AzuretableValetKeyAPI »

Invoke-RestMethod -Uri $Url -Method POST -ContentType « application/json » -Headers @{« Ocp-Apim-Subscription-Key »= »2fab81140f42490683XXXXXXXXa26ac0 »}

clip_image005

 

Nous y sommes. Nous avons réussi à consommer notre Azure Function exposée par Azure API Management.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Azure API Management 4/5 – C’est l’heure de consommer

Nous avons une API exposée avec des nouvelles fonctionnalités :

  • Point d’accès unique pour toutes mes futures API
  • Une méthode d’authentification unique pour toutes mes API
  • Une journalisation centralisée et non plus gérée au niveau de chaque API
  • Une politique de limitation d’usage

 

La prochaine étape, c’est donc nécessairement de consommer. Azure API Management est capable de s’interfacer avec bon nombre de systèmes d’authentification. Dans le contexte de cette série de billets, nous allons utiliser le fournisseur d’identité par défaut. Chaque utilisateur doit disposer d’un compte et d’un mot de passe pour accéder au service. On peut soit créer des utilisateurs ou les inviter. L’avantage de l’invitation, c’est que c’est l’invité qui sera chargé de configurer son mot de passe. J’ai donc retenu de lui envoyer une invitation.

clip_image002

 

Le client de ma licorne reçoit un mail qui l’invite à se connecter au portail. A noter que ces éléments de communication (template de mails) sont configurables dans Azure API Management.

clip_image004

 

Point d’attention, la politique de mot de passe d’Azure API Management est assez pointue. N’essayez pas d’utiliser des séquences continues dans vos mots de passe.

clip_image006

 

Une fois authentifié, on arrive sur le portail développeurs de notre instance du service Azure API Management. Dans la rubrique « Products », on constate qu’il nous est proposé la souscription d’un service. La notion de souscription à un produit est importante car pour chaque souscription de produit, une paire de clés d’accès est générée.

clip_image008

 

Au sens Azure API Management, un produit permet aux futurs clients de ma licorne de souscrire à nos API. Dans l’exemple ci-dessous, Azure API Management va imposer une Policy qui limite le nombre d’appels par minutes / semaines. Dans mon Business plan de la mort qui tue, j’ai un mode gratuit mais faut pas non plus qu’il me coute les yeux de la tête. Pour l’instant, il n’y a qu’une seule API.

clip_image009

 

Il est possible de personnaliser le nom de chaque souscription réalisée. C’est intéressant si on souscrit plusieurs fois au même produit.

clip_image011

 

C’est souscrit, pour accéder à mon API, je peux constater que j’ai deux clés.

clip_image013

 

En tant que client consommateur de l’API, je peux aussi référencer ma propre application qui va changer la face du monde.

clip_image015

 

Je peux la soumettre à publication, reste à voir si l’administrateur de l’Azure API Management service est prêt à m’aider à démarrer et qui sait devenir demain le nouveau Facebook 3.0.

clip_image017

 

Nous approchons de la fin de cette série de billets. Ne nous reste plus qu’à nous placer en tant que client pour consommer notre API. Ce sera le sujet du dernier billet.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Azure Reserved Instances – La fonctionnalité la plus simple à expliquer

Généralement, les lecteurs de mon blog s’attendent à ce que je disserte sur les fonctionnalités les plus technique d’Azure. La, on va faire juste expliquer la fonctionnalité la plus simple d’Azure. Pour la démontrer, même pas besoin du portail Azure, la calculatrice Azure suffira. L’idée de base, c’est plus on s’engage dans le temps pour consommer plus on obtient de remise. Pour illustrer mon propos, voilà le prix du service Azure compute pour la SKU D1 déployée en standard avec l’OS Windows, le tout hébergé dans la région West Europe. C’est notre prix de référence pour du « Pay as you go ».

clip_image001

Maintenant, si on s’engage à ce que notre machine virtuelle soit provisionnée dans Azure pendant un an, le prix baisse de 33%. C’est bien mais pas top.

clip_image002

Pour être top, il faut s’engager sur trois ans. La, le prix baisse de 44%.

clip_image003

Voilà, c’est tout ce qu’il y à savoir sur Azure Reserved Instance, enfin presque. Il y a quand même quelques limitations. A ce jour, cela ne concerne que les souscriptions de type Pay as you go ou Enterprise Agreement, pas encore les CSP.

Pour plus d’informations, lisez la FAQ.

 

Désolé, j’ai pas plus simple. Même le DAF il va liker!

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Azure API Management 3/5 – Exposition de notre première API

A partir de maintenant, tout va se passer dans Azure API Management. Notre Azure Function est prête à être référencée comme API. Dans l’interface de gestion du service, en cliquant sur « API », on arrive à l’interface ci-dessous :

clip_image001

Azure API Management prend en charge plusieurs langages de description pour nos API. Par chance, l’intégration avec Azure Function est nativement supportée ou presque. L’interface nous propose bien de sélectionner notre Function App (ce qui porte notre fonction) mais pas la fonction en elle-même. C’est pour cela que je spécifie le paramètre API Url suffixe correspondant le nom de la fonction.

clip_image002

Autre sujet important, l’accès authentifié à notre Azure Function. Pour rappel, chaque fonction que nous avons développée dispose de sa propre URL et clé d’accès :

clip_image003

Si je ne fais rien, aucune authentification sera présentée à mon Azure Function. Il faut donc pouvoir intégrer ce code d’authentification dans l’appel depuis Azure API Management. Vu que c’est un secret, on va commencer par le stocker dans une Named Value. Au moment de l’écriture de cette série de billets, il n’est pas encore possible de stocker ses secrets dans un Azure KeyVault. A ce jour, c’est un feedback qui a été remonté à Microsoft : Integration with Azure KeyVault. En attendant KeyVault, nous allons utiliser les Named Values.

clip_image004

Azure API Management permet d’injecter des paramètres additionnels dans le Header. C’est une des nombreuses fonctionnalités offertes par les Azure Policies d’Azure API Management. Nous allons travailler au niveau « Inbound Processing »

clip_image005

Notre opération consistera à ajouter un nouveau paramètre à notre requête HTTP. Pour éditer ma policy, je suis passé en mode « Code-View » pour intégrer une règle de transformation nommée « Set query request parameter ». De cette manière, on va injecter le paramètre « Code » avec la valeur contenue dans la Named Value {{AzureFunctionAPICode}}. Reste à ne pas oublier de cliquer sur le bouton Save.

clip_image006

De retour dans la view « From View », c’est plus simple à comprendre.

clip_image007

Attention, l’utilisation du Named Parameters, dans la vue form view ne conservera pas le named parameters mais va juste remplacer le contenu. D’ou le passage en mode « Form View ».

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Azure API Management 2/5 – Préparer l’exposition de notre Azure Function

Notre service Azure API Management est maintenant posé. Nous allons y revenir. Pour commencer, nous allons rendre notre Azure Function consommable par mon service API Management. Il faut un peu de préparation. A ce stade, il manque une description contenant :

  • Ce que produit notre API
  • Les paramètres qu’elle attend en entrée
  • Les paramètres qu’elle retourne
  • La ou ses différentes versions

Première étape, on va commencer par limiter ce que va accepter notre Azure Function en termes de verbes. Au niveau du nœud « Integrate » de notre fonction. Nous allons affiner la listes méthodes HTTP pour ne retenir que POST sans oublier de sauvegarder notre modification.

clip_image001

 

Prochaine étape, documenter notre API. Dans le contexte Azure Function, c’est le Framework Swagger qui a été retenu par Microsoft pour l’intégration avec Azure API management. Le Framework Swagger utiliser les spécifications OpenAPI. Allons configurer la définition de notre API en cliquant sur « API Definition ».

clip_image002

 

Azure Function peut être exposé sous forme d’API de deux manières :

  • Function (Preview pour l’intégration avec Azure API Management)
  • External URL (Utilisation d’un service tierce)

 

Azure API Management étant un service interne Azure, nous allons cliquer sur « Function (Preview) ».

clip_image003

 

Remarque importante, cela ne change strictement rien sur la méthode d’authentification de notre Azure Function. Nous pouvons toujours la solliciter ne direct dès lors que nous disposons de toutes les informations. C’est un sujet sur lequel nous allons revenir dans un prochain billet de la série.

clip_image004

 

Pour décrire notre API, nous allons utiliser les spécifications OpenAPI. L’intégration avec Azure est bien faite puisqu’on nous propose de créer un squelette JSON en cliquant sur le bouton « Generate API Definition template ».

clip_image005

 

OpenAPI va nous permettre de produire une description qui sera consommée par Azure API Management. Heureusement que mon API est simple. Globalement, j’ai indiqué :

  • Que mon API ne supportera que le HTTPS pas le HTTP
  • Que mon API ne supportait que la méthode POST via une URL bien précise
  • Qu’elle consomme ses paramètres au format JSON (même s’il n’y en a pas dans mon exemple)
  • Quelle produira du contenu au format JSON avec un seul message documenté

clip_image006

 

N’oubliez pas d’appuyer sur « Save ».

Avant d’aller plus loin dans l’intégration, nous allons déjà valider que cela fonctionne. Pour cela nous avons besoin d’une clé d’accès pour notre Azure Function. Dans le nœud « Manage » de notre Azure Function, nous allons récupérer une clé d’authentification en cliquant sur le bouton « Copy ».

clip_image007

 

De retour dans la configuration de la définition de notre API, dans la zone droite de l’interface, nous avons la possibilité de valider l’accès à notre future API. Cliquons sur « Change Authentication ».

clip_image008

 

Dans l’interface ci-dessous, nous allons renseigner la clé d’accès précédemment obtenus puis cliquer sur le bouton « Authenticate ».

clip_image009

 

Un peu plus bas dans l’interface, on constate la présence de la description de la seule méthode supportée par notre API : « Post ». En cliquant sur « Try this operation », nous allons réaliser un appel à notre future API avec la clé d’authentification.

clip_image010

 

Côté Request, mon API étant assez simpliste (aucun paramètre en entrée), ayant limité les choix d’utilisation à HTTPS seulement et imposé le JSON pour les paramètres, il ne nous reste qu’à appuyer sur le bouton « Send Request ».

clip_image011

 

Si tout se passe bien, nous devrions avoir le résultat retourné par notre Azure Function.

clip_image012

 

Côté Azure Function, les prérequis sont en place. Prochaine étape, l’exposition de notre première API.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Azure API Management 1/5 – Introduction

A forcer de créer des API, je vais finir par créer ma licorne. Problème, avec la GDPR qui arrive, si je commence à annoncer à mes futurs investisseurs et clients que je vais développer ma stack sécurité de bout en bout, autant dire que je vais la tuer ma licorne dans l’œuf.

clip_image002

Si développer ma stack sécurité n’est pas une option viable, autant en choisir une qui offre la possibilité de : S’intégrer avec les principaux fournisseurs du marché (Facebook, LinkedIn, Microsoft, Google, …).

  • Proposer un point d’accès unique pour toutes mes API
  • Permettre la mise en place de politiques de contrôle de l’usage de mes API
  • Permettre de gérer la souscription à mes API

Dans la liste des services Azure à destination des développeurs, on trouve Azure API Management Service. Ça fait tout cela et même plus. Dans cette série de billet, nous allons reprendre mon Azure Function proposée dans le billet Azure Function avec Managed Service Identity. Pour rappel voilà son contenu : Une Azure Function qui permet d’extraire un secret de mon Key Vault avec une identité Azure AD utilisant Managed Service Identity.

clip_image004

 

Dans la situation actuelle, tant qu’on dispose de la clé d’authentification associées à la fonction, on peut la solliciter autant qu’on veut et donc gérer une surfacturation. C’est une des fonction d’Azure API Management de limiter la consommation de notre API a un certain nombre d’appel par minutes.

Nous allons commencer par mettre en œuvre une instance du service API Management Service dans un nouveau groupe de ressources. Le service API Management est disponible en trois éditions :

  • Développeur
  • Standard
  • Premium

Pour le détail, je vous renvoie vers la page prévue à cet effet : API Management pricing . J’ai fait le choix de la version développeurs. Au passage, je me désigne comme l’administrateur de ce service.

clip_image005

 

Le provisionning du service API Management est plutôt lent (genre 40 minutes). Azure API Management supporte plusieurs fournisseurs d’identité. On peut :

  • Gérer les utilisateurs accédant à nos API nous-même car il intègre son propre module de gestion des utilisateurs
  • Gérer les utilisateurs en utilisant un Tenant Azure AD, ce qui permet de séparer les comptes des autres ressources Azure, ce qui est déjà bien mieux (mais on gère toujours les utilisateurs)
  • Gérer des utilisateurs issus d’un Tenant Azure AD B2C ce qui est l’option la plus intéressante puisque chaque utilisateur vient avec son identité, nous n’avons plus à la gérer

Remarque : Attention avec Azure AD B2C, au moment de l’écriture de ce billet, il n’est pas encore disponible en CSP. Pour cette raison, nous allons travailler avec le fournisseur d’authentification standard.

Ce qu’il faut comprendre, c’est que ces identités vont permettre à nos consommateurs de se connecter à un portail pour y souscrire l’accès aux API de notre future licorne. Le consommateur ne va donc pas s’authentifier directement avec un compte / mot de passe mais une clé d’accès générée par Azure API Management.

Une fois le provisioning terminé, l’administrateur est notifié par mail de la création du service. Dans le portail Azure, cela ressemble à l’illustration ci-dessous :

clip_image007

 

Première information, le service API Management est accessible selon deux URL :

  • L’URL de la Gateway pour exposer nos API
  • L’URL que nous mettons à disposition de nos partenaires pour gérer la souscription à nos API

clip_image008

 

Avant de poursuivre, on va commencer par configurer la journalisation pour tout envoyer dans Log Analytics.

clip_image009

 

Un peu plus haut, j’avais indiqué que notre service API Management était accessible selon deux URL. En fait, il y en a un peu plus. Bonus, on peut les personnaliser (notion de Custom Domain) ainsi que d’utiliser nos propres certificats.

clip_image011

 

Notre service API Management peut lui-même exposer ses propres API pour le gérer à distance. Par défaut, ce n’est pas activé.

clip_image013

 

Côté Identité, il y a des multiples fournisseurs. Nous allons conserver le fournisseur par défaut. Le service API Management va alors lui-même prendre en charge l’authentification des utilisateurs. Charge à nous administrateur de créer ou inviter des utilisateurs. Nous on va imposer notre marque avec un message de bienvenu sur les services mis à disposition par notre nouvelle licorne.

clip_image015

 

Voilà pour les fondations. Pour la suite, il faudra attendre la publication des prochains billets :

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)