Planifier votre stratégie d’inscription d’application métier

  • 2 minutes

Cette unité explique pourquoi les applications s’intègrent à Microsoft Entra ID. Ajoutez des applications à Microsoft Entra ID pour appliquer un ou plusieurs des services qu'il fournit, notamment :

  • L’authentification et l’autorisation de l’application.
  • L’authentification et l’autorisation de l’utilisateur.
  • L’authentification unique (SSO) à 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 : 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 du schéma d'annuaire : Élargissez le schéma des objets « principal de service » et « utilisateur » pour stocker des données supplémentaires dans Microsoft Entra ID.

Il existe deux représentations d'applications dans Microsoft Entra ID : les objets d'application et les principaux de service. Les deux sections suivantes expliquent ces représentations, ainsi que la façon dont elles interagissent les unes avec les autres dans le Portail Azure.

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

Vous pouvez gérer des objets d’application dans le portail Azure via Inscriptions d’application. Les objets d’application définissent et décrivent l’application à Microsoft Entra ID, ce qui permet à votre fournisseur d’identité 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 multilocataire prenant en charge des principaux de service dans d’autres répertoires. L’objet d’application inclut les éléments suivants (ainsi que d’autres informations non mentionnées ici) :

  • 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 (RBAC)
  • Configuration et métadonnées de l’authentification unique
  • Configuration et métadonnées du déploiement de l'utilisateur
  • Configuration et métadonnées du proxy

Vous pouvez créer des objets d’application par le biais de plusieurs chemins d’opérations, notamment :

  • Via les inscriptions d’application dans le portail Azure.
  • Créer une nouvelle application à l'aide de Visual Studio et la configurer 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.
  • De nombreuses autres voies, y compris diverses expériences de développeur dans Azure et des expériences d'explorateur d'API dans les centres de développeurs.

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

Vous pouvez gérer les principaux de service dans le portail Azure via les Applications d’entreprise. Les principaux services régissent une application qui se connecte à Microsoft Entra ID et peuvent être considérés comme l'instance de l'application dans votre répertoire. 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.

Comme les objets d’application, les principaux de service peuvent être créés via plusieurs chemins d’accès, 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 se connectent aux services en ligne de Microsoft comme Microsoft 365.

    • Lorsque vous vous abonnez à Microsoft 365 ou commencez une version d’évaluation, un ou plusieurs principaux de service sont créés dans l’annuaire représentant les différents services qui sont utilisés pour transmettre toutes les fonctionnalités associées à Microsoft 365.
    • Certains services de Microsoft 365 tels que SharePoint créent des principaux de service sur une base continue, afin de sécuriser les communications 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).

  • Ajoutez une application pour utiliser le proxy d’application 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 répertoire de départ, qui est référencé par un ou plusieurs principaux de service dans chacun des répertoires où elle s’exécute (y compris le répertoire de démarrage de l’application).

Diagram of the relationship between app objects and service principals.

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 (répertoire de la galerie d’applications).

Les fournisseurs/éditeurs d'applications qui s'intègrent à Microsoft Entra ID doivent avoir un répertoire de publication (représenté à droite en tant que « Répertoire SaaS »).

Les applications que vous ajoutez (représentées en tant que « (vos) applications » dans le schéma) incluent :

  • Les applications que vous avez développées (intégrées à Microsoft Entra ID).
  • Les applications que vous avez connectées pour l’authentification unique.
  • Les applications que vous avez publiées en utilisant le proxy d’application Microsoft Entra.

Remarques et exceptions aux principaux de service

Tous les principaux de service ne pointent pas vers un objet d’application. Lors de la création de Microsoft Entra ID, les services fournis aux applications étaient plus limités et le principal de service suffisait à établir l'identité d'une 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, sans créer en premier 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 :

  • Application
  • Principal de service

Ajout d’une nouvelle inscription d’application

Diagram of the relationship between app objects and service principals, focusing on process flow.

Flux du processus du diagramme

  1. L’utilisateur demande à inscrire une application : un jeton de demande est émis.
  2. Le point de terminaison d’autorisation renvoie une authentification.
  3. L’utilisateur consent à ce que l’application soit inscrite.
  4. Le service est créé à partir de l’application
  5. Le jeton est retourné à l’utilisateur.

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

