Dans le cadre d’une migration de notre infrastructure vers Azure Active Directory, il nous a été demandé d’utiliser les outils d’authentifications fournit par la plateforme Azure AD pour que nos API utilisant actuellement un provider d’authentification “homemade” (se basant sur le protocole OAuth 2.0) soient compatibles avec celui de Microsoft. Nos applications sont sécurisées à l’aide de rôles applicatifs que les utilisateurs doivent fournir pour accéder aux routes de nos contrôleurs.

Dans cet article nous allons voir comment structurer un groupe Azure AD de manière à ce que les rôles attribués à nos utilisateurs nous servent à contrôler les accès aux applications enregistrées sur la plateforme Azure. Je pars du principe que vous disposez déjà d’un compte locataire. Dans le cas contraire je vous invite à vous créer un compte gratuit et à lire l’article suivant pour vous créer une instance d’Azure AD : https://docs.microsoft.com/fr-fr/azure/active-directory/develop/quickstart-create-new-tenant

Il est important de savoir qu’en fonction du type de licence Azure Active Directory que vous possédez, l’association de groupes au sein d’une application inscrite ne pourra être possible. L’ajout d’un rôle devra alors se faire au niveau de l’utilisateur, ce qui est plus contraignant en terme de gestion des accès. Dans notre cas nous avons opté pour une licence de type Premium P1, nous permettant ainsi d’associer des groupes à une application.

Workflow d’identification

Nos API utilisent le workflow de code d’autorisation du protocole OAuth 2.0 (définit ici : OAuth 2.0 RFC 6749, section 4.1) pour authentifier les utilisateurs. Nous nous sommes donc basés sur celui-ci pour migrer notre infrastructure d’identification vers celle d’Azure. Ce workflow se présente de la manière suivante :

L’idée ici est que lors d’une identification de l’utilisateur via le portail d’Azure, le jeton JWT émis à l’étape 9 vers nos API contient la liste des rôles applicatifs définit pour un groupe d’utilisateurs ayant accès à une application. Il sera ainsi plus facile de gérer les droits d’accès aux applications en touchant aux groupes pour ajouter ou retirer des utilisateurs.

Il est temps à présent de nous concentrer sur le paramétrage d’Azure AD.

Création des groupes

Dans un premier temps votre structure Active Directory doit comporter un certain nombre d’utilisateurs et de groupes que nous associerons plus tard aux applications. Vous pouvez simplement créer deux groupes que nous nommerons API Administrators et API Users. Le type de groupe doit être positionné sur Sécurité. Quand au type d’appartenance, celui-ci est à votre convenance mais pour plus de facilité, vous pouvez le laisser sur Affecté.

Puis ajoutez y des comptes utilisateurs (ou le votre). N’hésitez pas à créer des comptes sans licence pour vos tests. En cas de difficulté reportez vous à la documentation Microsoft.

Définition des applications sous Azure

Notre cas pratique concerne un utilisateur se connectant à notre application Web et désireux de consommer des données en provenance de notre Web API. Pour cela il doit obtenir une approbation depuis un fournisseur d’accès, en l’occurrence Microsoft Azure, et fournir un token d’autorisation signé pour venir accéder à notre Web App qui tentera alors d’accéder elle même à l’API avec le dit token contenant les rôles de l’utilisateur. Notre API sera alors en mesure de vérifier l’authenticité du token et appliquer les droits d’accès aux contrôleurs qu’elle expose.

Nous avons donc besoin de déclarer deux applications dans Azure AD :

  • Une Web App par laquelle notre utilisateur va venir s’authentifier
  • Une Web API sécurisée qui sera consommée par notre Web App en fonction des rôles Azure AD de l’utilisateur

Inscription de la Web API

Depuis l’interface d’Azure AD :

  • Cliquez sur Inscriptions d’applications > Nouvelle Inscription
  • Dans le champ Nom ajoutez WebAPI. Vous pouvez bien entendu mettre autre chose mais pour les besoins de notre article nous utiliserons ce libellé.
  • Pour les types de comptes pris en charge cela dépendra de votre besoin. Nous concernant nous voulions limiter l’accès des API à notre organisation, soit la première option.
  • Concernant l’URI de redirection, laissez ce champ vide. Notre API est considérée comme une ressource consommée par notre Web App, la demande de token est donc faite en amont, mais nous y reviendront plus tard.
  • Enfin, cliquez sur le bouton d’inscription.
Inscrire une application dans Azure Active Directory

Ajout des rôles d’application

Ces rôles vont nous permettre d’identifier les types d’accès que nos utilisateurs pourront utiliser pour accéder à notre API. Ils seront associés à des groupes Azure que nous avons définit plus haut pour y ajouter des utilisateurs. Ainsi, on pourra aisément donner les droits d’accès ou les retirer en ajoutant ou dissociant simplement un utilisateur d’un groupe Azure.

