Configurer des profils de principal de service pour les applications multilocataires

Cet article explique comment configurer et utiliser des profils de principal de service après les avoir choisis pour une solution Power BI Embedded intégrer pour vos clients. Les profils prennent en charge l’administration de contenu à portée client et un grand nombre d’espaces de travail. La séparation des clients dépend du routage correct des applications, des autorisations d’espace de travail et des jetons d’intégration appropriés ; les profils ne créent pas d'identité Microsoft Entra indépendante ni de périmètre client cryptographique.

Remarque

Pour les nouvelles solutions multilocataires, commencez par des principaux de service dédiés pour les clients, en utilisant une identité managée et des informations d’identification fédérées lorsque les exigences en matière d’hébergement et de confiance s’y prêtent. Les profils restent une solution valide et facultative pour les applications nouvelles et existantes dont les exigences correspondent à leurs avantages et limitations. Vous pouvez continuer à utiliser des profils s’ils répondent à vos besoins.

Les profils ne sont pas des identités Microsoft Entra et ne peuvent pas être utilisés avec les API REST Fabric. Si votre solution nécessite des identités de client pour les services en aval, des journaux de connexion Microsoft Entra indépendants, l’accès conditionnel pour les identités de charge de travail ou des fonctionnalités autrement limitées par le modèle de profil, envisagez de remplacer les profils de principal de service par des principaux de service.

Remarque

Le mot locataire dans Power BI peut parfois faire référence à un locataire Microsoft Entra. Dans cet article, toutefois, nous utilisons le terme multitenancy pour décrire une solution où une instance unique d'une application logicielle dessert plusieurs clients ou organisations (locataires) nécessitant une séparation physique et logique des données. Par exemple, le générateur d’applications Power BI peut allouer un espace de travail distinct pour chacun de ses clients (ou locataires), comme nous l’avons abordé dans cet article. Ces clients ne sont pas nécessairement des locataires Microsoft Entra, donc ne confondez pas le terme d’application multilocataire que nous utilisons ici, avec l’application multilocataire Microsoft Entra.

Un profil de principal de service est un profil créé par un principal de service. L’application ISV appelle les API Power BI à l’aide d’un profil de principal de service, comme expliqué dans cet article.

Le principal de service de l’application ISV crée un profil Power BI différent pour chaque client, ou locataire. Lorsqu’un client visite l’application ISV, l’application utilise le profil correspondant pour générer un jeton incorporé utilisé pour afficher un rapport dans le navigateur.

L’utilisation de profils de principal de service permet à l’application ISV d’héberger plusieurs clients sur un seul abonné Power BI. Chaque profil représente un client dans Power BI. En d’autres termes, chaque profil crée et gère le contenu Power BI pour les données d’un client spécifique.

Diagramme des profils des principaux services et de l’architecture mutualisée.

Remarque

Pour obtenir une vue d’ensemble de cette alternative, consultez les profils de principal de service : solution multilocataire facultative. Les étapes de configuration suivantes s’appliquent après avoir sélectionné le modèle de profil.

La configuration de votre contenu Power BI implique les étapes suivantes :

Toutes les étapes ci-dessus peuvent être entièrement automatisées à l’aide d’API REST Power BI.

Prérequis

Avant de pouvoir créer des profils de principal de service, vous devez :

  • Configurez le service principal parent et les paramètres du locataire requis. Consultez la configuration du principal de service ou l’option parent de l’identité gérée.
  • À partir d’un compte d’administrateur du locataire Power BI, activez la création de profils au sein du locataire à l’aide du même groupe de sécurité que celui que vous avez utilisé lors de la création du principal de service.

Capture d’écran du commutateur de portail Administrateur.

Créer un profil

Les profils peuvent être créés, mis à jour et supprimés à l’aide de l’API REST des profils.

Par exemple, pour créer un profil :

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

Un principal de service peut également appeler l’API REST des profils GET pour obtenir la liste de ses profils. Par exemple :

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

Autorisations de profil

