Delen via

Schaalbare multitenancytoepassingen ontwikkelen met Power BI-insluiting

  • Artikel

In dit artikel wordt beschreven hoe u een multitenancy-toepassing ontwikkelt waarmee Power BI-inhoud wordt ingesloten en tegelijkertijd de hoogste schaalbaarheid, prestaties en beveiliging wordt bereikt. Door een toepassing met service-principalprofielen te ontwerpen en te implementeren, kunt u een multitenancy-oplossing maken en beheren die bestaat uit tienduizenden klanttenants die rapporten kunnen leveren aan doelgroepen van meer dan 100.000 gebruikers.

Service-principalprofielen is een functie waarmee u eenvoudiger organisatie-inhoud in Power BI kunt beheren en uw capaciteiten efficiënter kunt gebruiken. Het gebruik van service-principalprofielen kan echter complexiteit toevoegen aan uw toepassingsontwerp. Daarom moet u ze alleen gebruiken wanneer er een aanzienlijke schaal moet worden bereikt. We raden u aan service-principalprofielen te gebruiken wanneer u veel werkruimten en meer dan 1000 toepassingsgebruikers hebt.

Notitie

De waarde van het gebruik van service-principalprofielen neemt toe naarmate uw behoefte aan schaalverhogingen en uw behoefte aan het bereiken van de hoogste beveiligings- en tenantisolatie.

U kunt power BI-insluiting bereiken met behulp van twee verschillende insluitingsscenario's: Insluiten voor uw organisatie en Insluiten voor uw klant.

Het scenario Insluiten voor uw organisatie is van toepassing wanneer de doelgroep van de toepassing interne gebruikers omvat. Interne gebruikers hebben organisatieaccounts en moeten worden geverifieerd met Microsoft Entra-id (voorheen Bekend als Azure Active Directory). In dit scenario is Power BI software-as-a-service (SaaS). Het wordt soms aangeduid als Gebruiker is eigenaar van gegevens.

Het scenario Insluiten voor uw klant is van toepassing wanneer de doelgroep van de toepassing externe gebruikers omvat. De toepassing is verantwoordelijk voor het verifiëren van gebruikers. Voor toegang tot Power BI-inhoud is de toepassing afhankelijk van een insluitidentiteit (Microsoft Entra-service-principal of hoofdgebruikersaccount) voor verificatie met Microsoft Entra. In dit scenario is Power BI platform-as-a-service (PaaS). Het wordt soms aangeduid als App is eigenaar van gegevens.

Notitie

Het is belangrijk om te weten dat de functie service-principalprofielen is ontworpen voor gebruik met het scenario Insluiten voor uw klant . Dat komt doordat dit scenario ISV's en ondernemingen de mogelijkheid biedt om in te sluiten met een groter aantal gebruikers en een groot aantal klanttenants.

Ontwikkeling van multitenancy-toepassingen

Als u bekend bent met Microsoft Entra, kan het woord tenant ertoe leiden dat u denkt aan een Microsoft Entra-tenant. Het concept van een tenant verschilt echter in de context van het bouwen van een multitenancy-oplossing waarmee Power BI-inhoud wordt ingesloten. In deze context wordt een klanttenant gemaakt namens elke klant waarvoor de toepassing Power BI-inhoud insluit met behulp van het scenario Insluiten voor uw klant . Doorgaans richt u elke klanttenant in door één Power BI-werkruimte te maken.

Als u een schaalbare multitenancy-oplossing wilt maken, moet u het maken van nieuwe klanttenants kunnen automatiseren. Het inrichten van een nieuwe klanttenant omvat meestal het schrijven van code die gebruikmaakt van de Power BI REST API om een nieuwe Power BI-werkruimte te maken, semantische modellen (voorheen gegevenssets genoemd) te maken door Power BI Desktop-bestanden (.pbix) te importeren, gegevensbronparameters bij te werken, referenties voor gegevensbronnen in te stellen en geplande semantische modelvernieuwing in te stellen. In het volgende diagram ziet u hoe u Power BI-items, zoals rapporten en semantische modellen, kunt toevoegen aan werkruimten om tenants van klanten in te stellen.