L’ajout de groupe à une application n’est pas possible avec une licence gratuite, vous devrez le faire en associant le rôle directement à un utilisateur puis en l’ajoutant à l’application. Il vous faudra opter pour une licence payante de type Premium P1 ou P2 pour avoir cette option. Microsoft propose cependant un essai gratuit de ces licences, libre à vous de vous y adonner.

Pour les besoins de cet article nous allons créer deux rôles : Admin et User.

  • Depuis la fenêtre d’administration de WepAPI, cliquez sur Rôles d’application > Créer un rôle d’application
  • Dans la fenêtre qui s’affiche, dans la zone Nom d’affichage, insérez User access
  • Sélectionnez Utilisateurs/groupes pour Types de membres autorisés
  • Dans le champ Valeur, ajoutez User. Veillez à ne pas laisser d’espace dans le cas d’une valeur différente.
  • Dans le champ Description, mettez le commentaire suivant : User access to REST API
  • Enfin cliquez sur le bouton Appliquer
Ajout d'un rôle d'application

Répétez cette opération en remplaçant le terme User par Admin. Vous aurez ainsi créé les deux rôles applicatif nécessaires à notre Web API.

Ajout d’un scope étendu

Azure AD vous oblige à définir au moins un scope pour donner accès à votre Web API à une autre application. Dans notre cas nous souhaitons légitimement que notre futur Web App puisse être autorisée à accéder à notre actuelle Web API.

Ce ou ces scopes servent également à mettre en place un système de consentement par l’utilisateur pour exploiter des informations qui peuvent être réclamées par la Web API, mais nous n’en avons pas l’utilité ici.

  • Depuis la fenêtre d’administration de WepAPI, cliquez sur Exposer une API > Ajouter une étendue
  • Dans la zone Nom de l’étendue ajoutez User.Read
  • Sélectionnez Administrateurs et utilisateurs pour Qui peut accepter ?
  • Ajoutez Read-only access to user records dans la zone Nom d’affichage du consentement administrateur
  • Ajoutez Allow the application to have read-only access to user records dans la zone Description du consentement administrateur
  • Ajoutez Read-only access to your records dans la zone Nom d’affichage du consentement de l’utilisateur
  • Ajoutez Allow the application to have read-only access to your records dans la zone Description du consentement de l’utilisateur
  • Vérifiez que l’état du scope est bien sur activé
  • Enfin, cliquez sur le bouton Enregistrer
Ajout d'un scope étendu

Dernier point important, vous aurez sans doute remarqué sur cette page le libellé URI ID d’application. Nous allons devoir en définir une, car celle-ci permet d’identifier de manière unique votre application dans les scopes que vous exposez aux autres applications. Par défaut Azure AD vous fournit l’URI suivante : api://<Client_Id>. Il est important de modifier votre URI de manière à ne pas exposer votre ID client. Celle-ci doit simplement être unique au sein de votre organisation pour chaque application que vous enregistrez. Par convention il est utile de l’annoter de cette manière : https://subdomain.organisation.com/votrewebapi, mais ce n’est qu’une suggestion, libre à vous d’organiser votre structure.

Manifeste

L’ensemble des informations de configuration de votre application est stocké dans un manifeste au format JSON que vous pouvez retrouver via l’onglet Manifeste du portail d’administration de l’application. Les modifications que vous apportez au manifeste se répercutent directement dans l’interface d’Azure Active Directory. Le point intéressant ici est le paramètre accessTokenAcceptedVersion positionné soit sur null soit sur 2. D’après la documentation Microsoft :

Deux versions de jetons d’accès sont disponibles dans la plateforme d’identités Microsoft : v1.0 et v2.0. Ces versions régissent les revendications qui se trouvent dans le jeton, garantissant ainsi qu’une API web peut contrôler l’aspect de ses jetons. Les API web ont l’une de ces options sélectionnée par défaut lors de l’inscription : v1.0 pour les applications Azure AD uniquement et v2.0 pour les applications qui prennent en charge les comptes de consommateurs. Cela est contrôlable par les applications avec le paramètre accessTokenAcceptedVersion dans le manifeste de l’application, où null et 1 génèrent des jetons v1.0, et 2 génère des jetons v2.0.

Mais ils oublient également de préciser que si le token est au format v2.0, votre URI ID d’application devient irrémédiablement votre ID client, malgré la déclaration faite dans la page d’exposition de l’API. Faites donc très attention à ce paramètre.

Association des rôles d’applications aux groupes Azure AD

Dernier point important de la configuration de notre Web API, c’est bien entendu l’attribution des groupes ayant droit d’y accéder. Vous avez deux moyens pour vous y rendre.

Le premier consiste à retourner dans l’onglet général (Vue d’ensemble par défaut) de votre organisation puis de sélectionner l’onglet Applications d’entreprise, de rechercher et sélectionner votre application nommée WebAPI dans la liste, puis de cliquer sur l’onglet Utilisateurs et groupes.

