Partager via


Comment et pourquoi les applications sont ajoutées à Microsoft Entra ID

Il existe deux représentations d’applications dans Microsoft Entra ID :

  • Les objets d’application : bien qu’il existe des exceptions, les objets d’application peuvent être considérés comme la définition d’une application.
  • Les principaux de service : ils peuvent être considérés comme une instance d’une application. En règle générale, les principaux de service référencent un objet d’application, et un objet d’application peut être référencé par plusieurs principaux de service sur plusieurs annuaires.

À quoi correspondent les objets d’application et d’où viennent-ils ?

Vous pouvez gérer des objets d’application dans le centre d’administration Microsoft Entra via l’expérience Inscriptions d’applications. Les objets d’application décrivent l’application à Microsoft Entra ID et peuvent être considérés comme la définition de l’application. Ils permettent au service de savoir comment émettre des jetons pour l’application, en fonction de ses paramètres. L’objet d’application existe uniquement dans son répertoire de base, même s’il s’agit d’une application mutualisée prenant en charge des principaux de service dans d’autres répertoires. L’objet application peut inclure (mais sans s’y limiter) l’un des éléments suivants :

  • Nom, logo et éditeur
  • URI de redirection
  • Secrets (clés symétriques et/ou asymétriques utilisées pour authentifier l’application)
  • Dépendances d’API (OAuth)
  • API/ressources/étendues publiées (OAuth)
  • Rôles d'application
  • Métadonnées et configuration de l’authentification unique (SSO)
  • Configuration et métadonnées du déploiement de l'utilisateur
  • Configuration et métadonnées du proxy

Les objets d’application peuvent être créés via plusieurs méthodes, notamment :

  • Inscriptions d’applications dans le centre d’administration Microsoft Entra
  • Via la création d’une application à l’aide de Visual Studio et la configuration de celle-ci pour utiliser l’authentification Microsoft Entra
  • Lorsqu’un administrateur ajoute une application à partir de la galerie d’applications (ce qui crée également un principal de service)
  • En utilisant l’API Microsoft Graph ou PowerShell pour créer une application
  • Via beaucoup d’autres méthodes, notamment les différentes expériences de développement dans Azure et les expériences d’explorateur d’API dans tous les centres de développement

À quoi correspondent les principaux de service et d’où proviennent-ils ?

Vous pouvez gérer les principaux de service dans le centre d’administration Microsoft Entra via l’expérience Applications d’entreprise. Ce sont les principaux de service qui gouvernent une application se connectant à Microsoft Entra ID, et ils peuvent être considérés comme l’instance de l’application dans votre répertoire. Pour toute application donnée, le principal de service peut avoir au maximum un objet d’application (qui est inscrit dans un annuaire de base) et un ou plusieurs objets de principal de service représentant les instances de l’application dans tous les annuaires dans lesquels il agit.

Le principal de service peut inclure :

  • Une référence à un objet d’application via la propriété d’ID d’application
  • Des enregistrements des attributions de rôle de l’application de l’utilisateur local et du groupe
  • Des enregistrements des autorisations de l’utilisateur local et de l’administrateur accordées à l’application
    • Par exemple : autorisation pour l’application d’accéder à un e-mail d’utilisateur particulier
  • Des enregistrements des stratégies locales, y compris une stratégie d’accès conditionnel
  • Des enregistrements des paramètres locaux alternatifs pour une application
    • Revendication des règles de transformation
    • Mappages d'attributs (déploiement de l'utilisateur)
    • Rôles d’application spécifiques de l’annuaire (si l’application prend en charge les rôles personnalisés)
    • Logo ou nom spécifique de l’annuaire

