Configurer des rôles aux groupes d’Azure Active Directory (Microsoft 365) pour l’accès aux applications

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

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.

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.

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

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

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 :

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.

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 :

• Utiliser les rôles d’Azure Active Directory avec une Web API sous Spring Boot pour authentifier les utilisateurs
• Développer et déployer une application Web (Vue.js + Java) sous Docker avec une authentification sous Azure

Ressources

• Comment créer un compte Azure gratuit : https://docs.microsoft.com/fr-fr/azure/active-directory/develop/quickstart-create-new-tenant
• Documentation Azure AD pour la création des groupes : https://docs.microsoft.com/fr-fr/azure/active-directory/fundamentals/active-directory-groups-create-azure-portal