Diagram met een installatie voor drie tenants. Elke tenant heeft een eigen gegevensbron en werkruimte.

Wanneer u een toepassing ontwikkelt die gebruikmaakt van het scenario Insluiten voor uw klant, is het mogelijk om Power BI REST API-aanroepen te maken met behulp van een insluitidentiteit die een hoofdgebruikersaccount of een service-principal is. U wordt aangeraden een service-principal te gebruiken voor productietoepassingen. Het biedt de hoogste beveiliging en daarom is het de aanpak die door Microsoft Entra wordt aanbevolen. Het biedt ook ondersteuning voor betere automatisering en schaal en er is minder beheeroverhead. Hiervoor moeten Power BI-beheerdersrechten echter worden ingesteld en beheerd.

Met behulp van een service-principal kunt u veelvoorkomende problemen voorkomen die zijn gekoppeld aan hoofdgebruikersaccounts, zoals verificatiefouten in omgevingen waarin gebruikers zich moeten aanmelden met behulp van meervoudige verificatie (MFA). Het gebruik van een service-principal is ook consistent met het idee dat het scenario Insluiten voor uw klant is gebaseerd op het insluiten van Power BI-inhoud met behulp van een PaaS-mindset in plaats van een SaaS-mindset.

Beperking van 1000 werkruimten

Wanneer u een omgeving met meerdere tenants ontwerpt die het insluiten voor uw klantscenario implementeert, moet u er rekening mee houden dat de insluitidentiteit geen toegang kan krijgen tot meer dan 1000 werkruimten. De Power BI-service legt deze beperking op om goede prestaties te garanderen bij het maken van REST API-aanroepen. De reden voor deze beperking is gerelateerd aan de wijze waarop Power BI beveiligingsgerelateerde metagegevens voor elke identiteit onderhoudt.

Power BI gebruikt metagegevens om de werkruimten en werkruimte-items bij te houden die een identiteit kan openen. Power BI moet in feite een afzonderlijke ACL (Access Control List) onderhouden voor elke identiteit in het autorisatiesubsysteem. Wanneer een identiteit een REST API-aanroep maakt voor toegang tot een werkruimte, moet Power BI een beveiligingscontrole uitvoeren op basis van de ACL van de identiteit om ervoor te zorgen dat deze is geautoriseerd. De tijd die nodig is om te bepalen of de doelwerkruimte zich in de ACL bevindt, neemt exponentieel toe naarmate het aantal werkruimten toeneemt.

Notitie

Power BI dwingt de beperking van 1000 werkruimten niet af via code. Als u het probeert, voegt u een insluitidentiteit toe aan meer dan 1000 werkruimten en worden REST API-aanroepen nog steeds uitgevoerd. Uw toepassing wordt echter verplaatst naar een niet-ondersteunde status. Dit kan gevolgen hebben als u hulp van Microsoft-ondersteuning wilt aanvragen.

Overweeg een scenario waarin twee toepassingen met meerdere tenants zijn ingesteld voor het gebruik van één service-principal. Houd er nu rekening mee dat de eerste toepassing 990 werkruimten heeft gemaakt terwijl de tweede toepassing 1010 werkruimten heeft gemaakt. Vanuit ondersteuningsperspectief bevindt de eerste toepassing zich binnen de ondersteunde grenzen, terwijl de tweede toepassing dat niet is.

Vergelijk deze twee toepassingen nu puur vanuit een prestatieperspectief. Er is niet zoveel verschil omdat de ACL's voor beide service-principals de metagegevens voor hun ACL's tot een punt hebben laten groeien waar de prestaties tot een bepaalde mate afnemen.