Toute API qui accorde une autorisation utilisateur aux éléments Power BI peut également accorder une autorisation de profil aux éléments Power BI. Par exemple, l’API Ajouter un utilisateur de groupe peut être utilisée pour accorder une autorisation de profil à un espace de travail.

Les points suivants sont importants à comprendre lors de l’utilisation de profils :

  • Un profil appartient au principal de service qui l’a créé, et seul ce principal de service peut l’utiliser.
  • Un propriétaire de profil ne peut pas être modifié après la création.
  • Un profil n’est pas une identité autonome. Il a besoin du jeton Microsoft Entra du principal de service pour appeler les API REST Power BI.

Les applications ISV appellent les API REST de Power BI en fournissant le jeton Microsoft Entra du principal du service dans l’en-tête Authorization et l’ID de profil dans l’en-tête X-PowerBI-Profile-Id. Par exemple :

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

Créer un espace de travail

Les espaces de travail Power BI sont utilisés pour héberger des éléments Power BI comme des rapports et des modèles sémantiques.

Chaque profil doit :

  • Créer au moins un espace de travail Power BI

    POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
Authorization: Bearer eyJ0eXA…ZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "name": "ContosoWorkspace"
}

  • Accorder des autorisations d’accès à l’espace de travail. Le profil de principal de service doit avoir l’accès Admin à l’espace de travail.

  • Attribuer l'espace de travail à une capacité

    POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/AssignToCapacity HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
}

En savoir plus sur les espaces de travail Power BI.

Importer des rapports et des modèles sémantiques

Utilisez Power BI Desktop pour préparer des rapports connectés aux données du client ou à des exemples de données. Ensuite, vous pouvez utiliser l’API Importer pour importer le contenu dans l’espace de travail créé.

POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

Utilisez des paramètres de jeu de données pour créer un modèle sémantique qui peut se connecter à différentes sources de données des clients. Utilisez ensuite l’API Paramètres de mise à jour pour définir les données des clients auxquelles le modèle sémantique se connecte.

Définir la connexion de modèle sémantique

Les éditeurs de logiciels indépendants stockent généralement les données de leurs clients de l’une des deux manières suivantes :

Dans les deux cas, vous devriez obtenir des modèles sémantiques single-tenant (un modèle sémantique par client) dans Power BI.

Une base de données distincte pour chaque client

Si l’application ISV a une base de données distincte pour chaque client, créez des modèles sémantiques monolocataires dans Power BI. Fournissez pour chaque modèle sémantique des détails de connexion qui pointent vers sa base de données correspondante. Utilisez l’une des méthodes suivantes pour éviter de créer plusieurs rapports identiques avec différents détails de connexion :

  • Paramètres du modèle sémantique : créez un modèle sémantique avec des paramètres dans les détails de connexion (par exemple nom du serveur SQL, nom de la base de données SQL). Ensuite, importez un rapport dans l’espace de travail d’un client et modifiez les paramètres pour qu’ils correspondent aux détails de la base de données du client.

  • Mettre à jour l’API Source de données : créez un fichier .pbix qui pointe vers une source de données avec un exemple de contenu. Ensuite, importez le fichier .pbix dans l’espace de travail d’un client et modifiez les détails de connexion à l’aide de Mettre à jour l’API de source de données.

Une base de données multilocataire unique

Si l’application ISV utilise une seule base de données pour tous ses clients, séparez les clients en différents modèles sémantiques dans Power BI comme suit :

Créez un rapport à l’aide des paramètres qui récupèrent uniquement les données du client approprié. Ensuite, importez un rapport dans l’espace de travail d’un client et modifiez les paramètres pour ne récupérer que les données du client approprié.

Embed a report (Intégrer un rapport)

Une fois l’installation terminée, vous pouvez incorporer des rapports clients et d’autres éléments dans votre application à l’aide d’un jeton incorporé.

Lorsqu’un client visite votre application, utilisez le profil correspondant pour appeler l’API GenerateToken. Utilisez le jeton incorporé généré pour incorporer un rapport ou d’autres éléments dans le navigateur du client.

Pour générer un jeton d’incorporation :

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

Aspects de conception

