Tjenesteprincipalprofiler til apps med flere brugere i Power BI Embedded

  • Artikel

I denne artikel forklares det, hvordan en ISV eller en hvilken som helst anden Power BI Embedded-appejer med mange kunder kan bruge tjenesteprincipalprofiler til at tilknytte og administrere hver enkelt kundes data som en del af deres Power BI-integrering for dine kunders løsning. Profiler for tjenesteprincipaler gør det muligt for ISV'en at bygge skalerbare programmer, der muliggør bedre isolering af kundedata og etablere strengere sikkerhedsgrænser mellem kunder. I denne artikel beskrives fordelene og begrænsningerne ved denne løsning.

Bemærk

Ordet lejer i Power BI kan nogle gange referere til en Microsoft Entra-lejer. I denne artikel bruger vi dog udtrykket multitenancy til at beskrive en løsning, hvor en enkelt forekomst af et softwareprogram betjener flere kunder eller organisationer (lejere), der kræver fysisk og logisk adskillelse af data. Power BI App Builder kan f.eks. tildele et separat arbejdsområde til hver af sine kunder (eller lejere), som vi viser nedenfor. Disse kunder er ikke nødvendigvis Microsoft Entra-lejere, så forveksler ikke udtrykket multitenantprogram , som vi bruger her, med Microsoft Entra multitenant-programmet.

En tjenesteprincipalprofil er en profil, der er oprettet af en tjenesteprincipal. ISV-appen kalder Power BI-API s ved hjælp af en tjenesteprincipalprofil, som beskrevet i denne artikel.

ISV-programtjenesteprincipalen opretter en anden Power BI-profil for hver kunde eller lejer. Når en kunde besøger ISV-appen, bruger appen den tilsvarende profil til at generere et integreringstoken , der bruges til at gengive en rapport i browseren.

Brug af tjenesteprincipalprofiler gør det muligt for ISV-appen at hoste flere kunder på en enkelt Power BI-lejer. Hver profil repræsenterer én kunde i Power BI. Med andre ord opretter og administrerer hver profil Power BI-indhold for én bestemt kundes data.

Diagram over SP-profiler og flerdimensionel.

Bemærk

Denne artikel henvender sig til organisationer, der vil konfigurere en multitenant-app ved hjælp af profiler for tjenesteprincipaler. Hvis din organisation allerede har en app, der understøtter multitenancy, og du vil migrere til profilmodellen for tjenesteprincipalen, skal du se Overfør til profilmodellen for tjenesteprincipaler.

Konfiguration af dit Power BI-indhold omfatter følgende trin:

Alle ovenstående trin kan automatiseres fuldt ud ved hjælp af REST API'er til Power BI.

Forudsætninger

Før du kan oprette profiler for tjenesteprincipaler, skal du:

  • Konfigurer tjenesteprincipalen ved at følge de første tre trin i Integrer Power BI-indhold med tjenesteprincipal.
  • Fra en Power BI-lejeradministratorkonto kan du aktivere oprettelse af profiler i lejeren ved hjælp af den samme sikkerhedsgruppe, du brugte, da du oprettede tjenesteprincipalen.

Skærmbillede af Administration portalkontakt.

Opret en profil

Profiler kan oprettes, opdateres og slettes ved hjælp af REST API'en Profiler.

Hvis du f.eks. vil oprette en 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"}

En tjenesteprincipal kan også kalde GET Profiles REST API for at få en liste over dens profiler. Eksempler:

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

Profiltilladelser

Alle API'er, der giver en bruger tilladelse til Power BI-elementer, kan også tildele en profiltilladelse til Power BI-elementer. Tilføj gruppebruger-API kan f.eks. bruges til at tildele en profiltilladelse til et arbejdsområde.

Følgende punkter er vigtige at forstå, når du bruger profiler:

  • En profil tilhører den tjenesteprincipal, der oprettede den, og kan kun bruges af den pågældende tjenesteprincipal.
  • En profilejer kan ikke ændres efter oprettelsen.
  • En profil er ikke en separat identitet. Den skal bruge tjenesteprincipalen Microsoft Entra-token for at kunne kalde REST API'er til Power BI.

