Service-principalprofielen voor multitenancy-apps in Power BI Embedded

  • Artikel

In dit artikel wordt uitgelegd hoe een ISV of een andere eigenaar van een Power BI Embedded-app met veel klanten service-principalprofielen kan gebruiken om de gegevens van elke klant toe te wijzen en te beheren als onderdeel van hun Power BI-insluiting voor uw klantenoplossing. Met service-principalprofielen kan de ISV schaalbare toepassingen bouwen die betere isolatie van klantgegevens mogelijk maken en betere beveiligingsgrenzen tussen klanten tot stand brengen. In dit artikel worden de voordelen en beperkingen van deze oplossing besproken.

Notitie

Het woord tenant in Power BI kan soms verwijzen naar een Microsoft Entra-tenant. In dit artikel gebruiken we echter de term multitenancy om een oplossing te beschrijven waarbij één exemplaar van een softwaretoepassing meerdere klanten of organisaties (tenants) bedient waarvoor fysieke en logische scheiding van gegevens is vereist. De opbouwfunctie voor Power BI-apps kan bijvoorbeeld een afzonderlijke werkruimte toewijzen voor elk van de klanten (of tenants), zoals hieronder wordt weergegeven. Deze klanten zijn niet noodzakelijkerwijs Microsoft Entra-tenants, dus verwar de term multitenant-toepassing die we hier gebruiken, niet met de Microsoft Entra multitenant-toepassing.

Een service-principalprofiel is een profiel dat is gemaakt door een service-principal. De ISV-app roept de API van Power BI s aan met behulp van een service-principalprofiel, zoals wordt uitgelegd in dit artikel.

De SERVICE-principal van de ISV-toepassing maakt een ander Power BI-profiel voor elke klant of tenant. Wanneer een klant de ISV-app bezoekt, gebruikt de app het bijbehorende profiel om een insluittoken te genereren dat wordt gebruikt om een rapport in de browser weer te geven.

Met behulp van service-principalprofielen kan de ISV-app meerdere klanten hosten op één Power BI-tenant. Elk profiel vertegenwoordigt één klant in Power BI. Met andere woorden, elk profiel maakt en beheert Power BI-inhoud voor de gegevens van een specifieke klant.

Diagram van SP-profielen en multitenancy.

Notitie

Dit artikel is bedoeld voor organisaties die een app met meerdere tenants willen instellen met behulp van service-principalprofielen. Als uw organisatie al een app heeft die ondersteuning biedt voor multitenancy en u wilt migreren naar het profielmodel van de service-principal, raadpleegt u Migreren naar het model voor service-principalprofielen.

Het instellen van uw Power BI-inhoud omvat de volgende stappen:

Alle bovenstaande stappen kunnen volledig worden geautomatiseerd met power BI REST API's.

Vereisten

Voordat u service-principalprofielen kunt maken, moet u het volgende doen:

  • Stel de service-principal in door de eerste drie stappen van Power BI-inhoud in te sluiten met een service-principal.
  • Schakel vanuit een Power BI-tenantbeheerdersaccount het maken van profielen in de tenant in met dezelfde beveiligingsgroep die u hebt gebruikt toen u de service-principal maakte.

Schermopname van Beheer portalswitch.

Een profiel maken

Profielen kunnen worden gemaakt, bijgewerkt en verwijderd met behulp van de REST API van Profielen.

Als u bijvoorbeeld een profiel wilt maken:

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"}

Een service-principal kan ook DE REST API GET-profielen aanroepen om een lijst met de profielen op te halen. Voorbeeld:

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

Profielmachtigingen

Elke API die een gebruikersmachtiging verleent aan Power BI-items, kan ook een profielmachtiging verlenen aan Power BI-items. U kunt bijvoorbeeld groepsgebruikers-API toevoegen om een profielmachtiging toe te kennen aan een werkruimte.

De volgende punten zijn belangrijk om te begrijpen wanneer u profielen gebruikt:

  • Een profiel behoort tot de service-principal die het heeft gemaakt en kan alleen worden gebruikt door die service-principal.
  • Een profieleigenaar kan niet worden gewijzigd na het maken.
  • Een profiel is geen zelfstandige identiteit. Het heeft de service-principal Microsoft Entra-token nodig om Power BI REST API's aan te roepen.

