Les identités applicatives dans Azure Active Directory

Microsoft, via Azure Active Directory, propose une plateforme d’identité robuste. Azure Active Directory (aka Azure AD) assure la gestion des identités de votre tenant Azure. Outre les identités de type utilisateurs, Azure AD centralise également les identités applicatives. Dans mon expérience, ces identités applicatives sont surtout utiles pour sécuriser les échanges d’informations entre applications ou microservices. Cependant, entre les notions de “Managed Identity”, d’“App Registration”, d’“Enterprise Application” ou encore de “Service Principal”, le paysage est nébuleux pour bon nombre de développeurs. Dans cet article, je propose un petit tour d’horizon de ces différentes notions.

Authentification et autorisations

App Registration

La toute première chose à retenir d’une App Registration, c’est qu’elle est globalement unique. Une App Registration est une représentation unique de l’identité d’une application à l’échelle de la planète. De plus, elle offre différentes fonctionnalités :

• Contrôler quel type de compte accède à l’application (compte de travail ou scolaire, personnel)
• Contrôler quel tenant est autorisé à utiliser l’application (tenant local ou multi-tenant)
• Gérer la redirection sur les applications web (redirect URI) lors de l’authentification
• Gérer des certificats et des secrets
• Exposer des API
• Gérer/définir des permissions

L’App Registration est indispensable dès lors que vous souhaitez sécuriser les échanges avec l’extérieur. Par exemple, si vous exposez des API pour des partenaires, il vous faudra à minima 2 App Registrations :

• 1 App Registration qui représentera les API
• 1 App Registration pour chaque client qui utilise les API

Avec les App Registration, vous pouvez répondre à différents flow OAuth (par exemple Client Credentials ou Authorization Code). Notez cependant que vous devez gérer l’expiration des secrets par vos propres moyens. Cela peut vite devenir fastidieux si vous souhaitez généraliser OAuth pour les échanges entre vos composants.

Entreprise Application (EA) et Service Principal (SP)

Contrairement à l’App Registration et sa notion d’identité globale, l’Enterprise Application est une identité locale. Elle n’est définie que de votre tenant. Il n’y a pas de différence technique entre un Service Principal et une Enterprise Application, seulement une connotation :

Ainsi, par usage, une Enterprise Application désigne la représentation (ou instanciation) locale d’une application dans votre tenant. Par exemple, pour chaque App Registration que vous avez instanciée, une Enterprise Application existe dans votre tenant. Ou encore, lorsque vous ajoutez une application externe (Facebook, Netflix…) à votre tenant, en fait, vous réalisez une instanciation locale de l’identité dans votre tenant.

Identités Managées

Une Identité Managée est une identité gérée par Azure. C’est une identité de type Enterprise Application avec la particularité d’être associée à un service Azure (Logic Apps, Data Factory, Azure Function…). L’identité managée répond à 2 problématiques principales :

• Le renouvellement des secrets : il est assuré par la plateforme et est complètement transparent pour nous. D’ailleurs, à ma connaissance, vous ne pouvez pas récupérer le secret d’une identité managée.
• Le stockage du secret originel : pour comprendre ce point, il faut imaginer que vous avez besoin de stocker une donnée sensible (par exemple un mot de passe) pour une utilisation ultérieure. Pour sécuriser ce stockage, vous utiliserez probablement un Azure Key Vault. Au moment où vous aurez besoin de lire ce mot de passe, il vous faudra fournir un client/secret pour vous authentifier auprès du service Azure Key Vault. Mais où est-ce que vous stockez ce secret qui vous permet d’accéder au Key Vault ? C’est le serpent qui se mord la queue, ou la boucle infinie. C’est là que les identités managées sont essentielles. Vous n’avez pas besoin de stocker ce secret puisqu’il est géré par la plateforme.

Notez qu’il existe 2 types d’identités managées : System Assigned ou User Assigned. La première est générée par la plateforme Azure et assignée à un service. La seconde est générée par un utilisateur puis associée à un ou plusieurs services Azure.