Partager via

Profils des principaux services pour les applications multi-locataire dans Power BI Embedded

  • Article

Cet article explique comment un ISV ou un autre propriétaire d’application Power BI Embedded avec de nombreux clients peuvent utiliser des profils de principal de service pour mapper et gérer les données de chaque client dans le cadre de son incorporation Power BI pour votre solution de clients. Les profils de principal de service permettent aux éditeurs de logiciels indépendants de créer des applications évolutives qui permettent une meilleure isolation des données client et établissent des limites de sécurité plus strictes entre les clients. Cet article décrit les avantages et les limitations de cette solution.

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 multi-locataire pour décrire une solution où une seule instance d’une application logicielle sert 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 tenants) comme indiqué ci-dessous. Ces clients ne sont pas nécessairement des locataires Microsoft Entra. Ne confondez donc pas le terme d’application multi-locataire que nous utilisons ici, avec l’application multi-locataire 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é qui sera 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 SP Profiles et mutualisation.

Notes

Cet article s’adresse aux organisations qui souhaitent configurer une application multi-locataire à l’aide de profils de principal de service. Si votre organisation dispose déjà d’une application prenant en charge l’architecture multi-locataire et que vous souhaitez migrer vers le modèle de profils de principal de service, consultez Migrer vers le modèle de profils de principal de service.

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

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

Prérequis

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

  • Configurez le principal de service en suivant les trois premières étapes de Incorporer du contenu Power BI avec un principal de service.
  • À partir d’un compte d’administrateur de locataire Power BI, activez la création de profils dans le 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 ne peut être utilisé que par ce principal de service.
  • 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 des API REST Power BI en fournissant le jeton Microsoft Entra du principal de 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 le nouvel espace de travail à une capacité

    POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/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/f313e682-c86b-422c-a3e2-b1a05426c4a3/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 devez vous retrouver avec des modèles sémantiques à un seul locataire (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 à un seul locataire 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 multi-locataire 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 aura 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
  • Personnalisations non planifiées pour des locataires spécifiques
  • Fréquence des actualisations des modèles sémantiques

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 pouvez toujours créer plusieurs abonnés 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 de jeux de données de taille petite à moyenne, car :

  • Il n’y a qu’un seul rapport et un seul modèle sémantique à gérer
  • 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 limitations. 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 principal de service pour séparer les données de vos clients, vous pouvez néanmoins toujours utiliser la sécurité au niveau des lignes dans le modèle sémantique d’un même 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

  • 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 les principaux de service

Créer 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 principaux. 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 très prudent lors de la suppression d’un principal de service. Vous ne souhaitez pas perdre accidentellement des données de tous ses profils associés.

Si vous supprimez le principal de service dans Active Directory, tous ses profils dans Power BI seront supprimés. Toutefois, Power BI ne supprime pas immédiatement le contenu, de sorte que l’administrateur abonné peut 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, sachez que 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 les données sont séparées par des profils de principal de service, un mappage simple entre un profil et un client empêche un client de voir le contenu d’un autre client. L’utilisation d’un principal de service unique nécessite que le principal de service ait accès à tous les différents espaces de travail dans tous les profils.

Pour ajouter une séparation supplémentaire, attribuez à un principal de service distinct à chaque locataire, au lieu d’avoir l’accès à un seul principal de service pour plusieurs espaces de travail à l’aide de profils différents. L’attribution de principaux de service distincts présente plusieurs avantages, notamment :

  • Une erreur humaine ou une fuite d’informations d’identification n’entraîne pas l’exposition des données de plusieurs locataires.
  • La rotation des certificats peut être effectuée séparément pour chaque locataire.

Toutefois, l’utilisation de plusieurs principaux de service est fournie avec un coût de gestion élevé. Sélectionnez ce chemin uniquement si vous avez besoin de la séparation supplémentaire. Gardez en mémoire que la configuration des données affichées par l’utilisateur final est définie lors de la génération du jeton incorporé, un processus principal uniquement que les utilisateurs finaux ne peuvent pas voir ni modifier. La demande d’un jeton incorporé à l’aide d’un profil spécifique au locataire génère un jeton incorporé pour ce profil spécifique, ce qui vous donnera la séparation des clients dans la consommation.

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 cela, 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 cette fonctionnalité de modification, analysez rigoureusement la génération de contenu et d’effectuer un scale-up. 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é managée 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.

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 perdrez 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é sera 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é aura 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