ISV-apps roepen Power BI REST API's aan door de service-principal Microsoft Entra-token op te geven in de autorisatieheader en de profiel-id in de X-PowerBI-Profile-Id-header . Voorbeeld:

  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

Een werkruimte maken

Power BI-werkruimten worden gebruikt voor het hosten van Power BI-items, zoals rapporten en semantische modellen.

Elk profiel moet:

  • Ten minste één Power BI-werkruimte maken

    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"
}

  • Toegangsmachtigingen verlenen aan de werkruimte. Het service-principal-profiel moet Beheer toegang hebben tot de werkruimte.

  • De werkruimte toewijzen aan een capaciteit

    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"
}

Meer informatie over Power BI-werkruimten.

Rapporten en semantische modellen importeren

Gebruik Power BI Desktop om rapporten voor te bereiden die zijn verbonden met de gegevens of voorbeeldgegevens van de klant. Vervolgens kunt u de Import-API gebruiken om de inhoud te importeren in de gemaakte werkruimte.

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=

Gebruik gegevenssetparameters om een semantisch model te maken dat verbinding kan maken met de gegevensbronnen van verschillende klanten. Gebruik vervolgens de API updateparameters om te definiëren met welke gegevens van klanten het semantische model verbinding maakt.

De semantische modelverbinding instellen

ISV's slaan de gegevens van hun klanten meestal op twee manieren op:

In beide gevallen moet u eindigen met semantische modellen met één tenant (één semantisch model per klant) in Power BI.

Een afzonderlijke database voor elke klant

Als de ISV-toepassing een afzonderlijke database voor elke klant heeft, maakt u semantische modellen met één tenant in Power BI. Geef elk semantisch model op met verbindingsdetails die verwijzen naar de overeenkomende database. Gebruik een van de volgende methoden om te voorkomen dat u meerdere identieke rapporten met verschillende verbindingsgegevens maakt:

  • Semantische modelparameters: maak een semantisch model met parameters in de verbindingsgegevens (zoals sql-servernaam, SQL-databasenaam). Importeer vervolgens een rapport in de werkruimte van een klant en wijzig de parameters zodat deze overeenkomen met de databasegegevens van de klant.

  • Gegevensbron-API bijwerken: maak een PBIX die verwijst naar een gegevensbron met voorbeeldinhoud. Importeer vervolgens het PBIX-bestand in de werkruimte van een klant en wijzig de verbindingsgegevens met behulp van de Api Voor gegevensbron bijwerken.

Eén multitenant-database

Als de ISV-toepassing één database gebruikt voor alle klanten, scheidt u de klanten als volgt in verschillende semantische modellen in Power BI:

Maak een rapport met behulp van parameters waarmee alleen de relevante klantgegevens worden opgehaald. Importeer vervolgens een rapport in de werkruimte van een klant en wijzig de parameters om alleen de relevante klantgegevens op te halen.

Een rapport insluiten

Nadat de installatie is voltooid, kunt u klantrapporten en andere items in uw toepassing insluiten met behulp van een insluittoken.

Wanneer een klant uw toepassing bezoekt, gebruikt u het bijbehorende profiel om de GenerateToken-API aan te roepen. Gebruik het gegenereerde insluittoken om een rapport of andere items in te sluiten in de browser van de klant.

Een insluittoken genereren:

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"
    }
  ]
}

Ontwerpaspecten

Voordat u een op een profiel gebaseerde multitenant-oplossing instelt, moet u rekening houden met de volgende problemen:

Schaalbaarheid

Door de gegevens te scheiden in afzonderlijke semantische modellen voor elke klant, minimaliseert u de behoefte aan grote semantische modellen. Wanneer de capaciteit overbelast raakt, kunnen ongebruikte semantische modellen worden verwijderd om geheugen vrij te maken voor actieve semantische modellen. Deze optimalisatie is onmogelijk voor één groot semantisch model. Door meerdere semantische modellen te gebruiken, kunt u indien nodig tenants ook scheiden in meerdere Power BI-capaciteiten.

Zonder profielen is een service-principal beperkt tot 1000 werkruimten. Om deze limiet te overwinnen, kan een service-principal meerdere profielen maken, waar elk profiel toegang heeft tot maximaal 1000 werkruimten. Met meerdere profielen kan de ISV-app de inhoud van elke klant isoleren met behulp van afzonderlijke logische containers.