À l’instar des objets d’application, les principaux de service peuvent être créés via plusieurs méthodes, notamment :

  • Lorsque les utilisateurs se connectent à une application tierce intégrée à Microsoft Entra ID
    • Lors de la connexion, les utilisateurs sont invités à autoriser l’application à accéder à leur profil et à effectuer d’autres actions. Dès que la première personne donne son consentement, le principal de service représentant l’application est ajouté à l’annuaire.
  • Lorsque les utilisateurs utilisent ou se connectent à des services en ligne Microsoft tels que Microsoft 365, Microsoft Entra ID ou Microsoft Azure.
    • Lorsque vous utilisez pour la première fois un service Microsoft, un ou plusieurs principaux de service peuvent être créés dans l’annuaire représentant les différentes identités de service Microsoft utilisées pour fournir le service. Cet approvisionnement « juste-à-temps » peut se produire à tout moment, souvent dans le cadre d’un processus en arrière-plan. Dans de rares cas, le principal de service Microsoft créé peut également être affecté à un rôle d’annuaire, tel que « Lecteurs de répertoire ».
    • Certains services Microsoft, comme SharePoint Online, créent en permanence des principaux de service pour permettre une communication sécurisée entre les composants, y compris les flux de travail.
  • Lorsqu’un administrateur ajoute une application à partir de la galerie d’applications (cette opération crée également un objet d’application sous-jacent)
  • Lors de l’ajout d’une application pour utiliser le proxy d’application de Microsoft Entra
  • Connectez une application pour l’authentification unique à l’aide de SAML ou de l’authentification unique par mot de passe
  • Par programmation via l’API Microsoft Graph ou PowerShell

Une application possède un objet d’application dans son annuaire de base qui est référencé par un ou plusieurs principaux de service dans chacun des annuaires où il opère (y compris l’annuaire de base de l’application).

Illustre la relation entre les objets d’application et les principaux de service

Dans le schéma ci-dessus, Microsoft gère deux annuaires en interne (représentés à gauche), qu’il utilise pour publier des applications :

  • Une pour Microsoft Apps (annuaire de services Microsoft)
  • Un pour des applications tierces préintégrées (annuaire de la galerie d’applications)

Les fournisseurs/éditeurs d’applications qui s’intègrent à Microsoft Entra ID doivent avoir un annuaire de publication (représenté à droite en tant que « Annuaire SaaS (Software as a service) » ).

Les applications que vous ajoutez vous-même (représentées en tant que (Vos) applications dans le schéma) incluent :

  • Applications que vous avez développées (intégrées à Microsoft Entra ID)
  • Les applications que vous avez connectées pour l’authentification unique
  • Applications que vous avez publiées à l’aide du proxy d’application de Microsoft Entra

Remarques et exceptions

  • Tous les principaux de service ne pointent pas vers un objet d’application. Lorsque Microsoft Entra ID a été créé, les services fournis aux applications étaient alors plus limités et le principal de service était suffisant pour établir une identité d’application. Le principal du service d'origine était plus proche en termes de forme du compte de service Windows Server Active Directory. Pour cette raison, il est toujours possible de créer des principaux de service via diverses méthodes, telles que l’utilisation de PowerShell Microsoft Graph, sans d’abord créer un objet d’application. L’API Microsoft Graph requiert un objet d’application avant de pouvoir créer un principal de service.
  • Actuellement, toutes les informations décrites ci-dessus sont exposées par programmation. Les éléments suivants sont uniquement disponibles dans l'interface utilisateur :
    • Revendication des règles de transformation
    • Mappages d'attributs (déploiement de l'utilisateur)
  • Pour plus d’informations détaillées sur le principal de service et les objets d’application, consultez la documentation de référence sur l’API Microsoft Graph :

Pourquoi les applications s’intègrent-elles à Microsoft Entra ID ?

Les applications sont ajoutées à Microsoft Entra ID pour utiliser un ou plusieurs des services proposés par Microsoft Entra ID, notamment :

  • L’authentification et l’autorisation de l’application
  • L'authentification et l'autorisation de l'utilisateur
  • L'authentification unique à l'aide de la fédération ou du mot de passe
  • La configuration et la synchronisation de l’utilisateur
  • Le contrôle d’accès basé sur les rôles (RBAC) : utilisez le répertoire pour définir les rôles d’application, afin d’effectuer des vérifications d’autorisation basées sur les rôles dans une application
  • Les services d’autorisation OAuth : utilisés par Microsoft 365 et d’autres applications Microsoft pour autoriser l’accès aux API/ressources
  • La publication et le proxy d’applications : publiez une application sur Internet à partir d’un réseau privé
  • Attributs d’extension de schéma d’annuaire : étendre le schéma du principal du service et des objets utilisateur pour stocker des données supplémentaires dans Microsoft Entra ID

Qui a l'autorisation d'ajouter des applications à mon instance Microsoft Entra ?

Par défaut, tous les utilisateurs de votre annuaire disposent des droits d’inscrire des objets d’application qu’ils développent et de la discrétion de choisir les applications qu’ils partagent ou auxquelles ils donnent l’accès à leurs données organisationnelles par le biais du consentement. Si une personne est le premier utilisateur de votre annuaire à se connecter à une application et à donner son consentement, un principal de service sera créé dans votre locataire. Sinon, les informations d’octroi de consentement sont stockées sur le principal de service existant.

Permettre aux utilisateurs d’inscrire des applications et de donner leur consentement peut, à première vue, sembler inquiétant, mais n’oubliez pas les raisons suivantes :

  • Les applications sont capables d’utiliser Windows Server Active Directory pour l’authentification utilisateur depuis de nombreuses années sans que l’application ait besoin d’être inscrite ou enregistrée dans l’annuaire. Désormais, l’organisation disposera d’une visibilité améliorée sur le nombre précis d’applications qui utilisent l’annuaire, et pour quelles raisons.
  • La délégation de ces responsabilités aux utilisateurs supprime le besoin d’avoir un processus de publication et d’inscription des applications piloté par un administrateur. Avec Active Directory Federation Services (ADFS), il était probable que l’administrateur doive ajouter une application en tant que partie de confiance pour le compte de ses développeurs. Les développeurs sont désormais libres.
  • La connexion des utilisateurs à des applications à l’aide de leur compte d’organisation à des fins professionnelles est un point positif. Par la suite, s’ils quittent l’organisation, ils perdront automatiquement l’accès au compte qu’ils utilisaient pour cette application.
  • Il est bon de disposer d'un enregistrement permettant de savoir avec quelle application les données ont été partagées. Les données sont plus que jamais transportables, et il est utile de disposer d’un enregistrement précisant qui a partagé quelles données, et à l’aide de quelles applications.
  • Les propriétaires d’API qui utilisent Microsoft Entra ID pour OAuth décident en détail des autorisations que les utilisateurs sont en mesure d’accorder aux applications et des autorisations nécessitant un administrateur pour les confirmer. Seuls les administrateurs peuvent donner leur consentement pour des étendues plus larges et des autorisations plus importantes. Le consentement de l’utilisateur se limite aux propres fonctionnalités et données de celui-ci.
  • Quand un utilisateur ajoute ou autorise une application à accéder à ses données, l’événement peut être audité afin que vous puissiez afficher les rapports d’audit dans le centre d’administration Microsoft Entra et ainsi déterminer de quelle façon une application a été ajoutée à l’annuaire.

Si vous souhaitez toujours empêcher les utilisateurs de votre annuaire d’inscrire des applications et de se connecter à des applications sans l’approbation d’un administrateur, vous avez la possibilité de modifier deux paramètres :

  • Pour changer les paramètres de consentement utilisateur dans votre organisation, consultez Configurer la façon dont les utilisateurs donnent leur consentement aux applications.

  • Pour empêcher les utilisateurs d’inscrire leurs propres applications :

    1. Dans le centre d’administration Microsoft Entra, accédez à Identité>Utilisateurs>Paramètres d’utilisateur.
    2. Définissez le paramètre Les utilisateurs peuvent inscrire des applications sur Non.