Avant de configurer une solution multi-locataire basée sur un profil, vous devez connaître les problèmes suivants :

Évolutivité

En séparant les données en modèles sémantiques distincts pour chaque client, vous réduisez au minimum la nécessité d’avoir des grands modèles sémantiques. Quand la capacité est dépassée, les modèles sémantiques non utilisés peuvent être supprimés afin de libérer de la mémoire pour les modèles sémantiques actifs. Cette optimisation est impossible pour un seul grand modèle sémantique. En utilisant plusieurs modèles sémantiques, vous pouvez aussi séparer si nécessaire les locataires dans plusieurs capacités Power BI.

Sans profils, un principal de service est limité à 1 000 espaces de travail. Pour surmonter cette limite, un principal de service peut créer plusieurs profils, dans lesquels chaque profil peut accéder/créer jusqu’à 1 000 espaces de travail. Avec plusieurs profils, l’application ISV peut isoler le contenu de chaque client à l’aide de conteneurs logiques distincts.

Une fois qu’un profil de principal de service a accès à un espace de travail, l’accès de son principal de service parent à l’espace de travail peut être supprimé pour éviter les problèmes de scalabilité.

Même avec ces avantages, vous devez prendre en compte l’échelle potentielle de votre application. Par exemple, le nombre d’éléments d’espace de travail auxquels un profil peut accéder est limité. Aujourd’hui, un profil a les mêmes limites qu’un utilisateur normal. Si l’application ISV permet aux utilisateurs finaux d’enregistrer une copie personnalisée de leurs rapports incorporés, le profil d’un client a accès à tous les rapports créés de tous ses utilisateurs. Ce modèle peut éventuellement dépasser la limite.

Automatisation et complexité opérationnelle

Avec la séparation basée sur le profil Power BI, vous pouvez être amené à gérer des centaines ou des milliers d’éléments. Par conséquent, il est important de définir les processus qui se produisent fréquemment dans la gestion du cycle de vie de votre application et vous assurer de disposer de l’ensemble d’outils approprié pour effectuer ces opérations à grande échelle. Certaines opérations sont les suivantes :

  • Ajout d’un nouveau locataire
  • Mise à jour d’un rapport pour certains ou pour tous les locataires
  • Mise à jour du schéma du modèle sémantique pour tout ou partie des locataires
  • Activation de personnalisations non planifiées pour des locataires spécifiques
  • Définition de la fréquence des actualisations de modèle sémantique

Par exemple, la création d’un profil et d’un espace de travail pour un nouveau locataire est une tâche courante, qui peut être entièrement automatisée avec l’API REST Power BI.

Besoins multigéographiques

La prise en charge de plusieurs zones géographiques pour Power BI Embedded signifie que les éditeurs de logiciels indépendants et les organisations qui génèrent des applications à l’aide de Power BI Embedded pour incorporer des analytiques dans leurs applications peuvent désormais déployer leurs données dans différentes régions du monde. Pour prendre en charge différents clients dans différentes régions, attribuer l’espace de travail du client à une capacité dans la région souhaitée. Cette tâche est une opération simple qui n’implique pas de coût supplémentaire. Toutefois, si vous avez des clients qui ont besoin de données provenant de plusieurs régions, le profil locataire doit dupliquer tous les éléments dans plusieurs espaces de travail affectés à différentes capacités régionales. Cette duplication peut augmenter la complexité des coûts et de la gestion.

Pour des raisons de conformité, vous souhaiterez peut-être toujours créer plusieurs locataires Power BI dans différentes régions. En savoir plus sur les zones géographiques multiples.

Rentabilité