Hier volgt de belangrijkste waarneming: het aantal werkruimten dat door een service-principal is gemaakt, heeft een directe invloed op de prestaties en schaalbaarheid. Een service-principal die lid is van 100 werkruimten, voert SNELLER REST API-aanroepen uit dan een service-principal die lid is van 1000 werkruimten. Op dezelfde manier voert een service-principal die lid is van slechts 10 werkruimten REST API-aanroepen sneller uit dan een service-principal die lid is van 100 werkruimten.

Belangrijk

Vanuit het perspectief van prestaties en schaalbaarheid is het optimale aantal werkruimten waarvoor een service-principal lid is precies één.

Isolatie voor semantische modellen en gegevensbronreferenties beheren

Een ander belangrijk aspect bij het ontwerpen van een multitenancy-toepassing is het isoleren van tenants van klanten. Het is essentieel dat gebruikers van de ene klanttenant geen gegevens zien die deel uitmaken van een andere klanttenant. Daarom moet u begrijpen hoe u semantisch modeleigendom en gegevensbronreferenties beheert.

Semantisch modeleigendom

Elk semantisch Power BI-model heeft één eigenaar. Dit kan een gebruikersaccount of een service-principal zijn. Semantisch modeleigendom is vereist voor het instellen van geplande vernieuwing en het instellen van semantische modelparameters.

Tip

In de Power BI-service kunt u bepalen wie de eigenaar van het semantische model is door de semantische modelinstellingen te openen.

Indien nodig kunt u het eigendom van het semantische model overdragen aan een ander gebruikersaccount of een andere service-principal. U kunt dit doen in de Power BI-service of met behulp van de REST API-bewerkingTakeOver. Wanneer u een Power BI Desktop-bestand importeert om een nieuw semantisch model te maken met behulp van een service-principal, wordt de service-principal automatisch ingesteld als de eigenaar van het semantische model.

Gegevensbronreferenties

Als u een semantisch model wilt verbinden met de onderliggende gegevensbron, moet de eigenaar van het semantische model referenties voor gegevensbronnen instellen. Gegevensbronreferenties worden versleuteld en in de cache opgeslagen door Power BI. Vanaf dat moment gebruikt Power BI deze referenties om te verifiëren bij de onderliggende gegevensbron bij het vernieuwen van de gegevens (voor het importeren van opslagtabellen) of het uitvoeren van passthrough-query's (voor DirectQuery-opslagtabellen).

U wordt aangeraden een gemeenschappelijk ontwerppatroon toe te passen bij het inrichten van een nieuwe klanttenant. U kunt een reeks REST API-aanroepen uitvoeren met behulp van de identiteit van de service-principal:

  1. Maak een nieuwe werkruimte.
  2. Koppel de nieuwe werkruimte aan een toegewezen capaciteit.
  3. Importeer een Power BI Desktop-bestand om een semantisch model te maken.
  4. Stel de bronreferenties voor het semantische model in voor dat semantische model.

Na voltooiing van deze REST API-aanroepen is de service-principal een beheerder van de nieuwe werkruimte en de eigenaar van het semantische model en de referenties voor de gegevensbron.

Belangrijk

Er is een veelvoorkomende misvatting dat semantische gegevensbronreferenties van het model een bereik op werkruimteniveau hebben. Dat is niet waar. Referenties voor gegevensbronnen zijn gericht op de service-principal (of gebruikersaccount) en dat bereik wordt uitgebreid tot alle Power BI-werkruimten in de Microsoft Entra-tenant.

Het is mogelijk dat een service-principal referenties voor gegevensbronnen maakt die worden gedeeld door semantische modellen in verschillende werkruimten in verschillende tenants van klanten, zoals wordt weergegeven in het volgende diagram.

Diagram met een installatie voor twee tenants. Elke tenant deelt dezelfde referenties voor de gegevensbron.

Wanneer gegevensbronreferenties worden gedeeld door semantische modellen die deel uitmaken van verschillende tenants van klanten, worden de tenants van de klant niet volledig geïsoleerd.

Ontwerpstrategieën vóór service-principal-profielen