ISV-apps kalder Power BI REST API'er ved at angive tjenesteprincipalen Microsoft Entra-token i godkendelsesheaderen og profil-id'et i headeren X-PowerBI-Profile-Id. Eksempler:

  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

Opret et arbejdsområde

Power BI-arbejdsområder bruges til at hoste Power BI-elementer, f.eks. rapporter og semantiske modeller.

Hver profil skal:

  • Opret mindst ét Power BI-arbejdsområde

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

  • Tildel adgangstilladelser til arbejdsområdet. Tjenesteprincipalprofilen skal have Administration adgang til arbejdsområdet.

  • Tildel arbejdsområdet til en kapacitet

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

Læs mere om Power BI-arbejdsområder.

Importér rapporter og semantiske modeller

Brug Power BI Desktop til at forberede rapporter, der er forbundet til kundens data eller eksempeldata. Derefter kan du bruge Import-API'en til at importere indholdet til det oprettede arbejdsområde.

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=

Brug parametre for datasæt til at oprette en semantisk model, der kan oprette forbindelse til forskellige kunders datakilder. Brug derefter API'en til opdateringsparametre til at definere, hvilke kunders data den semantiske model opretter forbindelse til.

Angiv den semantiske modelforbindelse

ISV'er gemmer normalt deres kunders data på to måder:

I begge tilfælde skal du ende med semantiske modeller med en enkelt lejer (én semantisk model pr. kunde) i Power BI.

En separat database for hver kunde

Hvis ISV-programmet har en separat database for hver kunde, skal du oprette semantiske modeller med en enkelt lejer i Power BI. Angiv hver semantisk model med forbindelsesoplysninger, der peger på den tilsvarende database. Brug en af følgende metoder til at undgå at oprette flere identiske rapporter med forskellige forbindelsesoplysninger:

  • Semantiske modelparametre: Opret en semantisk model med parametre i forbindelsesoplysningerne (f.eks. SQL-servernavn, SQL-databasenavn). Importér derefter en rapport til en kundes arbejdsområde, og rediger parametrene, så de stemmer overens med kundens databaseoplysninger.

  • Opdater Datakilde-API: Opret en .pbix, der peger på en datakilde med eksempelindhold. Importér derefter .pbix til en kundes arbejdsområde, og rediger forbindelsesoplysningerne ved hjælp af API'en Opdater datakilde.

En enkelt multitenantdatabase

Hvis ISV-programmet bruger én database til alle sine kunder, skal du adskille kunderne i forskellige semantiske modeller i Power BI på følgende måde:

Opret en rapport ved hjælp af parametre , der kun henter den relevante kundes data. Importér derefter en rapport til en kundes arbejdsområde, og rediger parametrene for kun at hente den relevante kundes data.

Integrer en rapport

Når konfigurationen er fuldført, kan du integrere kunderapporter og andre elementer i dit program ved hjælp af et integreringstoken.

Når en kunde besøger dit program, skal du bruge den tilsvarende profil til at kalde GenerateToken-API'en. Brug det genererede integreringstoken til at integrere en rapport eller andre elementer i kundens browser.

Sådan genererer du et integreringstoken:

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

Designaspekter

Før du konfigurerer en profilbaseret multitenantløsning, skal du være opmærksom på følgende problemer:

Skalérbarhed

Ved at adskille dataene i separate semantiske modeller for hver kunde minimerer du behovet for store semantiske modeller. Når kapaciteten overbelastes, kan den fjerne ubrugte semantiske modeller for at frigøre hukommelse til aktive semantiske modeller. Denne optimering er umulig for en enkelt stor semantisk model. Ved hjælp af flere semantiske modeller kan du også adskille lejere i flere Power BI-kapaciteter, hvis det er nødvendigt.