La deuxième méthode s’effectue directement depuis la page d’administration de l’application WebAPI depuis laquelle nous avons effectué tous les paramétrages. Depuis l’onglet Vue d’ensemble se trouve un libellé intitulé Application managée dans l’annuaire local. Associé à ce libellé ce trouve un hyperlien nommé WebAPI (ou du nom que vous avez donné à votre application) qui mène lui aussi à la page de gestion contenant l’onglet Utilisateurs et groupes.

Nous partons du postulat que pour suivre cet article vous disposez d’une licence qui vous permet d’ajouter des groupes à une application. Sinon faite abstraction des groupes et lors de l’ajout d’un groupe à une application, ajoutez y simplement un utilisateur et associez lui un rôle.

Procédez à l’ajout d’un groupe en cliquant sur Ajouter un utilisateur/groupe. Dans la fenêtre qui apparaît cliquez sur Utilisateurs et groupes puis recherchez et sélectionnez dans la liste le groupe API Administrators et cliquez sur le bouton Sélectionner.

Cliquez ensuite sur Sélectionner un rôle et choisissez le rôle Administrator access que nous avons définit précédemment.

Enfin cliquez sur le bouton Attribuer et répétez la même chose mais cette fois pour le groupe API Users en veillant à sélectionner le rôle User access.

Inscription de la Web App

Maintenant que nous avons notre Web API d’enregistrée sous Azure AD, nous allons pouvoir définir de la même manière notre Web App. Pour rappel, c’est cette application qui sert de point d’entrée à nos utilisateurs pour obtenir un token d’authentification auprès d’Azure AD.

Procédez de la même manière que pour la Web API (En mettant WebApp comme nom) dans l’inscription de l’application à ceci prêt que cette fois l’URI de redirection doit être remplie. Cette URI est utilisée pour rediriger le token JWT obtenu depuis Azure AD vers la Web App, il est donc important de la spécifier. Elle sert également de référence à Azure pour légitimer la demande de token. Cela fait parti du protocole imposé par les spécifications OAuth 2.0. Pour les besoins de notre article vous pouvez simplement mettre cette valeur pour le moment : https://127.0.0.1

Gestion des autorisations

Dirigez vous maintenant vers l’onglet API autorisées. Nous allons autoriser et accorder les droits nécessaires à notre Web App pour l’accès à d’autres applications et notamment à notre Web API. Pour cela :

  • Cliquez sur Ajouter une autorisation
  • Sélectionnez l’onglet Mes API sur la fenêtre venant d’apparaître
  • Sélectionnez WebAPI dans la liste
  • Cochez l’autorisation User.Read
  • Cliquez sur Ajouter des autorisations

Par défaut, des droits sont déjà accordés sur l’API Microsoft Graph permettant l’accès au profil de l’utilisateur connecté. Ne le supprimez pas, c’est une information nécessaire à l’émission du token.

Vous devez à présent accorder un consentement d’administration pour les droits que vous venez d’ajouter. Cela évitera d’activer une fenêtre supplémentaire à l’utilisateur demandant un consentement administratif pour accéder aux API.

  • Cliquez sur Accorder un consentement d’administrateur pour <votre organisation>
  • Cliquez sur Oui

Tous les droit seront marqués d’une coche indiquant le consentement accordé pour l’organisation.

Ajout d’une clé secrète

Afin d’établir un terrain de confiance entre la Web App et Azure AD, nous devons générer une clé secrète qui sera à fournir par la Web App lors de la demande du token d’autorisation. Pour cela rendez vous dans l’onglet Certificats & secrets et cliquez sur le bouton Nouveau secret client.

  • Dans la zone Description ajoutez le texte suivant : Used to obtain the access token
  • Pour la Date d’expiration, sélectionnez Jamais

Une fois la clé ajoutée, pensez à la copier, car elle ne sera visible que durant une période très courte.

Ajout de groupes ou d’utilisateurs

Tout comme pour notre API Web, nous devons associer des utilisateurs à notre application. Procédez de la même manière que pour WebApi sans forcément ajouter de rôle applicatif, un rôle de type Default Access sera attribué au groupe d’utilisateurs ou à l’utilisateur ajouté.

Conclusion

Avec les éléments que nous avons paramétrés dans Azure, le token d’accès émis par la plateforme devrait maintenant contenir un attribut listant les rôles applicatifs de l’utilisateur et transmis à nos API. Celui-ci sera décortiqué par les API pour vérifier qu’ils correspondent bien aux rôles donnant accès aux routes exposées.

Dans cet article nous avons vu :

  • L’inscription et la configuration d’applications de type Web App / Web API sur la plateforme Azure Active Directory
  • L’ajout de rôles applicatifs à des groupes Azure AD ayant accès à une application

Aller plus loin

Vous savez à présent configurer Azure pour inclure des rôles applicatifs. L’étape suivante consisterait à voir de quelles manières ces informations peuvent être utilisées auprès d’API Web.

Je vous invite de ce pas à consulter les articles suivants :

Ressources


0 commentaire

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Configurer des rôles aux groupes d’Azure Active Directory (Micr…

par Cyrille P. temps de lecture : 10 min
0