Inzicht in ontwerpstrategieën voordat de functie voor het service-principal-profiel beschikbaar werd, kan u helpen om de behoefte aan de functie te waarderen. Vóór die tijd hebben ontwikkelaars multitenancy-toepassingen gebouwd met behulp van een van de volgende drie ontwerpstrategieën:

  • Eén service-principal
  • Pooling van service-principals
  • Eén service-principal per werkruimte

Er zijn sterke en zwakke punten die verband houden met elk van deze ontwerpstrategieën.

Voor de ontwerpstrategie voor één service-principal is een eenmalige creatie van een Microsoft Entra-app-registratie vereist. Daarom is er minder administratieve overhead nodig dan de andere twee ontwerpstrategieën, omdat er geen vereiste is om meer Microsoft Entra-app-registraties te maken. Deze strategie is ook het eenvoudigst in te stellen, omdat hiervoor geen extra code hoeft te worden geschreven waarmee de aanroepende context tussen service-principals wordt gewijzigd bij het maken van REST API-aanroepen. Een probleem met deze ontwerpstrategie is echter dat deze niet wordt geschaald. Het biedt alleen ondersteuning voor een multitenancy-omgeving die kan groeien tot 1000 werkruimten. Bovendien kunnen de prestaties afnemen omdat de service-principal toegang krijgt tot een groter aantal werkruimten. Er is ook een probleem met tenantisolatie van de klant, omdat de enkele service-principal de eigenaar wordt van elk semantisch model en alle gegevensreferenties voor alle tenants van klanten.

De ontwerpstrategie voor service-principalpooling wordt vaak gebruikt om de beperking van 1000 werkruimten te voorkomen. Hiermee kan de toepassing worden geschaald naar een willekeurig aantal werkruimten door het juiste aantal service-principals toe te voegen aan de pool. Een groep van vijf service-principals maakt het bijvoorbeeld mogelijk om maximaal 5000 werkruimten op te schalen; Een groep van 80 service-principals maakt het mogelijk om maximaal 80.000 werkruimten op te schalen, enzovoort. Hoewel deze strategie echter kan worden geschaald naar een groot aantal werkruimten, heeft deze verschillende nadelen. Eerst moet er extra code worden geschreven en metagegevens worden opgeslagen om contextwisseling tussen service-principals mogelijk te maken bij het maken van REST API-aanroepen. Ten tweede gaat het om meer administratieve inspanningen, omdat u Microsoft Entra-app-registraties moet maken wanneer u het aantal service-principals in de pool moet verhogen.

Bovendien is de poolstrategie voor service-principals niet geoptimaliseerd voor prestaties, omdat service-principals lid kunnen worden van honderden werkruimten. Het is ook niet ideaal vanuit het perspectief van klanttenantisolatie, omdat de service-principals eigenaar kunnen worden van semantisch model en gegevensreferenties die worden gedeeld tussen tenants van klanten.

De ene service-principal per ontwerpstrategie voor werkruimten omvat het maken van een service-principal voor elke klanttenant. Vanuit theoretisch oogpunt biedt deze strategie de beste oplossing omdat deze de prestaties van REST API-aanroepen optimaliseert en tegelijkertijd echte isolatie biedt voor semantische modellen en gegevensbronreferenties op werkruimteniveau. Wat het beste in theorie werkt, werkt echter niet altijd best in de praktijk. Dat komt doordat de vereiste voor het maken van een service-principal voor elke klanttenant onpraktisch is voor veel organisaties. Dat komt doordat sommige organisaties formele goedkeuringsprocessen hebben of te veel bureaucratie hebben om Microsoft Entra-app-registraties te maken. Deze redenen kunnen het onmogelijk maken om een aangepaste toepassing de instantie te verlenen die nodig is voor het maken van Microsoft Entra-app-registraties op aanvraag en op de geautomatiseerde manier die uw oplossing vereist.

