Service-principalprofielen configureren voor multitenancy-toepassingen

In dit artikel wordt uitgelegd hoe u service-principalprofielen configureert en gebruikt nadat u deze hebt gekozen voor een Power BI Embedded insluiten voor uw klanten-oplossing. Profielen ondersteunen inhoudsbeheer op klantniveau en grote aantallen werkruimten. De scheiding van klanten is afhankelijk van de juiste routering van toepassingen, machtigingen voor werkruimten en embedtokens met het juiste bereik; profielen creëren geen onafhankelijke Microsoft Entra-identiteit of een cryptografische scheiding tussen klanten.

Notitie

Voor nieuwe multitenancy-oplossingen begint u met dedicated customerservice-principals, met behulp van beheerde identiteit en gefedereerde referenties waar dit past binnen de hosting- en vertrouwensvereisten. Profielen blijven een geldige, optionele oplossing voor nieuwe en bestaande toepassingen waarvan de vereisten passen bij hun voordelen en beperkingen. U kunt profielen blijven gebruiken als ze voldoen aan uw vereisten.

Profielen zijn niet Microsoft Entra identiteiten en kunnen niet worden gebruikt met Fabric REST API's. Als uw oplossing klantidentiteiten vereist voor downstreamservices, onafhankelijke Microsoft Entra-aanmeldingslogboeken, voorwaardelijke toegang voor workloadidentiteiten of mogelijkheden die anders worden beperkt door het profielmodel, kunt u overwegen om service-principalprofielen te vervangen door service-principals.

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 we in dit artikel bespreken. Deze klanten zijn niet noodzakelijkerwijs Microsoft Entra-tenants, dus verwar de term multitenant-toepassing die we hier gebruiken, niet met de Microsoft Entra-toepassing voor meerdere tenants.

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 weer te geven in de browser.

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 service-principalprofielen en multitenancy.

Notitie

Zie Service-principalprofielen: een optionele multitenancy-oplossing voor een overzicht van dit alternatief. De volgende configuratiestappen zijn van toepassing nadat u het profielmodel hebt geselecteerd.

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 serviceprincipalprofielen kunt maken, moet u het volgende doen:

Schermopname van de switch voor de beheerportal.

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 GET Profiles REST API aanroepen om een lijst van zijn 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 alleen die service-principal kan het gebruiken.
  • Een profieleigenaar kan niet worden gewijzigd na het maken.
  • Een profiel is geen zelfstandige identiteit. Het heeft het service-principal-token van Microsoft Entra nodig om Power BI REST API's aan te spreken.

ISV-apps roepen Power BI REST-API's aan door het service-principal-Microsoft-Entra-token op te geven in de Authorization-header 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 beheerderstoegang tot de werkruimte hebben.

  • De werkruimte toewijzen aan een capaciteit

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

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/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=

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 embedtoken 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 gebruik te maken van meerdere semantische modellen, kunt u indien nodig ook klanten scheiden in verschillende 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 inschakelen voor specifieke tenants
  • De frequentie van semantische modelvernieuwing instellen

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 in verschillende regio's maken. 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:

  • Ze hoeven slechts één rapport en één semantisch model te 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

Evalueer de identiteits-, API- en schaallimieten voordat u het profielmodel kiest of uitbreidt.

Beperkingen van identiteits- en API-functionaliteit

Bekijk deze beperkingen voordat u profielen gaat gebruiken of een bestaande oplossing op basis van een profiel uitbreidt:

Beperking Wat betekent het voor uw oplossing?
Geen Microsoft Entra-identiteit Een profiel bestaat alleen in Power BI. U kunt deze niet onafhankelijk beheren of beoordelen via Microsoft Entra hulpprogramma's of machtigingen verlenen als een identiteit in downstreamservices. Een profiel kan bijvoorbeeld niet de identiteit zijn van een Direct Lake-verbinding van een semantisch model naar een lakehouse of warehouse.
Geen Fabric REST API-ondersteuning Profielen werken via de Power BI REST API, Power BI .NET SDK en ondersteunde XMLA/TOM-interfaces. Fabric REST API's ondersteunen deze niet en ondersteuning is niet gepland.
Geen onafhankelijke aanmeldingsidentiteit Met bewerkingen binnen een profielbereik worden geen onafhankelijke Microsoft Entra-aanmeldingsrecords per klant geproduceerd. Power BI activiteitenlogboeken kunnen nog steeds profielen identificeren.
Geen voorwaardelijke toegang per profiel Een profiel is geen principal waarop Conditional Access voor workload identity kan worden gericht. Beleidsregels voor in aanmerking komende dedicated service-principals hebben afzonderlijke licentie- en configuratievereisten.
Gebonden aan de aanmakende principal U kunt geen profielen overdragen tussen bovenliggende service-principals. Als u het bovenliggende item wijzigt, moet u profielen opnieuw maken, werkruimtetoegang herstellen en klanttoewijzingen bijwerken.
Alleen API-beheer Profielen hebben geen afzonderlijke beheerdersinterface om ze te controleren en te beheren. Ze worden niet weergegeven in het Microsoft Entra-beheercentrum.