Les développeurs d’applications utilisant Power BI Embedded doivent acheter une capacité Power BI Embedded. Le modèle de séparation basé sur un profil fonctionne bien avec les capacités, car :

  • Le plus petit objet que vous pouvez attribuer indépendamment à une capacité est un espace de travail (vous ne pouvez pas attribuer un rapport, par exemple). En séparant les clients par profils, vous obtenez différents espaces de travail : un par client. De cette façon, vous bénéficiez d’une flexibilité totale pour gérer chaque client en fonction de ses besoins en matière de niveau de performance et en optimisant l’utilisation de la capacité en effectuant un scale-up ou un scale-down. Par exemple, vous pouvez gérer des clients volumineux et fondamentaux caractérisés par un volume et une volatilité élevés dans une capacité distincte pour garantir un niveau de service homogène, tout en regroupant les clients plus petits dans une autre capacité afin d’optimiser les coûts.

  • La séparation des espaces de travail implique également de séparer les modèles sémantiques entre les locataires pour que les modèles de données se trouvent dans des blocs plus petits au lieu d’avoir un seul grand modèle sémantique. Ces modèles plus petits permettent de gérer plus efficacement l’utilisation de la mémoire. Les modèle sémantique de petite taille et inutilisés peuvent être supprimés après une période d’inactivité, afin de maintenir un bon niveau de performance.

Lors de l’achat d’une capacité, prenez en compte la limite du nombre d’actualisations parallèles, car les processus d’actualisation peuvent nécessiter une capacité supplémentaire quand vous avez plusieurs modèles sémantiques.

Sécurité au niveau des lignes

Cet article explique comment utiliser des profils pour créer un modèle sémantique distinct pour chaque client. Les applications ISV peuvent aussi stocker toutes les données de leurs clients dans un grand modèle sémantique et utiliser la sécurité au niveau des lignes (RLS) pour protéger les données de chaque client. Cette approche peut être pratique pour les éditeurs de logiciels indépendants qui ont relativement peu de clients et des modèles sémantiques de taille petite à moyenne, car :

  • Ils n’ont qu’à conserver un rapport et un modèle sémantique
  • Le processus d’intégration pour les nouveaux clients peut être simplifié

Avant d’utiliser la sécurité au niveau des lignes, veillez toutefois à comprendre ses limites. Toutes les données de tous les clients se trouvent dans un grand modèle sémantique Power BI. Ce modèle sémantique s’exécute dans une seule capacité avec sa propre mise à l’échelle et ses autres limitations.

Même si vous utilisez des profils de service principal pour séparer les données de vos clients, vous pouvez toujours utiliser la RLS (sécurité au niveau des lignes) au sein du modèle sémantique d'un seul client pour permettre à différents groupes d'accéder à différentes parties des données. Par exemple, vous pouvez utiliser RLS pour empêcher les membres d’un service d’accéder aux données d’un autre service dans la même organisation.

Observations et limitations

Évaluez les limites d’identité numérique, d’API et d’échelle avant de choisir ou d’étendre le modèle de profil.

Limitations de l’identité et de l’API

Passez en revue ces limitations avant d’adopter des profils ou d’étendre une solution existante basée sur des profils :

Limitation Ce que cela signifie pour votre solution
Ce n’est pas une identité Microsoft Entra Un profil existe uniquement dans Power BI. Vous ne pouvez pas le gérer ou l’examiner indépendamment à l’aide des outils Microsoft Entra, ni accorder des autorisations en tant qu’identité dans les services dépendants en aval. Par exemple, un profil ne peut pas être l’identité d’une connexion Direct Lake d’un modèle sémantique à un lakehouse ou à un warehouse.
Aucune prise en charge de l’API REST Fabric Les profils fonctionnent via l’API REST Power BI, Power BI .NET SDK et les interfaces XMLA/TOM prises en charge. Les API REST Fabric ne les prennent pas en charge, et aucune prise en charge n'est prévue.
Aucune identité de connexion indépendante Les opérations à l’échelle du profil ne produisent pas d'enregistrements de connexion Microsoft Entra indépendants par client. Les journaux d’activité Power BI peuvent toujours identifier les profils.
Aucun accès conditionnel par profil Un profil n’est pas un principal que l’Accès conditionnel pour les identités de charge de travail peut cibler. Les stratégies pour les principaux de service dédiés éligibles ont des exigences distinctes en matière de licence et de configuration.
Lié à leur principal créateur Vous ne pouvez pas transférer de profils entre les principaux de service parents. La modification de l’élément parent nécessite la recréation des profils, la restauration de l’accès à l’espace de travail et la mise à jour des mappages client.
Administration uniquement par API Les profils n’ont aucune interface utilisateur d’administration dédiée pour les inspecter et les gérer. Ils ne sont pas représentés dans le centre d’administration Microsoft Entra.