In minder gangbare scenario's waarin een aangepaste toepassing de juiste machtigingen heeft gekregen, kan deze de Microsoft Graph API gebruiken om microsoft Entra-app-registraties op aanvraag te maken. De aangepaste toepassing is echter vaak complex om te ontwikkelen en te implementeren, omdat deze verificatiereferenties moet bijhouden voor elke Registratie van Microsoft Entra-apps. Het moet ook toegang krijgen tot deze referenties wanneer deze moet worden geverifieerd en toegangstokens moeten verkrijgen voor afzonderlijke service-principals.

Service-principalprofielen

De functie voor service-principalprofielen is ontworpen om het beheer van organisatie-inhoud in Power BI eenvoudiger te maken en uw capaciteiten efficiënter te gebruiken. Ze helpen bij het oplossen van drie specifieke uitdagingen die betrekking hebben op de laagste hoeveelheid inspanning en overhead van ontwikkelaars. Deze uitdagingen zijn onder andere:

  • Schalen naar een groot aantal werkruimten.
  • Prestaties van REST API-aanroepen optimaliseren.
  • Semantische modellen en gegevensbronreferenties isoleren op tenantniveau van de klant.

Wanneer u een multitenancy-toepassing ontwerpt met behulp van service-principal-profielen, kunt u profiteren van de sterke punten van de drie ontwerpstrategieën (beschreven in de vorige sectie) terwijl de bijbehorende zwakke punten worden vermeden.

Service-principalprofielen zijn lokale accounts die in de context van Power BI worden gemaakt. Een service-principal kan de Profiles REST API-bewerking gebruiken om nieuwe profielen voor service-principals te maken. Een service-principal kan een eigen set service-principalprofielen maken en beheren voor een aangepaste toepassing, zoals wordt weergegeven in het volgende diagram.

Diagram met een service-principal die drie service-principalprofielen maakt in Power BI.

Er is altijd een relatie tussen een service-principal en de profielen van de service-principal die worden gemaakt. U kunt geen service-principalprofiel maken als een zelfstandige entiteit. In plaats daarvan maakt u een service-principalprofiel met behulp van een specifieke service-principal en die service-principal fungeert als het bovenliggende profiel. Bovendien is een service-principalprofiel nooit zichtbaar voor gebruikersaccounts of andere service-principals. Een service-principalprofiel kan alleen worden weergegeven en gebruikt door de service-principal die het heeft gemaakt.

Service-principalprofielen zijn niet bekend bij Microsoft Entra

Hoewel de service-principal zelf en de onderliggende registratie van Microsoft Entra-apps bekend zijn bij Microsoft Entra, weet Microsoft Entra ID niets over service-principalprofielen. Dat komt doordat service-principalprofielen worden gemaakt door Power BI en ze alleen bestaan in het Power BI-service subsysteem dat de beveiliging en autorisatie van Power BI beheert.

Het feit dat service-principalprofielen niet bekend zijn bij Microsoft Entra ID, hebben zowel voor- als nadelen. Het belangrijkste voordeel is dat voor een toepassing insluiten voor uw klantscenario geen speciale Microsoft Entra-machtigingen nodig zijn om service-principalprofielen te maken. Dit betekent ook dat de toepassing een set lokale identiteiten kan maken en beheren die los staan van Microsoft Entra.

Er zijn echter ook nadelen. Omdat service-principalprofielen niet bekend zijn bij Microsoft Entra, kunt u geen service-principalprofiel toevoegen aan een Microsoft Entra-groep om deze impliciet toegang te verlenen tot een werkruimte. Externe gegevensbronnen, zoals een Azure SQL Database of Azure Synapse Analytics, kunnen ook geen service-principalprofielen herkennen als de identiteit bij het maken van verbinding met een database. De ene service-principal per werkruimte-ontwerpstrategie (het maken van een service-principal voor elke klanttenant) is dus een betere keuze wanneer er een vereiste is om verbinding te maken met deze gegevensbronnen met behulp van een afzonderlijke service-principal met unieke verificatiereferenties voor elke tenant van de klant.

