La sécurité applicative s’arrête rarement à l’authentification. Que l’on parle de « rôle », de « profil », etc., nous avons toujours besoin de distinguer des populations d’utilisateurs. Et tout comme l’authentification, cette gestion est particulièrement sensible : la moindre erreur pourrait donner des privilèges à un compte qui ne devrait pas en avoir. C’est aussi pour cette raison que déléguer la gestion des rôles est tout aussi importante que déléguer l’authentification.

L’autre intérêt de déléguer la gestion des rôles à Azure AD est la possibilité de séparer deux activités que l’on retrouve dans chaque outil de gestion de rôles :

  • La définition et application des rôles : généralement l’équipe de développement ;
  • L’assignation des rôles : généralement les administrateurs de l’application.

gestion des roles utilisateurs Azure AD

Dans Azure AD, les rôles sont définis dans le manifeste de l’application. Il est maintenant possible de le faire sur le portail Azure sans avoir à manipuler le manifeste.

⚠️ Je vous conseille malgré tout de vous familiariser avec le manifeste si vous souhaitez vous en servir lors du déploiement de votre application : cela vous évitera d’avoir à le réécrire !

 

Manisfeste Azure AD

 

Une fois ces rôles définis au niveau de l’application, ils devront être assignés à des identités dans le service principal par les administrateurs de l’Azure AD.

Azure AD assignation service principal

 

Prenons une application Azure AD de type MVC et voyons comment cela se représente coté code. J’utilise le template Asp.net MVC avec .Net 5 (qui utilise la bibliothèque Microsoft.Identity.Web).

template Asp.net MVC avec .Net 5

 

Une fois l’authentification configurée (pour plus de détails, consulter notre article sur le flow authorization code), voici ce que je retrouve dans les claims :

 

affichage claims Azure AD rôle

 

Comme on peut le constater, les rôles apparaissent maintenant dans les « claims ». Si j’avais été assigné à plusieurs rôles, ils auraient été tous présents dans la liste.

ASP.Net MVC fournit naturellement un ensemble de mécanismes permettant de lire ces claims et de vérifier si les actions de nos contrôleurs peuvent être appelées pour nos rôles via l’attribut « Authorise » :

Voici la page privacy avec l’ID de mon rôle :

 

Azure ID privacy role

 

Et voici ce qui s’affiche lorsque je change l’ID du rôle :

 

Azure AD privacy access denied

 

Pour aller plus loin

Nous arrivons à la fin de ce Mois de l’Identité : nous espérons que cette série d’articles vous aura été utile et vous permettra de devenir un expert de la gestion des identités !

Pour terminer, nous vous proposons de mettre en pratique tous les principes d’authentification nécessaires pour obtenir une gestion sécurisée des identités en visualisant le replay de notre webinaire spécial identité. 

 

Azure AD par la pratique