Si ces limitations limitent votre solution, consultez Remplacer les profils de principal de service par des principaux de service. Pour les clients qui choisissent de migrer, ce guide recommande une identité managée et des informations d’identification fédérées lorsque les exigences d’hébergement et de confiance s’y prêtent. L’authentification directe du principal de service reste une alternative.

Interfaces prises en charge et limites de mise à l’échelle

  • Les profils de principal de service ne sont pris en charge que par le biais de l’API REST Power BI, du kit de développement logiciel (SDK) Power BI .NET, et via le point de terminaison XMLA et le modèle d’objet tabulaire (TOM) lors de l’utilisation des bibliothèques clientes Analysis Services version 16.0.139.27 ou ultérieure. Les profils de principal de service ne sont pas pris en charge dans Power BI via le point de terminaison XMLA ou le modèle objet tabulaire (TOM) avec des bibliothèques clientes plus anciennes.
  • Les profils de principal de service ne sont pas pris en charge avec Azure Analysis Services (AAS) en mode de connexion active.
  • Un seul principal de service peut avoir un maximum de 100 000 profils.

Limitations de capacité Power BI

Gérer des service principals

Changer un principal du service

Dans Power BI, un profil appartient au principal de service qui l’a créé. Cela signifie qu’un profil ne peut pas être partagé avec d’autres utilisateurs. Avec cette limitation, si vous souhaitez modifier le principal de service pour une raison quelconque, vous devez recréer tous les profils et fournir les nouveaux profils d’accès aux espaces de travail appropriés. Souvent, l’application ISV doit enregistrer un mappage entre un ID de profil et un ID client afin de choisir le profil approprié si nécessaire. Si vous modifiez le principal de service et recréez les profils, les ID changeront également et vous devrez peut-être mettre à jour le mappage dans la base de données d’application ISV.

Supprimer un principal de service

Avertissement

Soyez prudent lors de la suppression d’un principal de service. Vous ne souhaitez pas perdre accidentellement des données de tous les profils associés.

Si vous supprimez le principal de service dans active directory, tous ses profils dans Power BI sont supprimés. Toutefois, Power BI ne supprime pas immédiatement le contenu, afin que l’administrateur du locataire puisse toujours accéder aux espaces de travail. Soyez prudent lors de la suppression d’un principal de service utilisé dans un système de production, en particulier lorsque vous avez créé des profils à l’aide de ce principal de service dans Power BI. Si vous supprimez un principal de service qui a créé des profils, vous devez recréer tous les profils, fournir les nouveaux profils d’accès aux espaces de travail appropriés et mettre à jour les ID de profil dans la base de données d’application ISV.

Séparation des données

Lorsque vous utilisez des profils de principal de service, votre application doit mapper chaque client authentifié au profil approprié et aux ressources autorisées. Les autorisations d’espace de travail et les jetons d’intégration à portée limitée contrôlent l’accès. Un profil n'est pas une identité Microsoft Entra indépendante, et son principal de service parent peut agir par le biais de n'importe quel profil qu'il crée.

Prenez en compte les principaux de service dédiés lorsque votre solution nécessite une gouvernance Microsoft Entra, une surveillance de connexion indépendante, des stratégies d’accès conditionnel pour les identités de charge de travail éligibles, des identités de services en aval ou un accès à l’API REST Fabric. Ils sont également une alternative lorsque le couplage du profil au parent ou l’administration API uniquement créent des difficultés opérationnelles. Si les profils répondent à vos besoins, vous pouvez continuer à les utiliser.

Les identités de service dédiées vous permettent de gérer indépendamment les autorisations et l’authentification des clients. Si vous utilisez des certificats stockés, vous pouvez les renouveler séparément pour chaque client. Toutefois, l’impact d’une fuite d’identifiants ou d’une compromission du runtime dépend des informations d’identification client ou des relations d’approbation fédérées que le runtime peut utiliser. Aucune architecture ne garantit automatiquement l’isolation entre les clients.