Service-principalprofielen zijn eersteklas beveiligingsprinciplen

Hoewel service-principalprofielen niet bekend zijn bij Microsoft Entra, herkent Power BI deze als eersteklas beveiligingsprinciplen. Net als een gebruikersaccount of service-principal kunt u service-principalprofielen toevoegen aan een werkruimterol (als Beheer of lid). U kunt het ook een semantische modeleigenaar en de eigenaar van gegevensbronreferenties maken. Om deze redenen is het maken van een nieuw service-principalprofiel voor elke nieuwe klanttenant een best practice.

Diagram met meerdere klanttenants, elk met hun eigen service-principal-profielen.

Tip

Wanneer u een Insluiten voor uw klantscenariotoepassing ontwikkelt met behulp van service-principal-profielen, hoeft u slechts één Microsoft Entra-app-registratie te maken om uw toepassing één service-principal te bieden. Deze aanpak verlaagt de administratieve overhead aanzienlijk ten opzichte van andere strategieën voor multitenancyontwerp, waarbij het nodig is om doorlopend extra Microsoft Entra-app-registraties te maken nadat de toepassing is geïmplementeerd in productie.

REST API-aanroepen uitvoeren als een service-principal-profiel

Uw toepassing kan REST API-aanroepen uitvoeren met behulp van de identiteit van een service-principalprofiel. Dit betekent dat er een reeks REST API-aanroepen kan worden uitgevoerd om een nieuwe klanttenant in te richten en in te stellen.

  1. Wanneer een service-principalprofiel een nieuwe werkruimte maakt, voegt Power BI dat profiel automatisch toe als werkruimtebeheerder.
  2. Wanneer een service-principalprofiel een Power BI Desktop-bestand importeert om een semantisch model te maken, stelt Power BI dat profiel in als de eigenaar van het semantische model.
  3. Wanneer met een service-principalprofiel referenties voor gegevensbronnen worden ingesteld, wordt dat profiel door Power BI ingesteld als eigenaar van de referenties voor de gegevensbron.

Het is belangrijk om te begrijpen dat een service-principal een identiteit heeft in Power BI die gescheiden is van de identiteiten van de profielen. Dat biedt u de keuze als ontwikkelaar. U kunt REST API-aanroepen uitvoeren met behulp van de identiteit van een service-principalprofiel. U kunt ook REST API-aanroepen uitvoeren zonder een profiel, dat gebruikmaakt van de identiteit van de bovenliggende service-principal.

U wordt aangeraden REST API-aanroepen uit te voeren als de bovenliggende service-principal wanneer u service-principalprofielen maakt, weergeeft of verwijdert. U moet het service-principal-profiel gebruiken om alle andere REST API-aanroepen uit te voeren. Deze andere aanroepen kunnen werkruimten maken, Power BI Desktop-bestanden importeren, semantische modelparameters bijwerken en referenties voor gegevensbronnen instellen. Ze kunnen ook metagegevens van werkruimte-items ophalen en insluittokens genereren.

Bekijk een voorbeeld waarin u een klanttenant moet instellen voor een klant met de naam Contoso. De eerste stap maakt een REST API-aanroep om een service-principalprofiel te maken met de weergavenaam die is ingesteld op Contoso. Deze aanroep wordt gedaan met behulp van de identiteit van de service-principal. Alle resterende configuratiestappen maken gebruik van het service-principal-profiel om de volgende taken uit te voeren:

  1. Een werkruimte maken.
  2. Koppel de werkruimte aan een capaciteit.
  3. Een Power BI Desktop-bestand importeren.
  4. Stel semantische modelparameters in.
  5. Gegevensbronreferenties instellen.
  6. Geplande gegevensvernieuwing instellen.

Het is belangrijk om te begrijpen dat toegang tot de werkruimte en de inhoud ervan moet worden uitgevoerd met behulp van de identiteit van het service-principal-profiel dat is gebruikt om de tenant van de klant te maken. Het is ook belangrijk om te begrijpen dat de bovenliggende service-principal geen toegang nodig heeft tot de werkruimte of de inhoud ervan.

