Microsoft lance Microsoft Graph !

Bonjour à tous,

Aujourd’hui, une petite news liée à l’offre Office 365 : Microsoft Graph. La sortie de cette fonctionnalité entre dans la « nouvelle » stratégie de Microsoft : faciliter et augmenter l’ouverture de ses produits à des applications tierces, quelques soit la technologie utilisée par lesdites applications. On est donc également dans une philosophie de standardisation.
Rien à voir avec la fonctionnalité Graph qui était (est toujours ?) dans Excel. Il ne faut pas non plus confondre ce produit avec Office Graph, qui enregistre les interactions des utilisateurs sur des objets d’Office 365.

A quoi ça sert ?
A interagir avec (presque) toutes les données que stocke Office 365. Cela va de vos mails à vos fichiers OneNote, en passant par vos documents, fichiers Excel, …). Le gros avantage, c’est qu’on peut maintenant le faire au travers d’une seule API, via une simple requête Http en GET.

MicrosoftGraph_DevStack

 

Ainsi, on note également que la nouvelle version de l’API (encore en beta) permet un certain nombre d’avancées en terme de typologies de contenus à requêter.

Office Graph

Comment ça marche ?
Comment je l’indiquais ci-dessus, c’est une API qui fonctionne en HTTP via GET, qui renvoie les données en JSON. Voici le site sur lequel vous pouvez réaliser des tests pour vous donner une idée de la portée : https://graphexplorer2.azurewebsites.net/

Il faut « juste » s’authentifier en amont sur votre Azure AD.
Toute la documentation est disponible ici.

Enfin, un projet ASP.Net MVC est disponible, tout est déjà codé, y’a plus qu’à créer l’application dans Azure et à débuguer !

Pour aller plus loin, je vous invite à regarder cette excellente vidéo de Ynas Arenas sur Channel 9

Publicités

Web Service dans Azure : créez, sécurisez et consommez !

Note : les projets Visual Studio évoqués ci-dessous sont disponibles à la fin de ce post

Bonjour à tous,
Aujourd’hui je voudrais vous montrer comment facilement créer un webservice dans Azure, et comment le consommer, de manière sécurisée, avec les applications de l’Azure AD.

Cela peut paraître facile, mais ne vous y trompez pas : j’ai dû passer pas mal de temps à comprendre les mécanismes d’authentification avec Azure (OWIN, …). J’écris également ce billet car j’ai eu l’occasion de discuter avec l’excellente Joëlle Ruelle et d’autres personnes, notamment lors du yOS Montréal, qui ont rencontré des problèmes avec l’Azure AD (qui gère toute la partie authentification).

Avant d’avancer, je voudrai également préciser qu’à l’heure actuelle, Microsoft n’a pas fourni de documentation complète et claire sur ces sujets. Ce qui est dommage, mais je vais essayer d’y remédier.

Avant de faire du deep dive, je voudrai faire un peu de théorie. L’Azure AD change un peu notre façon de concevoir l’authentification.

Ce qu’il faut bien comprendre, c’est que votre web service et votre client existe dans l’Azure AD. Si l’Active Directory On Prem a (généralement) une pure fonction d’annuaire d’utilisateurs et de ressources, il s’est vu ajouter un nouveau type d’entité dans Azure : les applications.

Ainsi, ce qu’il faut saisir, c’est que vous devez gérer l’authentification à deux niveaux :

  • L’authentification d’un utilisateur lorsqu’il veut se connecter à votre consommateur de web service (client)
  • l’authentification de votre client sur le web service.

L’Azure AD fait les deux, et je vais vous expliquer comment cela fonctionne…

Let’s Rock With Azure !

Créez votre propre Web API.

Je pensais vous montrer comment faire, mais je me suis souvenu qu’il y a un très bon billet officiel sur le site d’Azure. Aucun intérêt à refaire ce qui a été fait… https://azure.microsoft.com/fr-fr/documentation/articles/app-service-dotnet-create-api-app/
On voit d’ailleurs ici l’utilisation de Swagger qui est complètement intégré dans le template. J’adore cet outil !

Vous devez arriver au point 2 en ayant publié votre Web service (ou API) dans Azure…Capture d’écran 2015-11-04 à 12.32.15

Note : si votre web service doit disposer d’une IP fixe (cela arrive parfois, sur certaines infrastructures), vous serez obligés de l’héberger sur un Cloud Service ou sur une machine virtuelle dans Azure (ou autre).

Pour tout vous dire, je me suis cassé les dents sur les Cloud Service. Il s’agit de sortes de VM préparées dans Azure, auxquelles on peut attribuer une IP fixe. Mais franchement, je n’ai jamais réussi à déployer un dev là dessus… Ça bug dans tous les sens. Donc => Go machine virtuelle.

Activez l’authentification.

