Profils de principaux de service : solution multilocative facultative

Les profils de principal de service sont une solution facultative pour les applications multilocataires Power BI Embedded. Ils fournissent des profils clients légers et prennent en charge un grand nombre d’espaces de travail clients sans nécessiter d’inscription d’application Microsoft Entra distincte pour chaque client.

Pour les nouvelles solutions multilocataires, nous recommandons des principaux de service client dédiés, authentifiés au moyen d’identités managées et d’informations d’identification d’identité fédérée lorsque les exigences d’hébergement et de confiance sont remplies.

Les profils restent une alternative valide pour les applications nouvelles et existantes dont les exigences correspondent à leurs fonctionnalités. Ils ne sont pas obsolètes. Les applications existantes auxquelles les profils conviennent peuvent continuer à les utiliser. Cet article explique leurs avantages, limitations et configuration de haut niveau. Pour obtenir des exemples d’API, consultez le guide de profil détaillé.

Où s’inscrivent les profils de principal de service

Prenez en compte les profils lorsque votre application utilise leurs interfaces prises en charge, bénéficie de leur modèle de mise à l’échelle et d’administration et peut accepter leurs limitations d’identité et d’exploitation. Un client est un client logique de votre application, pas nécessairement un locataire Microsoft Entra distinct.

Les profils peuvent réduire l’approvisionnement d’annuaires par client, mais nécessitent toujours une automatisation du cycle de vie des applications. Une petite application n’a peut-être pas besoin de son modèle de mise à l’échelle. Si votre application utilise déjà des identités dédiées et répond à ses exigences, il n’est pas nécessaire de basculer vers des profils.

Limitations et compromis

Évaluez ces contraintes en même temps que les avantages:

• Les profils ne sont pas des identités Microsoft Entra indépendantes et ne produisent pas d'enregistrements de connexion Entra distincts pour chaque client.
• Les profils ne peuvent pas recevoir de stratégies d’accès conditionnel pour les identités de workload ni d’autorisations de service en aval en tant qu’identités Entra indépendantes.
• Les profils ne prennent pas en charge Fabric API REST. Vérifiez les interfaces prises en charge et les limites de mise à l’échelle.
• Les profils restent liés à leur parent de création et disposent d’une administration d’API uniquement.
• Le parent peut agir par l’un de ses profils. Les profils ne créent pas d’isolation cryptographique des clients.

Pour connaître les restrictions complètes, consultez les limitations d’identité et d’API. Les principaux de sécurité dédiés nécessitent également la planification de la capacité d’annuaire et la gestion du cycle de vie ; aucun modèle d’identité ne remplace les autorisations de ressource ou le routage sécurisé du client.

Des espaces de travail clients distincts et des modèles sémantiques peuvent améliorer la gestion de la capacité dans les deux modèles d’identité. Ces avantages ne nécessitent pas de profils. Si une application basée sur un profil existant a besoin de fonctionnalités en dehors du modèle de profil, consultez Remplacer les profils de principal de service par des principaux de service.

Fonctionnement du modèle de profil

Le principal de service parent de l’application crée un profil pour chaque limite d’autorisation du client. L’application associe un client authentifié au profil correct et à ses espaces de travail et contenu autorisés.

Pour les appels REST au niveau du profil, utilisez le jeton d'accès Microsoft Entra parent et l'en-tête X-PowerBI-Profile-Id. Le profil sélectionne le contexte client ; il ne s’agit pas d’un jeton d’accès Entra distinct. Consultez les autorisations de profil.

Prérequis

Après avoir sélectionné le modèle de profil, passez en revue le guide de configuration détaillé.

Vous devez également procéder comme suit :

• Configurez l’authentification de l’application d’entreprise parente et les paramètres de locataire requis. Consultez la configuration du principal de service ou l’option parente pour l’identité managée. Protégez et renouvelez les secrets ou certificats stockés utilisés par la méthode d’authentification choisie.
• À partir d’un compte d’administrateur de locataire Power BI, activez la création de profils dans le locataire.

Configurer une solution basée sur un profil

Si vous choisissez des profils, configurez le contexte client, les ressources et les demandes d’application :

1. Créez des profils de clients.
2. Organisez les espaces de travail client et leur contenu.
3. Configurez les requêtes d’application tenant compte du profil.
4. Valider l’accès client et les opérations.

Créer des profils clients

Utilisez l’API REST Profiles avec le principal de service parent pour créer un profil pour chaque périmètre d’autorisation du client.