Tip

Vergeet niet: wanneer u REST API-aanroepen maakt, gebruikt u de service-principal om service-principalprofielen te maken en beheren, en gebruikt u het service-principalprofiel om Power BI-inhoud te maken, in te stellen en te openen.

Rest API-bewerkingen voor profielen gebruiken

De REST API-bewerkingsgroep Profielen bestaat uit bewerkingen waarmee service-principalprofielen worden gemaakt en beheerd:

  • Create Profile
  • Delete Profile
  • Get Profile
  • Get Profiles
  • Update Profile

Een service-principalprofiel maken

Gebruik de bewerking Profiel REST API maken om een service-principalprofiel te maken. U moet de eigenschap in de hoofdtekst van de displayName aanvraag instellen om een weergavenaam voor de nieuwe tenant op te geven. De waarde moet uniek zijn voor alle profielen die eigendom zijn van de service-principal. De aanroep mislukt als er al een ander profiel met die weergavenaam bestaat voor de service-principal.

Een geslaagde aanroep retourneert de id eigenschap, een GUID die het profiel vertegenwoordigt. Wanneer u toepassingen ontwikkelt die gebruikmaken van service-principal-profielen, wordt u aangeraden profielweergavenamen en hun id-waarden op te slaan in een aangepaste database. Op die manier is het eenvoudig voor uw toepassing om de id's op te halen.

Als u programmeert met de .NET SDK van Power BI, kunt u de Profiles.CreateProfile methode gebruiken, die een ServicePrincipalProfile object retourneert dat het nieuwe profiel vertegenwoordigt. Het maakt het eenvoudig om de id eigenschapswaarde te bepalen.

Hier volgt een voorbeeld van het maken van een service-principalprofiel en het verlenen van toegang tot de werkruimte.

// Create a service principal profile
string profileName = "Contoso";

var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);

// Retrieve the ID of the new profile
Guid profileId = profile.Id;

// Grant workspace access
var groupUser = new GroupUser {
    GroupUserAccessRight = "Admin",
    PrincipalType = "App",
    Identifier = ServicePrincipalId,
    Profile = new ServicePrincipalProfile {
        Id = profileId
    }
};

pbiClient.Groups.AddGroupUser(workspaceId, groupUser);

In de Power BI-service kunt u in het deelvenster Toegang tot de werkruimte bepalen welke identiteiten, inclusief beveiligingsprincipaals, toegang hebben.

Schermopname van een schermopname van het deelvenster Toegang tot werkruimte. Er wordt een service-principalprofiel weergegeven met een weergavenaam van Contoso met beheerdersmachtigingen.

Een service-principalprofiel verwijderen

Gebruik de bewerking Profiel REST API verwijderen om een service-principalprofiel te verwijderen. Deze bewerking kan alleen worden aangeroepen door de bovenliggende service-principal.

Als u programmeert met de .NET SDK van Power BI, kunt u de Profiles.DeleteProfile methode gebruiken.

Alle service-principalprofielen ophalen

Gebruik de REST API-bewerking Profielen ophalen om een lijst met service-principalprofielen op te halen die deel uitmaken van de aanroepende service-principal. Met deze bewerking wordt een JSON-nettolading geretourneerd die de id en displayName eigenschappen van elk service-principalprofiel bevat.

Als u programmeert met de .NET SDK van Power BI, kunt u de methode Profiles.GetProfiles gebruiken.

REST API-aanroepen uitvoeren met behulp van een service-principalprofiel

Er zijn twee vereisten voor het maken van REST API-aanroepen met behulp van een service-principalprofiel:

  • U moet het toegangstoken doorgeven voor de bovenliggende service-principal in de autorisatie-header .
  • U moet een header met de naam X-PowerBI-profile-id opnemen met de waarde van de id van het service-principal-profiel.