Bien qu’il existe certaines tâches que seuls les administrateurs généraux peuvent effectuer par défaut (par exemple, l’ajout d’applications à partir de la galerie d’applications et la configuration d’une application pour utiliser le proxy d’application), vous pouvez également attribuer des rôles comme Administrateur d’application et Administrateur d’application cloud pour effectuer ces tâches. Vous devez vous rappeler que, par défaut, tous les utilisateurs de votre annuaire ont des droits pour enregistrer les objets d’application qu’ils développent, et qu’ils ont la possibilité de décider des applications qu’ils partagent/auxquelles ils donnent accès à leurs données organisationnelles par le biais du consentement. Lorsque le premier utilisateur de votre annuaire se connecte à une application, et donne son consentement, cela crée un principal de service. 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 points suivants :

  • Les applications sont capables de tirer parti de 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 les services de fédération Active Directory (AD FS), un administrateur a probablement dû ajouter une application en tant que partie de confiance pour le compte de ses développeurs. Maintenant, les développeurs peuvent se déployer eux-mêmes (libre-service).
  • 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.
  • Lorsqu’un utilisateur ajoute ou autorise une application à accéder à ses données, l’événement peut être audité. Vous pouvez afficher les rapports d’audit dans le Portail Azure pour déterminer la façon dont 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, deux paramètres vous permettent de désactiver ces capacités :

Pour empêcher les utilisateurs de donner leur consentement pour leur propre compte :

  • Dans le portail Azure, accédez à la section Paramètres utilisateur sous Applications d’entreprise.

  • Définissez le paramètre Les utilisateurs peuvent autoriser les applications à accéder aux données de l’entreprise en leur nom sur Non.

    Notes

    Si vous décidez de désactiver le consentement de l’utilisateur, un administrateur devra donner son consentement pour chaque nouvelle application qu’un utilisateur utilisera.

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

  • Dans le portail Azure, accédez à la section Paramètres utilisateur sous Microsoft Entra ID.
  • Définissez le paramètre Les utilisateurs peuvent inscrire des applications sur Non.

Location dans Microsoft Entra ID

Microsoft Entra organise des objets comme des utilisateurs et des applications dans des groupes appelés tenants. Les locataires permettent à un administrateur de définir des stratégies sur les utilisateurs au sein de l’organisation et les applications appartenant à l’organisation pour répondre à leurs stratégies de sécurité et opérationnelles.

Qui peut accéder à votre application ?

Lorsqu’il s’agit de développer des applications, les développeurs peuvent choisir de configurer leur application pour être monolocataire ou multilocataire lors de l’inscription d’application dans le portail Microsoft Azure.

  • Les applications mono-locataires ne sont disponibles que dans le locataire dans lequel elles ont été inscrites, également appelé leur locataire de base.
  • Les applications multilocataires sont à la disposition des utilisateurs dans leur tenant de base et d’autres tenants.

Dans le Portail Azure, vous pouvez configurer votre application pour qu’elle soit unique ou multilocataire en définissant l’audience comme suit :

*Accès à des applications spécifiques

Audience Monolocataire/multilocataire Qui peut se connecter
Comptes dans cet annuaire uniquement Locataire unique Tous les comptes d’utilisateur et d’invité dans votre annuaire peuvent utiliser votre application ou API. Utilisez cette option si votre audience cible est interne à votre organisation.
Comptes dans n’importe quel répertoire Microsoft Entra Multi-locataire Tous les utilisateurs et invités avec un compte professionnel ou scolaire Microsoft peuvent utiliser votre application ou API. Cela inclut les établissements scolaires et les entreprises qui utilisent Microsoft 365. Utilisez cette option si votre audience cible est constituée de clients d’entreprise ou du secteur éducatif.
Comptes dans n’importe quel répertoire Microsoft Entra et des comptes Microsoft personnels (tels que Skype, Xbox, Outlook.com) Multi-locataire Tous les utilisateurs avec un compte professionnel, scolaire, ou personnel Microsoft, peuvent utiliser votre application ou API. Cela inclut les établissements scolaires et les entreprises qui utilisent Microsoft 365, ainsi que les comptes personnels utilisés pour se connecter à des services tels que Xbox et Skype. Utilisez cette option pour cibler l’ensemble plus large de comptes Microsoft.

Meilleures pratiques pour les applications multilocataires

La création d’excellentes applications multilocataires peut s’avérer difficile en raison du nombre de stratégies différentes que les administrateurs informatiques peuvent définir dans leurs tenants. Si vous choisissez de créer une application multilocataire, suivez ces meilleures pratiques :

  • Testez votre application dans un locataire dans lequel des stratégies d’accès conditionnel sont configurées.
  • Suivez le principe de moindre accès utilisateur pour vous assurer que votre application demande uniquement des autorisations dont elle a réellement besoin.
  • Fournissez les noms et descriptions appropriés de toutes les autorisations que vous exposez dans le cadre de votre application. Cela permet aux utilisateurs et administrateurs de savoir ce qu’ils sont autorisés à faire quand ils tentent d’utiliser les API de votre application. Pour plus d’informations, consultez la section des meilleures pratiques dans le guide des autorisations.