Uden profiler er en tjenesteprincipal begrænset til 1.000 arbejdsområder. For at overvinde denne grænse kan en tjenesteprincipal oprette flere profiler, hvor hver profil kan få adgang til/oprette op til 1.000 arbejdsområder. Med flere profiler kan ISV-appen isolere hver kundes indhold ved hjælp af forskellige logiske objektbeholdere.

Når en tjenesteprincipalprofil har adgang til et arbejdsområde, kan den overordnede tjenesteprincipals adgang til arbejdsområdet fjernes for at undgå skalerbarhedsproblemer.

Selv med disse fordele bør du overveje det potentielle omfang af dit program. Antallet af arbejdsområdeelementer, som en profil kan få adgang til, er f.eks. begrænset. I dag har en profil de samme grænser som en almindelig bruger. Hvis ISV-programmet giver slutbrugerne mulighed for at gemme en tilpasset kopi af deres integrerede rapporter, har en kundes profil adgang til alle de oprettede rapporter for alle dens brugere. Denne model kan med tiden overskride grænsen.

Automatisering og driftsmæssig kompleksitet

Med profilbaseret fratræden i Power BI skal du muligvis administrere hundred- eller tusindvis af elementer. Det er derfor vigtigt at definere de processer, der ofte sker i administrationen af programlivscyklussen, og sikre, at du har det rette sæt værktøjer til at udføre disse handlinger i stor skala. Nogle af disse handlinger omfatter:

  • Tilføjelse af en ny lejer
  • Opdatering af en rapport for nogle eller alle lejere
  • Opdaterer det semantiske modelskema for nogle eller alle lejere
  • Ikke-planlagte tilpasninger for bestemte lejere
  • Hyppigheden af semantiske modelopdateringer

Oprettelse af en profil og et arbejdsområde for en ny lejer er f.eks. en almindelig opgave, som kan automatiseresfuldt ud med Power BI REST-API'en.

Multi-Geo-behov

Multi-Geo-understøttelse af Power BI Embedded betyder, at ISV'er og organisationer, der bygger programmer ved hjælp af Power BI Embedded til at integrere analyser i deres apps, nu kan udrulle deres data i forskellige områder over hele verden. Hvis du vil understøtte forskellige kunder i forskellige områder, skal du tildele kundens arbejdsområde til en kapacitet i det ønskede område. Denne opgave er en simpel handling, der ikke medfører ekstra omkostninger. Men hvis du har kunder, der har brug for data fra flere områder, skal lejerprofilen duplikere alle elementer til flere arbejdsområder, der er tildelt forskellige regionale kapaciteter. Denne duplikering kan øge både omkostningerne og administrationens kompleksitet.

Af hensyn til overholdelse af angivne standarder kan du stadig oprette flere Power BI-lejere i forskellige områder. Læs mere om multi-geo.

Omkostningseffektivitet

Programudviklere, der bruger Power BI Embedded, skal købe en Power BI Embedded-kapacitet. Den profilbaserede adskillelsesmodel fungerer godt sammen med kapaciteter, fordi:

  • Det mindste objekt, du kan tildele uafhængigt af hinanden til en kapacitet, er et arbejdsområde (du kan f.eks. ikke tildele en rapport). Ved at adskille kunder efter profiler får du forskellige arbejdsområder – ét pr. kunde. På denne måde får du fuld fleksibilitet til at administrere hver enkelt kunde i henhold til deres ydeevnebehov og optimere kapacitetsudnyttelsen ved at skalere op eller ned. Du kan f.eks. administrere store og vigtige kunder med høj volumen og volatilitet i en separat kapacitet for at sikre et ensartet serviceniveau, samtidig med at mindre kunder grupperes i en anden kapacitet for at optimere omkostningerne.

  • Adskillelse af arbejdsområder betyder også adskillelse af semantiske modeller mellem lejere, så datamodeller er i mindre dele i stedet for en enkelt stor semantisk model. Disse mindre modeller gør det muligt for kapaciteten at administrere hukommelsesforbruget mere effektivt. Små, ubrugte semantiske modeller kan fjernes efter en periode med inaktivitet for at opretholde en god ydeevne.

Når du køber en kapacitet, skal du overveje grænsen for antallet af parallelle opdateringer, da opdateringsprocesser kan kræve ekstra kapacitet, når du har flere semantiske modeller.

Sikkerhed på rækkeniveau

I denne artikel forklares det, hvordan du bruger profiler til at oprette en separat semantisk model for hver kunde. Isv-programmer kan også gemme alle deres kunders data i én stor semantisk model og bruge sikkerhed på rækkeniveau (RLS) til at beskytte hver kundes data. Denne fremgangsmåde kan være praktisk for ISV'er, der har relativt få kunder og små til mellemstore semantiske modeller, fordi:

  • Der er kun én rapport og én semantisk model at vedligeholde
  • Onboardingprocessen for nye kunder kan forenkles

Før du bruger sikkerhed på rækkeniveau, skal du dog sørge for at forstå dens begrænsninger. Alle data for alle kunder er i én stor semantisk Power BI-model. Denne semantiske model kører i en enkelt kapacitet med sin egen skalering og andre begrænsninger.

Selvom du bruger tjenesteprincipalprofiler til at adskille dine kunders data, kan du stadig bruge sikkerhed på rækkeniveau i en enkelt kundes semantiske model til at give forskellige grupper adgang til forskellige dele af dataene. Du kan f.eks. bruge sikkerhed på rækkeniveau til at forhindre medlemmer af én afdeling i at få adgang til data fra en anden afdeling i samme organisation.

Overvejelser og begrænsninger

  • Tjenesteprincipalprofiler understøttes kun via Power BI REST API og Power BI .NET SDK. Tjenesteprincipalprofiler understøttes ikke i Power BI via XMLA-slutpunktet eller TOM (Tabular Object Model).
  • Tjenesteprincipalprofiler understøttes ikke med Azure Analysis Services (AAS) i liveforbindelsestilstand.

Begrænsninger for Power BI-kapacitet

Administrer tjenesteprincipaler

Skift en tjenesteprincipal

I Power BI tilhører en profil den tjenesteprincipal, der oprettede den. Det betyder, at en profil ikke kan deles med andre principaler. Med denne begrænsning skal du genoprette alle profiler og give de nye profiler adgang til de relevante arbejdsområder, hvis du af en eller anden grund vil ændre tjenesteprincipalen. ISV-programmet skal ofte gemme en tilknytning mellem et profil-id og et kunde-id for at kunne vælge den rigtige profil, når det er nødvendigt. Hvis du ændrer tjenesteprincipalen og opretter profilerne igen, ændres id'erne også, og du skal muligvis opdatere tilknytningen i ISV-programdatabasen.

Slet en tjenesteprincipal

Advarsel!

Vær meget forsigtig, når du sletter en tjenesteprincipal. Du ønsker ikke at miste data fra alle de tilknyttede profiler ved et uheld.

Hvis du sletter tjenesteprincipalen i active directory, slettes alle profilerne i Power BI. Power BI sletter dog ikke indholdet med det samme, så lejeradministratoren kan stadig få adgang til arbejdsområderne. Vær forsigtig, når du sletter en tjenesteprincipal, der bruges i et produktionssystem, især når du har oprettet profiler ved hjælp af denne tjenesteprincipal i Power BI. Hvis du sletter en tjenesteprincipal, der har oprettet profiler, skal du være opmærksom på, at du skal genoprette alle profilerne, give de nye profiler adgang til de relevante arbejdsområder og opdatere profil-id'erne i ISV-programdatabasen.

Dataadskillelse

Når data adskilles af tjenesteprincipalprofiler, forhindrer en simpel tilknytning mellem en profil og en kunde, at en kunde kan se en anden kundes indhold. Brug af en enkelt tjenesteprincipal kræver, at tjenesteprincipalen har adgang til alle de forskellige arbejdsområder i alle profilerne.

Hvis du vil tilføje ekstra adskillelse, skal du tildele en separat tjenesteprincipal til hver lejer i stedet for at have en enkelt tjenesteprincipal adgang til flere arbejdsområder ved hjælp af forskellige profiler. Tildeling af separate tjenesteprincipaler har flere fordele, herunder:

  • Menneskelige fejl eller en lækage af legitimationsoplysninger medfører ikke, at flere lejeres data vises.
  • Certifikatrotation kan udføres separat for hver lejer.

Men hvis du bruger flere tjenesteprincipaler, får du høje administrationsomkostninger. Vælg kun denne sti, hvis du har brug for den ekstra adskillelse. Vær opmærksom på, at konfigurationen af, hvilke data der skal vises en slutbruger, er defineret, når du genererer integreringstokenet, en backend-proces, som slutbrugerne ikke kan se eller ændre. Hvis du anmoder om et integreringstoken ved hjælp af en lejerspecifik profil, genereres der et integreringstoken for den pågældende specifikke profil, hvilket giver dig kundeadskillelse i forbrug.

Én rapport, flere semantiske modeller

Generelt har du én rapport og én semantisk model pr. lejer. Hvis du har hundredvis af rapporter, har du hundredvis af semantiske modeller. Nogle gange kan du have ét rapportformat med forskellige semantiske modeller (f.eks. forskellige parametre eller forbindelsesoplysninger). Hver gang du har en ny version af rapporten, skal du opdatere alle rapporter for alle lejere. Selvom du kan automatisere dette, er det nemmere at administrere, hvis du kun har én kopi af rapporten. Opret et arbejdsområde, der indeholder den rapport, der skal integreres. Under en session skal du binde rapporten til den lejerspecifikke semantiske model. Læs dynamiske bindinger for at få flere oplysninger.

Tilpasning og oprettelse af indhold

Når du opretter indhold, skal du nøje overveje, hvem der har tilladelse til at redigere det. Hvis du tillader, at flere brugere i hver lejer redigerer, er det nemt at overskride begrænsningerne for semantiske modeller. Hvis du beslutter dig for at give brugerne mulighed for at redigere, skal du overvåge deres indholdsgenerering nøje og skalere op efter behov. Af samme grund anbefaler vi ikke, at du bruger denne funktion til tilpasning af indhold, hvor hver bruger kan foretage små ændringer i en rapport og gemme den for sig selv. Hvis ISV-programmet tillader tilpasning af indhold, kan du overveje at introducere politikker for opbevaring af arbejdsområder for brugerspecifikt indhold. Opbevaringspolitikker gør det nemmere at slette indhold, når brugerne flytter til en ny stilling, forlader virksomheden eller holder op med at bruge platformen.

Systemadministrerede identiteter

I stedet for en tjenesteprincipal kan du bruge en brugertildelt eller systemtildeltadministreret identitet til at oprette profiler. Administrerede identiteter reducerer behovet for hemmeligheder og certifikater.

Vær forsigtig, når du bruger en systemadministrert identitet, fordi:

  • Hvis en administreret identitet, der er tildelt af systemet, ved et uheld er slået fra, mister du adgangen til profilerne. Denne situation svarer til et tilfælde, hvor en tjenesteprincipal slettes.
  • En systemtildelt administreret identitet er forbundet til en ressource i Azure (webapp). Hvis du sletter ressourcen, slettes identiteten.
  • Brug af flere ressourcer (forskellige webapps i forskellige områder) vil resultere i flere identiteter, der skal administreres separat (hver identitet har sine egne profiler).

På grund af ovenstående overvejelser anbefaler vi, at du bruger en brugertildelt administreret identitet.

Eksempel

Hvis du vil se et eksempel på, hvordan du bruger tjenesteprincipalprofiler til at administrere et multitenantmiljø med integration af Power BI og App-Owns-Data, skal du downloade appen ejer et lager med flere data fra Power BI Dev Camp (tredjepartswebsted).

Relateret indhold