Zodra een service-principalprofiel toegang heeft tot een werkruimte, kan de toegang van de bovenliggende service-principal tot de werkruimte worden verwijderd om schaalbaarheidsproblemen te voorkomen.

Zelfs met deze voordelen moet u rekening houden met de mogelijke schaal van uw toepassing. Het aantal werkruimte-items dat een profiel kan openen, is bijvoorbeeld beperkt. Tegenwoordig heeft een profiel dezelfde limieten als een gewone gebruiker. Als de ISV-toepassing eindgebruikers toestaat een gepersonaliseerde kopie van hun ingesloten rapporten op te slaan, heeft het profiel van een klant toegang tot alle gemaakte rapporten van alle gebruikers. Dit model kan uiteindelijk de limiet overschrijden.

Automatisering en operationele complexiteit

Met scheiding op basis van Power BI-profielen moet u mogelijk honderden of duizenden items beheren. Daarom is het belangrijk om de processen te definiëren die vaak plaatsvinden in het levenscyclusbeheer van uw toepassing en ervoor te zorgen dat u over de juiste set hulpprogramma's beschikt om deze bewerkingen op schaal uit te voeren. Enkele van deze bewerkingen zijn:

  • Een nieuwe tenant toevoegen
  • Een rapport voor sommige of alle tenants bijwerken
  • Het semantische modelschema voor sommige of alle tenants bijwerken
  • Niet-geplande aanpassingen voor specifieke tenants
  • Frequentie van semantische modelvernieuwing

Het maken van een profiel en een werkruimte voor een nieuwe tenant is bijvoorbeeld een algemene taak, die volledig kan worden geautomatiseerd met de Power BI REST API.

Multi-Geo-behoeften

Ondersteuning voor meerdere geografische gebieden voor Power BI Embedded betekent dat ISV's en organisaties die toepassingen bouwen met Power BI Embedded om analyses in te sluiten in hun apps nu hun gegevens kunnen implementeren in verschillende regio's over de hele wereld. Als u verschillende klanten in verschillende regio's wilt ondersteunen, wijst u de werkruimte van de klant toe aan een capaciteit in de gewenste regio. Deze taak is een eenvoudige bewerking die geen extra kosten met zich meebrengt. Als u echter klanten hebt die gegevens uit meerdere regio's nodig hebben, moet het tenantprofiel alle items dupliceren in meerdere werkruimten die zijn toegewezen aan verschillende regionale capaciteiten. Deze duplicatie kan zowel de complexiteit van kosten als het beheer verhogen.

Om nalevingsredenen wilt u mogelijk nog steeds meerdere Power BI-tenants maken in verschillende regio's. Meer informatie over meerdere geografische gebieden.

Kostenefficiëntie

Toepassingsontwikkelaars die Power BI Embedded gebruiken, moeten een Power BI Embedded-capaciteit aanschaffen. Het op profielen gebaseerde scheidingsmodel werkt goed met capaciteiten omdat:

  • Het kleinste object dat u onafhankelijk aan een capaciteit kunt toewijzen, is een werkruimte (u kunt bijvoorbeeld geen rapport toewijzen). Door klanten te scheiden op profielen, krijgt u verschillende werkruimten: één per klant. Op deze manier krijgt u volledige flexibiliteit om elke klant te beheren op basis van hun prestatiebehoeften en het capaciteitsgebruik te optimaliseren door omhoog of omlaag te schalen. U kunt bijvoorbeeld grote en essentiële klanten beheren met een hoog volume en volatiliteit in een afzonderlijke capaciteit om een consistent serviceniveau te garanderen, terwijl u kleinere klanten in een andere capaciteit groepeert om de kosten te optimaliseren.

  • Het scheiden van werkruimten betekent ook het scheiden van semantische modellen tussen tenants, zodat gegevensmodellen zich in kleinere segmenten bevinden, in plaats van één groot semantisch model. Deze kleinere modellen maken het mogelijk om het geheugengebruik efficiënter te beheren. Kleine, ongebruikte semantische modellen kunnen na een periode van inactiviteit worden verwijderd om goede prestaties te behouden.

Houd bij het kopen van een capaciteit rekening met de limiet voor het aantal parallelle vernieuwingen, omdat vernieuwingsprocessen mogelijk extra capaciteit nodig hebben wanneer u meerdere semantische modellen hebt.

De beveiliging op rijniveau

In dit artikel wordt uitgelegd hoe u profielen gebruikt om voor elke klant een afzonderlijk semantisch model te maken. Daarnaast kunnen ISV-toepassingen alle gegevens van hun klanten opslaan in één groot semantisch model en beveiliging op rijniveau (RLS) gebruiken om de gegevens van elke klant te beveiligen. Deze benadering kan handig zijn voor ISV's met relatief weinig klanten en kleine tot middelgrote semantische modellen, omdat:

  • Er is slechts één rapport en één semantisch model dat moet worden onderhouden
  • Het onboardingproces voor nieuwe klanten kan worden vereenvoudigd

Voordat u RLS gebruikt, moet u echter weten wat de beperkingen zijn. Alle gegevens voor alle klanten bevinden zich in één groot semantisch Power BI-model. Dit semantische model wordt uitgevoerd in één capaciteit met een eigen schaalaanpassing en andere beperkingen.

Zelfs als u service-principalprofielen gebruikt om de gegevens van uw klanten te scheiden, kunt u RLS nog steeds gebruiken binnen het semantische model van één klant om verschillende groepen toegang te geven tot verschillende delen van de gegevens. U kunt bijvoorbeeld RLS gebruiken om te voorkomen dat leden van een afdeling toegang hebben tot gegevens van een andere afdeling in dezelfde organisatie.

Overwegingen en beperkingen

  • Service-principalprofielen worden alleen ondersteund via de Power BI REST API en de Power BI .NET SDK. Service-principalprofielen worden niet ondersteund in Power BI via het XMLA-eindpunt of het Tabellaire objectmodel (TOM).
  • Service-principalprofielen worden niet ondersteund met Azure Analysis Services (AAS) in de liveverbindingsmodus.

Power BI-capaciteitsbeperkingen

Service-principals beheren

Een service-principal wijzigen

In Power BI behoort een profiel tot de service-principal die het heeft gemaakt. Dat betekent dat een profiel niet kan worden gedeeld met andere principals. Als u de service-principal om welke reden dan ook wilt wijzigen, moet u alle profielen opnieuw maken en de nieuwe profielen toegang geven tot de relevante werkruimten. Vaak moet de ISV-toepassing een toewijzing opslaan tussen een profiel-id en een klant-id om het juiste profiel te kiezen wanneer dat nodig is. Als u de service-principal wijzigt en de profielen opnieuw maakt, worden de id's ook gewijzigd en moet u de toewijzing mogelijk bijwerken in de ISV-toepassingsdatabase.

Een service-principal verwijderen

Waarschuwing

Wees erg voorzichtig bij het verwijderen van een service-principal. U wilt niet per ongeluk gegevens van alle bijbehorende profielen kwijtraken.

Als u de service-principal in de Active Directory verwijdert, worden alle profielen in Power BI verwijderd. De inhoud wordt echter niet onmiddellijk verwijderd in Power BI, zodat de tenantbeheerder nog steeds toegang heeft tot de werkruimten. Wees voorzichtig bij het verwijderen van een service-principal die wordt gebruikt in een productiesysteem, met name wanneer u profielen hebt gemaakt met behulp van deze service-principal in Power BI. Als u een service-principal verwijdert die profielen heeft gemaakt, moet u alle profielen opnieuw maken, de nieuwe profielen toegang geven tot de relevante werkruimten en de profiel-id's bijwerken in de ISV-toepassingsdatabase.

Gegevensscheiding

Wanneer gegevens worden gescheiden door service-principalprofielen, voorkomt een eenvoudige toewijzing tussen een profiel en de klant dat de ene klant de inhoud van een andere klant ziet. Als u één service-principal gebruikt, moet de service-principal toegang hebben tot alle verschillende werkruimten in alle profielen.

Als u extra scheiding wilt toevoegen, wijst u een afzonderlijke service-principal toe aan elke tenant in plaats van dat één service-principal toegang heeft tot meerdere werkruimten met behulp van verschillende profielen. Het toewijzen van afzonderlijke service-principals heeft verschillende voordelen, waaronder:

  • Menselijke fout of een referentielek zorgt er niet voor dat de gegevens van meerdere tenants worden weergegeven.
  • Certificaatrotatie kan afzonderlijk worden uitgevoerd voor elke tenant.

Het gebruik van meerdere service-principals wordt echter geleverd met hoge beheerkosten. Selecteer dit pad alleen als u de extra scheiding nodig hebt. Houd er rekening mee dat de configuratie van welke gegevens voor het weergeven van een eindgebruiker wordt gedefinieerd wanneer u het insluittoken genereert, een proces met alleen back-end dat eindgebruikers niet kunnen zien of wijzigen. Als u een insluittoken aanvraagt met behulp van een tenantspecifiek profiel, wordt er een insluittoken voor dat specifieke profiel gegenereerd, waardoor u klantscheiding in verbruik krijgt.

Eén rapport, meerdere semantische modellen

Over het algemeen hebt u één rapport en één semantisch model per tenant. Als u honderden rapporten hebt, hebt u honderden semantische modellen. Soms hebt u mogelijk één rapportindeling, met verschillende semantische modellen (bijvoorbeeld verschillende parameters of verbindingsgegevens). Telkens wanneer u een nieuwe versie van het rapport hebt, moet u alle rapporten voor alle tenants bijwerken. Hoewel u dit kunt automatiseren, is het eenvoudiger om te beheren als u slechts één exemplaar van het rapport hebt. Maak een werkruimte die het rapport bevat dat moet worden ingesloten. Bind het rapport tijdens een sessieruntime aan het tenantspecifieke semantische model. Lees dynamische bindingen voor meer informatie.

Inhoud aanpassen en ontwerpen

Wanneer u inhoud maakt, moet u zorgvuldig overwegen wie gemachtigd is om deze te bewerken. Als u meerdere gebruikers in elke tenant toestaat om te bewerken, is het eenvoudig om semantische modelbeperkingen te overschrijden. Als u besluit om gebruikers bewerkingsmogelijkheden te geven, controleert u de generatie van inhoud nauwkeurig en schaalt u indien nodig omhoog. Om dezelfde reden raden we u niet aan deze mogelijkheid te gebruiken voor het aanpassen van inhoud, waarbij elke gebruiker kleine wijzigingen in een rapport kan aanbrengen en voor zichzelf kan opslaan. Als de ISV-toepassing persoonlijke instellingen voor inhoud toestaat, kunt u overwegen om bewaarbeleid voor werkruimten te introduceren voor gebruikersspecifieke inhoud. Met bewaarbeleid kunt u gemakkelijker inhoud verwijderen wanneer gebruikers overstappen op een nieuwe positie, het bedrijf verlaten of het platform niet meer gebruiken.

Door het systeem beheerde identiteit

In plaats van een service-principal kunt u een door de gebruiker toegewezen of door het systeem toegewezenbeheerde identiteit gebruiken om profielen te maken. Beheerde identiteiten verminderen de noodzaak van geheimen en certificaten.

Wees voorzichtig bij het gebruik van een door het systeem beheerde identiteit, omdat:

  • Als een door het systeem toegewezen beheerde identiteit per ongeluk is uitgeschakeld, verliest u de toegang tot de profielen. Deze situatie is vergelijkbaar met een geval waarin een service-principal wordt verwijderd.
  • Een door het systeem toegewezen beheerde identiteit is verbonden met een resource in Azure (web-app). Als u de resource verwijdert, wordt de identiteit verwijderd.
  • Het gebruik van meerdere resources (verschillende web-apps in verschillende regio's) resulteert in meerdere identiteiten die afzonderlijk moeten worden beheerd (elke identiteit heeft zijn eigen profielen).

Vanwege de bovenstaande overwegingen raden we u aan een door de gebruiker toegewezen beheerde identiteit te gebruiken.

Opmerking

Voor een voorbeeld van het gebruik van service-principalprofielen voor het beheren van een omgeving met meerdere tenants met Power BI en App-Owns-Data embedding, downloadt u de app eigenaar van de gegevensopslagplaats voor meerdere tenants van Power BI Dev Camp (externe site).

Gerelateerde inhoud