Als deze beperkingen uw oplossing beperken, zie Service-principalprofielen vervangen door service-principals. Voor klanten die ervoor kiezen om te migreren, raadt die handleiding beheerde identiteit en federatieve aanmeldingsgegevens aan wanneer aan de vereisten voor hosting en vertrouwen wordt voldaan. Directe authenticatie van de service-principal blijft een alternatief.

Ondersteunde interfaces en schaallimieten

  • Service-principalprofielen worden alleen ondersteund via de Power BI REST API, de Power BI .NET SDK en via het XMLA-eindpunt en het TOM (Tabular Object Model) bij het gebruik van Analysis Services-clientbibliotheken versie 16.0.139.27 of hoger. Service-principalprofielen worden niet ondersteund in Power BI via het XMLA-eindpunt of het Tabellaire objectmodel (TOM) met oudere clientbibliotheken.
  • Service-principalprofielen worden niet ondersteund met Azure Analysis Services (AAS) in de liveverbindingsmodus.
  • De maximale profielen die één service-principal kan hebben, is 100.000.

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. Vanwege deze beperking, 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, veranderen de id's ook, en moet u mogelijk de koppeling in de ISV-toepassingsdatabase bijwerken.

Een service-principal verwijderen

Waarschuwing

Wees 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 bijbehorende profielen in Power BI verwijderd. Power BI verwijdert de inhoud echter niet onmiddellijk, 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 in de ISV-toepassingsdatabase bijwerken.

Gegevensscheiding

Wanneer u service-principalprofielen gebruikt, moet uw toepassing elke geverifieerde klant koppelen aan het juiste profiel en toegestane resources. Werkruimtemachtigingen en embedtokens met de juiste scope dwingen toegang af. Een profiel is geen onafhankelijke Microsoft Entra-identiteit en de bovenliggende service-principal kan via elk profiel dat deze maakt optreden.

Overweeg speciale service-principals wanneer voor uw oplossing Microsoft Entra governance, onafhankelijke aanmeldingscontrole, beleid voor voorwaardelijke toegang voor in aanmerking komende workloadidentiteiten, downstreamservice-identiteiten of Fabric REST API-toegang is vereist. Ze zijn ook een alternatief wanneer profiel-naar-parent-koppeling of API-beheer operationele problemen veroorzaakt. Als profielen aan uw vereisten voldoen, kunt u deze blijven gebruiken.

Met toegewezen service-principals kunt u klantmachtigingen en verificatie onafhankelijk beheren. Als u opgeslagen certificaten gebruikt, kunt u deze afzonderlijk roteren voor elke klant. De impact van een lek van inloggegevens of runtime-inbreuk is echter afhankelijk van welke klantreferenties of federatieve vertrouwensrelaties de runtime kan gebruiken. Geen van beide architecturen garandeert automatisch isolatie tussen klanten.

Het beheren van specifieke identiteiten introduceert limieten voor directory-objecten en levenscycluswerkzaamheden. Evalueer deze afwegingen en volg Service-principalprofielen vervangen door service-principals als u ervoor kiest om te migreren. Bewaar de configuratie van welke gegevens aan een eindgebruiker in de back-end worden weergegeven wanneer u het insluittoken genereert. Valideer het klantlidmaatschap voordat u een identiteit, werkruimte of inhoud selecteert.

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 proces 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.

Notitie

Een beheerde identiteit die profielen maakt en gebruikt, verandert deze profielen niet in Microsoft Entra-identiteiten of maakt het gebruik ervan met Fabric REST API's niet mogelijk. Deze situatie verschilt van het gebruik van beheerde identiteiten en gefedereerde referenties om te verifiëren als toegewezen service-principals van klanten. Zie Service-principalprofielen vervangen door service-principals.

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

  • Als een door het systeem toegewezen beheerde identiteit per ongeluk wordt 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 ook 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.

Voorbeeld

Voor een voorbeeld van hoe u service-principalprofielen kunt gebruiken om een multitenant-omgeving te beheren met Power BI en App-Owns-Data embedding, downloadt u de App-Owns-Data-multitenant-repository van Power BI Dev Camp (een externe site).

Gerelateerde inhoud

  • Laatst bijgewerkt om