Dans vos projets business, vous n’ouvrez généralement pas votre API a qui veut l’exploiter. Vous devez demander au client de s’identifier. On va pouvoir faire ça en en quelques minutes.Installez ça via NuGet dans votre projet : https://www.nuget.org/packages/Microsoft.IdentityModel.Clients.ActiveDirectory
https://www.nuget.org/packages/Microsoft.Owin.Security.ActiveDirectory/
https://www.nuget.org/packages/Microsoft.Owin.Host.SystemWeb/

Rendez-vous dans le controller (notez que je mets sérieusement au MVC ^^) et, juste au dessus de la classe, ajoutez [Authorize]Capture d’écran 2015-11-06 à 10.09.05On va également finaliser l’implémentation d’OWIN : ajouter une classe Owin comme dans le screenshot ci-dessous.
Capture d’écran 2015-11-06 à 09.44.57

Nommez la startup.csCapture d’écran 2015-11-06 à 09.45.43

Gardez le fichier ouvert, on va y revenir !

Créez une application dans votre Azure AD
Capture d’écran 2015-11-06 à 09.07.17Capture d’écran 2015-11-06 à 09.07.59Capture d’écran 2015-11-06 à 09.08.09Capture d’écran 2015-11-06 à 09.08.32

Remplissez les propriétés de l’application

URL de connexion : il s’agit de l’URL du serveur sur lequel est hébergé votre API. C’est une information que vous avez dû récupérer au moment de la publication de votre API sur Azure.

URI ID d’Application : il ne s’agit pas d’une URL au sens propre, mais d’un moyen d’identifier facilement votre application. Ce n’est ni plus ni moins qu’un ID qui a la forme d’une URL. A vous de le définir pour qu’il soit unique au sein des applications de votre Azure AD.Profitez-en pour copier l’URI ID d’Application.

Capture d’écran 2015-11-06 à 09.09.34

Retour dans Visual Studio, et dans la classe Startup.cs qu’on vient de créer.
Ajoutez le code ci-dessous :

1:  public void Configuration(IAppBuilder app)  
2:      {  
3:        ConfigureAuth(app);  
4:      }  
5:    
6:      private void ConfigureAuth(IAppBuilder app)  
7:      {  
8:        app.UseWindowsAzureActiveDirectoryBearerAuthentication(  
9:        new WindowsAzureActiveDirectoryBearerAuthenticationOptions  
10:        {  
11:          Audience = "https://clouds-natives/rockwithazure-webservice",  
12:          Tenant = "clouds-natives.com"  
13:        });  
14:    
15:      }  

Remplacez les valeurs de « Audience » et « Tenant » par les valeurs que vous venez de saisir.

Audience est l’URI ID d’Application de votre web service précédemment créé dans l’Azure AD
Le tenant, c’est le nom de domaine de votre Azure AD.

ça devrait ressembler à ça :
Capture d’écran 2015-11-06 à 09.47.32

Si vous relancez un debug et chargez Swagger, vous verrez que vous ne pourrez plus accéder aux contacts (puisque Swagger ne s’authentifie pas sur l’AD).

Capture d’écran 2015-11-06 à 10.39.16

Votre web service est donc maintenant correctement sécurisé, nous allons voir comment le consommer, en s’authentifiant.

Créez une application cliente, consommatrice de votre web service

On va tout d’abord préparer une application dans l’Azure AD pour notre consommateur du web service, et lui dire qu’il peut s’authentifier sur l’application du Web Service.

Comme précédemment pour le web service, nous allons créer une nouvelle application sur notre AAD.

Capture d’écran 2015-11-06 à 11.27.28

Capture d’écran 2015-11-06 à 11.28.49

Une fois l’application créée, on se rend dans ses paramètres, en cliquant sur « Configurer »Capture d’écran 2015-11-06 à 09.37.52

Scrollez vers le bas, et vous tomberez sur les « clés ». Il s’agit de passphrase permettant à votre application cliente de s’authentifier. Sélectionnez 1 année ou 2 années, et enregistrez (le bouton en bas de l page) !

Capture d’écran 2015-11-06 à 09.38.06

La clé s’affiche alors, copiez là.Capture d’écran 2015-11-06 à 09.38.28

Enfin, toujours en scrollant vers le bas, vous allez arriver sur la rubrique « autorisations pour d’autres applications ». C’est là qu’on va donner les droits à l’application cliente de se connecter à l’application du web service.

Cliquez sur le bouton vert « Ajouter une application »

Capture d’écran 2015-11-06 à 09.39.17

Sélectionnez le web serviceCapture d’écran 2015-11-06 à 09.39.47

Et enfin, donnez une autorisation déléguée à votre application cliente pour qu’elle puisse s’authentifier sur votre application service. Attention : n’oubliez pas de cliquer sur « Enregistrer »

Capture d’écran 2015-11-06 à 09.40.05

On va donc créer un second projet Visual Studio, celui-ci sera une application web cliente de votre Web Service.
Capture d’écran 2015-11-06 à 10.43.09

Lorsque le projet est créé, ajoutez le packet suivant : https://www.nuget.org/packages/Microsoft.IdentityModel.Clients.ActiveDirectory

Dans le code behind de votre page default.aspx, ajoutez le code suivant dans la classe.
Définissez les variables du haut de ce bout de code avec vos propres valeurs

 /// <summary>  
     /// Le nom de domaine de votre Azure AD  
     /// </summary>  
     private static string strTenant = "clouds-natives.com";  
     /// <summary>  
     /// Le Client ID de l'application créée dans AAD (onglet "configurer")  
     /// </summary>  
     private static string strClientId = "c01db880-48c1-4a9a-ae0d-6414e72e28e8";  
     /// <summary>  
     /// La passphrase de l'application créée dans AAD  
     /// </summary>  
     private static string strPassPhrase = "";  
     /// <summary>  
     /// Le URI ID d'Application de l'application cible (le webservice), créé dans les points précédents  
     /// </summary>  
     private static string strAADIdOfTheTargetApp = "https://clouds-natives/rockwithazure-webservice";  
     /// <summary>  
     /// L'URL du webservice a appeler  
     /// </summary>  
     private static string strRequestUrl = "https://microsoft-apiapp3bbbd2c854bf48c680cf6df2583e023b.azurewebsites.net/api/Contacts";  
   
   
     private static string aadInstance = "https://login.microsoftonline.com/{0}";  
     private static string authority = String.Format(CultureInfo.InvariantCulture, aadInstance, strTenant);  
     static private AuthenticationContext authContext = new AuthenticationContext(authority);  
   
     protected void Page_Load(object sender, EventArgs e)  
     {  
       var result = Task.Run(() => ReadValues()).Result;  
       lblResult.Text = result;  
     }  
   
     public async Task<string> ReadValues()  
     {  
       AuthenticationContext authContext = new AuthenticationContext(authority);  
   
       ClientCredential credential = new ClientCredential(strClientId, strPassPhrase);  
   
       AuthenticationResult assertionCredential = authContext.AcquireToken(strAADIdOfTheTargetApp, credential);  
   
       // Create an HTTP client and add the token to the Authorization header  
       HttpClient httpClient = new HttpClient();  
       httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(assertionCredential.AccessTokenType, assertionCredential.AccessToken);  
         
       HttpResponseMessage httpResponse = await httpClient.GetAsync(strRequestUrl);  
       string strToReturn = await httpResponse.Content.ReadAsStringAsync();  
       return strToReturn;  
     }  

Voilà à quoi ça doit ressembler

Capture d’écran 2015-11-08 à 10.02.32

Sur le fichier « default.aspx », n’oubliez pas d’ajouter votre label et de supprimer le code inutile.

 <%@ Page Title="Home Page" Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="RockWithAzure_API_Client._Default" %>  
   
 <asp:Content ID="BodyContent" ContentPlaceHolderID="MainContent" runat="server">  
   

Get from API

Et voilà ! Vous pouvez débuger (F5) ou même déployer dans Azure (ou un IIS quelconque) votre web application.

Capture d’écran 2015-11-08 à 10.11.55

Pour aller plus loin : sécurisez l’application web cliente

Il peut vous arriver de vouloir sécuriser l’accès à votre application cliente. Rien de plus simple avec Azure ! Si votre application web est hébergée sur Azure, vous pouvez obliger les utilisateurs qui s’y connectent à être dans un AAD.

Pour se faire, rendez-vous dans le portail préliminaire, et dans le panneau de votre application web.

Capture d’écran 2015-11-08 à 10.41.07

Capture d’écran 2015-11-08 à 10.41.54Capture d’écran 2015-11-08 à 10.44.07

Si vous vous rendez à nouveau sur votre web application, vous verrez que vous devez maintenant vous connecter (attention : à tester avec un navigateur non encore connecté, ou en mode inPrivate).

Si vous essayez de vous connecter à votre application cliente, vous serez redirigé vers une page d’authentification.

Capture d’écran 2015-11-08 à 10.51.12

Capture d’écran 2015-11-08 à 10.51.26

Et voilà ! Votre API et son consommateur sont 100% sécurisés et prêts à être utilisés (et enrichis).

Vous trouverez ci-dessous les deux projets Visual Studio :
– Webservice API : http://1drv.ms/1PvME8C
– Web client application : http://1drv.ms/1PvMCxG

Attention : les diverses variables (client ID, passphrase, …) sont ici en dur dans le code. Ce n’est pas du tout la bonne pratique. Il faudra mettre ces variables dans le web.config.

N’hésitez pas si vous avez des questions !