Partager via

Intégration d’applications à Microsoft Entra ID et établissement d’une base de référence d’accès révisé

  • Article

Une fois que vous avez établi les stratégies précisant qui doit avoir accès à une application, vous pouvez connecter votre application à Microsoft Entra ID puis déployer les stratégies pour en régir l’accès.

La gouvernance Microsoft Entra ID peut être intégrée à de nombreuses applications, notamment des applications connues telles que SAP R/3, SAP S/4HANA,et celles qui utilisent des normes telles que OpenID Connect, SAML, SCIM, SQL, LDAP, SOAP et REST. Grâce à ces normes, vous pouvez utiliser Microsoft Entra ID avec de nombreuses applications SaaS populaires et applications locales, y compris les applications développées par votre organisation. Ce plan de déploiement explique comment connecter votre application à Microsoft Entra ID et activer les fonctionnalités de gouvernance des identités à utiliser pour cette application.

Pour que Microsoft Entra ID Governance puisse être utilisé pour une application, celle-ci doit d’abord être intégrée à Microsoft Entra ID et représentée dans votre annuaire. Lorsque l’application est intégrée à Microsoft Entra ID, cela signifie qu’une de ces deux exigences doit être remplie :

  • L’application s’appuie sur Microsoft Entra ID pour l’authentification unique fédérée et Microsoft Entra ID contrôle l’émission de jeton d’authentification. Si Microsoft Entra ID est le seul fournisseur d’identité pour l’application, seuls les utilisateurs qui sont affectés à l’un des rôles de l’application dans Microsoft Entra ID peuvent se connecter à l’application. Les utilisateurs qui perdent leur attribution de rôle d’application ne peuvent plus obtenir de nouveau jeton pour se connecter à l’application.
  • L’application s’appuie sur des listes d’utilisateurs ou de groupes fournies à l’application par Microsoft Entra ID. Cette exigence peut être satisfaite à l’aide d’un protocole de provisionnement tel que SCIM, par l’application interrogeant Microsoft Entra ID par le biais de Microsoft Graph ou par l’application utilisant AD Kerberos pour obtenir les appartenances aux groupes d’un utilisateur.

Si aucun de ces critères n’est respecté pour une application, par exemple lorsque l’application ne s’appuie pas sur Microsoft Entra ID, la gouvernance des identités peut quand même être utilisée. Toutefois, il peut y avoir certaines limitations applicables à l’utilisation de la gouvernance des identités sans répondre aux critères. Par exemple, les utilisateurs qui ne figurent pas dans votre annuaire Microsoft Entra ID ou qui ne sont pas affectés aux rôles d’application dans Microsoft Entra ID ne seront pas inclus dans les révisions d’accès de l’application tant que vous ne les aurez pas affectés aux rôles d’application. Pour plus d’informations, consultez Préparation d’une révision d’accès de l’accès des utilisateurs à une application.

Intégrer l’application à Microsoft Entra ID pour garantir que seuls les utilisateurs autorisés peuvent accéder à l’application

En règle générale, ce processus d’intégration d’une application commence lorsque vous configurez cette application pour qu’elle s’appuie sur Microsoft Entra ID pour l’authentification utilisateur, avec une connexion de protocole d’authentification unique fédérée, et que vous ajoutez ensuite le provisionnement. Les protocoles les plus couramment utilisés pour l’authentification unique sont SAML et OpenID Connect. Vous pouvez en apprendre davantage sur les outils et le processus permettant de découvrir et de migrer l’authentification d’application vers Microsoft Entra ID.

Ensuite, si l’application implémente un protocole de provisionnement, vous devez configurer Microsoft Entra ID pour provisionner des utilisateurs dans l’application, afin que Microsoft Entra ID puisse informer l’application quand un utilisateur a reçu l’accès ou que son accès a été supprimé. Ces signaux de provisionnement permettent à l’application d’apporter des corrections automatiques, telles que la réaffectation du contenu créé par un employé qui a quitté l’entreprise à son responsable.

  1. Vérifiez si votre application figure dans la liste des applications d’entreprise ou la liste des inscriptions d’applications. Si l’application est déjà présente dans votre locataire, passez à l’étape 5 de cette section.

  2. Si votre application est une application SaaS qui n’est pas encore inscrite dans votre locataire, vérifiez si elle est disponible dans la galerie d’applications en tant qu’application pouvant être intégrée pour l’authentification unique fédérée. Si l’application figure dans la galerie, utilisez les tutoriels pour l’intégrer à Microsoft Entra ID.

    1. Suivez le tutoriel pour configurer l’application pour l’authentification unique fédérée avec Microsoft Entra ID.
    2. Si l’application prend en charge le provisionnement, configurez l’application pour le provisionnement.
    3. Lorsque vous avez terminé, passez à la section suivante de cet article. Si l’application SaaS n’est pas dans la galerie, demandez au fournisseur SaaS de l’intégrer.

  3. S’il s’agit d’une application privée ou personnalisée, vous pouvez également sélectionner l’intégration d’authentification unique la plus appropriée, en fonction de l’emplacement et des fonctionnalités de l’application.

  4. Si votre application a plusieurs rôles, que chaque utilisateur n’a qu’un seul rôle dans l’application et que l’application s’appuie sur Microsoft Entra ID pour envoyer le rôle unique spécifique à l’application d’un utilisateur en tant que revendication d’un utilisateur se connectant à l’application, configurez ces rôles d’application dans Microsoft Entra ID sur votre application, puis attribuez chaque utilisateur au rôle d’application. Vous pouvez utiliser l’interface utilisateur des rôles d’application pour ajouter ces rôles au manifeste de l’application. Si vous utilisez les bibliothèques d'authentification Microsoft, un exemple de code explique comment utiliser les rôles d'application dans votre application pour contrôler l'accès. Si un utilisateur peut avoir plusieurs rôles simultanément, vous pouvez souhaiter mettre en œuvre l’application pour vérifier les groupes de sécurité dans les revendications de jetons ou ceux disponibles dans Microsoft Graph, au lieu d’utiliser les rôles d’application du manifeste de l’application pour le contrôle d’accès.

  5. Si l’application prend en charge le provisionnement, configurez le provisionnement des utilisateurs et des groupes affectés de Microsoft Entra ID vers cette application. S’il s’agit d’une application privée ou personnalisée, vous pouvez également sélectionner l’intégration la plus appropriée, en fonction de l’emplacement et des fonctionnalités de l’application.

  6. Si votre application utilise Microsoft Graph pour interroger des groupes à partir de Microsoft Entra ID, consentez à ce que les applications disposent des autorisations appropriées pour lire à partir de votre locataire.

  7. Définissez cet accès de sorte que l’application soit autorisée uniquement pour les utilisateurs affectés à l’application. Ce paramètre empêche que les utilisateurs ne voient par inadvertance l’application dans MyApps et ne tentent de s’y connecter avant que les stratégies d’accès conditionnel soient activées.

Effectuer une révision d’accès initiale

S’il s’agit d’une nouvelle application que votre organisation n’a encore jamais utilisée, et que par conséquent personne n’a un accès préexistant, ou si vous avez déjà effectué des révisions d’accès pour cette application, passez à la section suivante.

Toutefois, si l’application existait déjà dans votre environnement, il est possible que des utilisateurs aient obtenu un accès dans le passé par le biais de processus manuels ou hors bande. Ces utilisateurs doivent maintenant être examinés, afin de confirmer que leur accès est toujours nécessaire et approprié à l’avenir. Nous vous recommandons d’effectuer une révision d’accès des utilisateurs qui ont déjà accès à l’application avant d’activer des stratégies autorisant d’autres utilisateurs à demander l’accès. Cette révision définit une base de référence de tous les utilisateurs ayant été examinés au moins une fois, afin de s’assurer que ces utilisateurs sont autorisés à conserver l’accès.

  1. Suivez les étapes indiquées dans Préparation d’une révision d’accès de l’accès des utilisateurs à une application.
  2. Si l’application n’utilisait pas Microsoft Entra ID ou AD, mais qu’elle prend en charge un protocole d’approvisionnement ou qu’elle avait une base de données SQL ou LDAP sous-jacente, intégrez les utilisateurs existants et créez des attributions de rôles d’application pour eux.
  3. Si l’application n’utilise pas Microsoft Entra ID ou AD et ne prend pas en charge un protocole d’approvisionnement, obtenez une liste d’utilisateurs à partir de l’application et créez des attributions de rôles d’application pour chacun d’eux.
  4. Si l’application utilisait des groupes de sécurité AD, vous devez revoir l’appartenance de ces groupes de sécurité.
  5. Si l’application avait son propre annuaire ou sa propre base de données et n’a pas été intégrée pour le provisionnement, une fois la révision terminée, vous devrez peut-être mettre à jour manuellement la base de données interne ou l’annuaire de l’application pour supprimer les utilisateurs qui ont été refusés.
  6. Si l’application utilisait des groupes de sécurité AD et que ces groupes ont été créés dans AD, une fois la révision terminée, vous devez mettre à jour manuellement les groupes AD pour supprimer les appartenances des utilisateurs qui ont été refusés. Par la suite, pour que les droits d’accès refusés soient supprimés automatiquement, vous pouvez mettre à jour l’application pour qu’elle utilise un groupe AD créé dans Microsoft Entra ID et réécrit dans Microsoft Entra ID ou déplacer l’appartenance du groupe AD vers le groupe Microsoft Entra et imbriquer le groupe réécrit comme seul membre du groupe AD.
  7. Une fois la révision terminée et l’accès à l’application mis à jour, ou si aucun utilisateur n’a accès, passez aux étapes suivantes pour déployer des stratégies de gestion des droits d’utilisation et d’accès conditionnel pour l’application.

Maintenant que vous disposez d’une base de référence qui garantit qu’une révision de l’accès existant a été effectuée, vous pouvez déployer les stratégies de l’organisation pour l’accès continu et toutes les nouvelles demandes d’accès.

Étapes suivantes