Explorer les principaux de service

Effectué

Pour déléguer des fonctions de gestion des identités et des accès à Microsoft Entra ID, une application doit être inscrite auprès d’un locataire Microsoft Entra. Lorsque vous inscrivez votre application auprès de Microsoft Entra ID, vous créez une configuration d’identité pour votre application, ce qui lui permet de s’intégrer à Microsoft Entra ID. Lorsque vous inscrivez une application dans le portail Azure, vous choisissez qu’elle soit :

  • Monolocataire : uniquement accessible dans votre locataire
  • Multilocataire : accessible dans d’autres locataires

Si vous inscrivez une application dans le portail, un objet application (l’instance globale unique de l’application) et un objet principal de service sont automatiquement créés dans votre locataire d’accueil. Vous disposez également d’un ID global unique pour votre application (l’ID de l’application ou du client). Dans le portail, vous pouvez ensuite ajouter des secrets ou des certificats, ainsi que des étendues pour que votre application fonctionne, personnaliser votre application dans la boîte de dialogue de connexion, et bien plus.

Notes

Vous pouvez également créer des objets principal de service dans un locataire à l’aide d’Azure PowerShell, d’Azure CLI, de Microsoft Graph et d’autres outils.

Objet application

Une application Microsoft Entra est limitée à son unique objet d’application. L’objet application réside dans le locataire Microsoft Entra dans lequel l’application a été inscrite (connu sous le nom de locataire « de base » de l’application). Un objet application est utilisé en tant que modèle ou blueprint pour créer un ou plusieurs objets principal de service. Un principal de service est créé dans chaque locataire dans lequel l’application est utilisée. À l’image d’une classe en programmation orientée objet, l’objet d’application a des propriétés statiques qui sont appliquées à tous les principaux de service créés (ou instances d’application).

L’objet application décrit trois aspects d’une application :

  • Comment le service peut émettre des jetons pour pouvoir accéder à l’application.
  • Les ressources auxquelles l’application peut avoir besoin d’accéder.
  • Actions que l’application peut effectuer.

L’entité Application de Microsoft Graph définit le schéma pour les propriétés d’un objet d’application.

Objet principal du service

Toute entité qui nécessite l’accès aux ressources sécurisées par un locataire Microsoft Entra doit être représentée par un principal de sécurité. Ceci est valable aussi bien pour les utilisateurs (principal d’utilisateur) que pour les applications (principal de service).

Le principal de sécurité définit la stratégie d’accès et les autorisations pour l’utilisateur ou l’application du locataire Microsoft Entra. Cela rend possibles les fonctionnalités de base, telles que l’authentification de l’application ou de l’utilisateur lors de la connexion, et l’autorisation lors de l’accès aux ressources.

Il existe trois types de principal de service :

  • Application : le type de principal de service est la représentation locale, ou instance d’application, d’un objet d’application global dans un seul locataire ou annuaire. Un principal de service est créé dans chaque locataire dans lequel l’application est utilisée et fait référence à l’objet application global unique. L’objet principal de service définit ce que l’application peut réellement faire dans le locataire spécifique, qui peut accéder à l’application, ainsi que les ressources auxquelles l’application peut accéder.

  • Identité managée : ce type de principal de service est utilisé pour représenter une identité managée. Les identités gérées fournissent une identité que les applications peuvent utiliser lors de la connexion à des ressources prenant en charge l’authentification Microsoft Entra. Lorsqu’une identité managée est activée, un principal de service représentant cette identité managée est créé dans votre locataire. Les principaux de service représentant des identités managées peuvent se voir accorder des accès et des autorisations, mais ne peuvent pas être mis à jour ni modifiés directement.

  • Hérité : ce type de principal de service représente une application héritée, à savoir une application créée avant l’introduction d’inscriptions d’applications ou la création d’une application par le biais d’expériences héritées. Un principal de service hérité peut avoir :

    • credentials
    • des noms des principal de service
    • des URL de réponse
    • et d’autres propriétés qu’un utilisateur autorisé peut modifier, mais sans avoir une inscription d’application associée.

Relation entre les objets application et les principaux de service

L’objet application est la représentation globale de votre application à l’usage de tous les locataires, et le principal de service est la représentation locale de l’application à l’usage d’un locataire spécifique. L’objet application fait office de modèle à partir duquel les propriétés communes et par défaut sont dérivées pour une utilisation visant à créer des objets de principal de service correspondants.

Un objet application a :

  • Une relation un-à-un avec l’application logicielle et
  • Une relation un-à-plusieurs avec ses objets de principal de service correspondants.

Un principal de service doit être créé dans chaque locataire sur lequel l’application est utilisée pour établir une identité pour la connexion et/ou l’accès aux ressources sécurisées par le locataire. Une application à locataire unique n’a qu’un seul principal de service (dans son locataire de base), créé et pouvant être utilisé pendant l’inscription de l’application. Une application multilocataire a également un principal de service créé dans chaque locataire où un utilisateur de ce locataire a consenti à son utilisation.