Stockez le mappage client à profil dans la configuration côté serveur de confiance. Valider l’appartenance du client avant de sélectionner un profil ou une ressource ; n’acceptez pas les ID de profil arbitraires du client.

Organiser vos espaces de travail

Le moyen le plus simple de gérer vos données consiste à tenir à jour un espace de travail par client. Si votre application utilise déjà ce modèle, vous n’avez pas besoin de créer d’espaces de travail. Toutefois, vous devez quand même fournir à chaque profil un accès Admin à l’espace de travail correspondant à l’aide de l’Add Group User API.

Si vous n’avez pas d’espace de travail par client, utilisez le profil correspondant pour appeler Create Group API pour créer un espace de travail pour chaque client.

Organiser les éléments dans les espaces de travail

Après avoir créé ou affecté des espaces de travail client, importez des rapports et des modèles sémantiques si nécessaire. Conservez le contenu existant si la conception choisie le permet. Choisissez le modèle sémantique et la conception de source de données pour vos besoins :

• Si votre application utilise un modèle sémantique distinct pour chaque client, la conception du modèle sémantique peut fonctionner comme c’est le cas.

• Si votre conception tire parti de modèles distincts, configurez un modèle sémantique pour chaque client. Évaluez les coûts de capacité, de rafraîchissement et d’administration plutôt que de supposer que les profils seuls améliorent la mise à l’échelle de chaque application.

• Si votre conception utilise la sécurité au niveau des lignes (RLS), validez l’identité et les rôles effectifs fournis lors de la génération de jetons incorporés, y compris le résultat attendu UserName() pour le RLS dynamique et la sélection des rôles pour le RLS statique. Vous pouvez utiliser RLS dans le modèle sémantique d’un client pour différencier les droits d’accès entre ses utilisateurs.

Une fois les éléments prêts, importez-les dans les espaces de travail pertinents. Pour automatiser le processus, vous pouvez utiliser l’Import API.

Pour un modèle sémantique existant que le profil client doit administrer par le biais d’opérations de propriétaire uniquement, assurez-vous que le profil possède le modèle. Lorsqu’elle est prise en charge, utilisez l’API Take Over In Group pour ce profil afin de transférer la propriété. Configurez les identités de connexion requises et les informations d’identification de source de données avant de basculer ces opérations vers le profil. L’accès administrateur de l’espace de travail seul ne transfère pas la propriété ni ne configure ces paramètres.

Demandes d’application sensibles au profil

Utilisez le profil client mappé de manière cohérente pour les opérations client prises en charge :

• Authentification et sélection du profil : Obtenez le jeton d’accès du parent via sa méthode d’authentification configurée. Sélectionnez le profil client à l’aide de l’en-tête de profil ou de la configuration du profil sdk. Un profil utilise le jeton du parent ; ne traitez pas un ID de profil comme un ID de principal Entra.
• Provisionnement du client : Créez un profil client et utilisez-le pour créer et administrer l’espace de travail et le contenu du client. Automatisez les importations, la configuration de la connexion et les modifications de cycle de vie si nécessaire.
• Génération de jetons incorporés : Utilisez le contexte de profil client prévu pour appeler l’API GenerateToken. Limitez la demande au contenu autorisé du client et fournissez l’identité effective RLS et les rôles requis, le cas échéant. Le parent peut agir par le biais de ses profils ; un profil n’est pas une limite de sécurité indépendante.

Vérifier l’accès client

Testez la configuration choisie avant la mise en production :

• Vérifiez que chaque client authentifié sélectionne uniquement son profil attribué et les ressources autorisées. Tester les demandes inter-clients refusées ainsi que les demandes réussies.
• Vérifiez l’accès à l’espace de travail du client, la portée du jeton d’incorporation, le rendu du rapport et le comportement RLS applicable.
• Vérifiez la propriété du modèle sémantique, les identités de connexion, les informations d’identification de source de données, les mises à jour des paramètres et l’actualisation planifiée.
• Passez en revue les journaux d’activité des ressources et la surveillance de la connexion de l’identité parente. Les profils ne créent pas de connexions Entra indépendantes pour chaque client.
• Automatisez la désaffectation d’un client et vérifiez les tâches ou le contenu qui dépendent toujours d’un profil avant de supprimer son accès ou de le supprimer.

Contenu connexe

• Multilocatif avec principaux de service dédiés.
• Configurez des profils de principal de service.
• SDK Power BI et profils de principal de service.
• Remplacez les profils de principal de service par des principaux de service.
• Questions? Essayez d’interroger la communauté Power BI