La gestion des identités dédiées entraîne des limites des objets d’annuaire et la gestion du cycle de vie. Évaluez ces compromis et suivez Remplacer les profils de principal de service par des objets de service si vous choisissez de migrer. Conservez la configuration des données à afficher dans le back-end lorsque vous générez le jeton d’intégration. Validez l’adhésion du client avant de sélectionner une identité, un espace de travail ou un contenu.

Un rapport, plusieurs modèles sémantiques

En général, vous avez un rapport et un modèle sémantique par locataire. Si vous avez des centaines de rapports, vous aurez des centaines de modèles sémantiques. Parfois, vous pouvez avoir un seul format de rapport avec différents modèles sémantiques (par exemple différents paramètres ou détails de connexion). Chaque fois que vous disposez d’une nouvelle version du rapport, vous devez mettre à jour tous les rapports pour tous les locataires. Bien que vous puissiez automatiser ce processus, il est plus facile de gérer si vous n’avez qu’une seule copie du rapport. Créez un espace de travail qui contient le rapport à intégrer. Pendant l’exécution d’une session, liez le rapport au modèle sémantique spécifique du locataire. Pour plus d’informations, lisez les liaisons dynamiques.

Personnalisation et création du contenu

Lorsque vous créez du contenu, réfléchissez soigneusement à qui a l’autorisation de le modifier. Si vous autorisez plusieurs utilisateurs dans chaque locataire à effectuer des modifications, les limitations des modèles sémantiques risquent d’être dépassées. Si vous décidez d'accorder aux utilisateurs la capacité de modification, surveillez étroitement leur génération de contenu et augmentez progressivement si nécessaire. Pour les mêmes raisons, nous déconseillons l’utilisation de cette fonctionnalité pour la personnalisation du contenu, dans laquelle chaque utilisateur peut apporter des modifications mineures à un rapport et l’enregistrer pour lui-même. Si l’application ISV autorise la personnalisation du contenu, envisagez d’introduire des stratégies de rétention d’espaces de travail pour du contenu spécifique à l’utilisateur. Les stratégies de rétention facilitent la suppression du contenu lorsque les utilisateurs passent à une nouvelle position, quittent l’entreprise ou arrêtent d’utiliser la plateforme.

Identité gérée par le système

Au lieu d’un principal de service, vous pouvez utiliser uneidentité managée affectée par l’utilisateur ou affectée par le système pour créer des profils. Les identités managées réduisent le besoin de secrets et de certificats.

Remarque

Une identité managée qui crée et utilise des profils ne transforme pas ces profils en identités Microsoft Entra et ne permet pas leur utilisation avec les API REST Fabric. Cette condition diffère de l’utilisation de l’identité managée et des justificatifs fédérés pour s’authentifier en tant que principaux de service dédiés au client. Consultez Remplacer des profils de principal de service par des principaux de service.

Soyez prudent lors de l’utilisation d’une identité managée par le système, car :

  • Si une identité managée affectée par le système est désactivée accidentellement, vous perdez l’accès aux profils. Cette situation est similaire à un cas où un principal de service est supprimé.
  • Une identité managée affectée par le système est connectée à une ressource dans Azure (application web). Si vous supprimez la ressource, l’identité est également supprimée.
  • L’utilisation de plusieurs ressources (différentes applications web dans différentes régions) entraîne la gestion de plusieurs identités qui doivent être gérées séparément (chaque identité possède ses propres profils).

En raison des considérations ci-dessus, nous vous recommandons d’utiliser une identité managée affectée par l’utilisateur.

Exemple

Pour obtenir un exemple d’utilisation des profils de principal de service pour gérer un environnement multilocataire avec l’incorporation de Power BI et d’App-Owns-Data, téléchargez le référentiel App owns data multilocataire à partir de Power BI Dev Camp (site tiers).

Contenu connexe

  • Dernière mise à jour :