Als u de .NET SDK van Power BI gebruikt, kunt u de headerwaarde X-PowerBI-profile-id expliciet instellen door de id van het service-principal-profiel door te geven.

// Create the Power BI client
var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBIClient(uriPowerBiServiceApiRoot, tokenCredentials);

// Add X-PowerBI-profile-id header for service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
pbiClient.HttpClient.DefaultRequestHeaders.Add("X-PowerBI-profile-id", profileId);

// Retrieve workspaces by using the identity of service principal profile
var workspaces = pbiClient.Groups.GetGroups();

Zoals u in het bovenstaande voorbeeld ziet, kunt u, nadat u de header X-PowerBI-profile-id aan het PowerBIClient object hebt toegevoegd, eenvoudig methoden aanroepen, zoals Groups.GetGroups, zodat deze worden uitgevoerd met behulp van het service-principal-profiel.

Er is een handigere manier om de X-PowerBI-profile-id-header voor een PowerBIClient object in te stellen. U kunt het object initialiseren door de id van het profiel door te geven aan de constructor.

// Create the Power BI client
string profileId = "11111111-1111-1111-1111-111111111111";

var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBiClient(uriPowerBiServiceApiRoot, tokenCredentials, profileId);

Wanneer u een multitenancy-toepassing programmeert, moet u waarschijnlijk schakelen tussen het uitvoeren van aanroepen als de bovenliggende service-principal en het uitvoeren van aanroepen als een service-principalprofiel. Een handige benadering voor het beheren van contextwisselingen is het declareren van een variabele op klasseniveau waarin het PowerBIClient object wordt opgeslagen. Vervolgens kunt u een helpermethode maken waarmee de variabele wordt ingesteld met het juiste object.

// Class-level variable that stores the PowerBIClient object
private PowerBIClient pbiClient;

// Helper method that sets the correct PowerBIClient object
private void SetCallingContext(string profileId = "") {

    if (profileId.Equals("")) {
        pbiClient = GetPowerBIClient();    
    }
    else {
        pbiClient = GetPowerBIClientForProfile(new Guid(profileId));
    }
}

Wanneer u een service-principalprofiel moet maken of beheren, kunt u de SetCallingContext methode zonder parameters aanroepen. Op deze manier kunt u profielen maken en beheren met behulp van de identiteit van de service-principal.

// Always create and manage profiles as the service principal
SetCallingContext();

// Create a service principal profile
string profileName = "Contoso";

var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);

Wanneer u een werkruimte moet maken en instellen voor een nieuwe klanttenant, wilt u die code uitvoeren als een service-principalprofiel. Daarom moet u de SetCallingContext methode aanroepen door de id van het profiel door te geven. Op deze manier kunt u de werkruimte maken met behulp van de identiteit van het service-principal-profiel.

// Always create and set up workspaces as a service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
SetCallingContext(profileId);

// Create a workspace
GroupCreationRequest request = new GroupCreationRequest(workspaceName);
Group workspace = pbiClient.Groups.CreateGroup(request);

Nadat u een specifiek service-principalprofiel hebt gebruikt om een werkruimte te maken en te configureren, moet u hetzelfde profiel blijven gebruiken om de inhoud van de werkruimte te maken en in te stellen. U hoeft de SetCallingContext methode niet aan te roepen om de installatie te voltooien.

Voorbeeld van ontwikkelaars

We raden u aan een voorbeeldtoepassing met de naam AppOwnsDataMultiTenant te downloaden.

Deze voorbeeldtoepassing is ontwikkeld met behulp van .NET 6 en ASP.NET en laat zien hoe u de richtlijnen en aanbevelingen kunt toepassen die in dit artikel worden beschreven. U kunt de code bekijken voor meer informatie over het ontwikkelen van een multitenancy-toepassing waarmee het insluiten voor uw klantscenario wordt geïmplementeerd met behulp van service-principalprofielen.

Gerelateerde inhoud

Raadpleeg de volgende bronnen voor meer informatie over dit artikel: