Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
Bruk dedikerte Microsoft Entra tjenestekontohavere for kundeidentiteter for nye løsninger for multitenancy. Der verts- og klareringskravene passer til løsningen, kan du bruke administrert identitet og legitimasjon for organisasjonsbasert identitet til å godkjenne disse kundeprogrammene uten å lagre klienthemmelighetene eller sertifikatets private nøkler.
Tjenestekontohaverprofiler forblir en gyldig, valgfri løsning for nye og eksisterende Power BI Embedded programmer med krav som passer deres fordeler og begrensninger. De er ikke avskrevet. Hvis den eksisterende profilbaserte løsningen oppfyller kravene dine, kan du fortsette å bruke den.
Denne artikkelen hjelper deg med å velge en identitetsmodell og finne riktig konfigurasjonsveiledning. En kunde er en logisk kunde- eller autorisasjonsgrense i programmet, ikke nødvendigvis en separat Microsoft Entra leier.
Anbefalt modell: Dedikerte kundeservicekontohavere
Opprett en programregistrering og tjenestekontohaver for hver grense for kundeautorisasjon. Gi denne hovedkontohavertilgangen bare til kundens tillatte arbeidsområder og ressurser. Dedikerte hovedstoler gir uavhengige Microsoft Entra påloggingsposter, katalogadministrasjon og tilgang til tjenester som støtter disse identitetene.
Der du er kvalifisert og lisensiert, kan du bruke arbeidsbelastningsidentitet betinget tilgang direkte til kundeservicekontohavere. Oppretting av en hovedstol gir ikke automatisk tilgang eller aktiverer ikke-støttet API-operasjon. Kontroller identitetsstøtte og tillatelseskrav for hver måltjeneste.
Velg en autentiseringsmetode
Det anbefalte godkjenningsmønsteret bruker en brukertilordet administrert identitet på programmets støttede Azure databehandlingsressurs som en deklarasjonskilde. En legitimasjon for organisasjonsbasert identitet for hver kundeprogramregistrering klarerer den administrerte identiteten. Ved kjøring utveksler programmet den administrerte identitetsdeklarasjonen for et ressurstilgangstoken som representerer den valgte kundeservicekontohaveren.
Dette mønsteret fjerner behovet for å lagre og rotere kundeprogramhemmeligheter eller sertifikater. Det eliminerer ikke programregistrering, klareringsadministrasjon, ressurstillatelser eller livssyklusadministrasjon for kundeidentitet.
Den administrerte identiteten og programregistreringene som klarerer den, må tilhøre den samme Microsoft Entra katalogleieren. Målressurser i en annen leier har ytterligere krav til programkonfigurasjon, samtykke og tillatelser. Kryssskytokenutveksling støttes ikke. Se mønster- og klareringskravene.
Hvis du ikke vil bruke administrert identitet og forbund, godkjenner du de dedikerte kundeprogrammene direkte med sertifikater eller en annen støttet programlegitimasjon. Beskytt lagret legitimasjon og automatiser rotasjon. Se alternativet for direkte godkjenning.
Planlegg godkjenning og skalering
Verken dedikerte hovedstoler eller profiler oppretter automatisk kryptografisk kundeisolasjon. En delt kjøretidsadministrert identitet kan godkjennes som alle kundeprogrammer som klarerer den. På samme måte kan en kjøretid med tilgang til flere lagrede kundelegitimasjoner bruke disse identitetene. Beskytt kjøretiden og løs kundens identitet og tillatte ressurser gjennom klarert konfigurasjon på serversiden.
Arbeidsområde- og ressurstillatelser fremtvinger tilgang. Konfigurer nødvendige leierinnstillinger og gi hver kundekontohaver de minst privilegerte ressursrollene som støttes. For innstillinger med gruppeomfang inkluderer du eksplisitt alle relevante hovedstoler i en tillatt sikkerhetsgruppe.
Dedikerte identiteter bruker Microsoft Entra katalogobjekter. Sammenlign kundeantallet med katalogkvoter, klargjøringstillatelser og gjennomstrømming, og hver tjenestes ressursgrenser. Automatiser pålasting, overvåking og avlasting. Ikke velg en identitetsmodell utelukkende fra antall programbrukere.
Alternativ modell: Tjenestekontohaverprofiler
Profiler gir lette kundekontekster under en overordnet tjenestekontohaver. Du kan opprette profiler uten separat Microsoft Entra programregistrering for hver kunde. En forelder kan opprette opptil 100 000 profiler, og hver profil kan få tilgang til eller opprette opptil 1000 arbeidsområder innenfor de dokumenterte grensene.
Profiler kan passe til programmer som verdsetter denne skalerings- og administrasjonsmodellen og ikke krever uavhengige Entra-identiteter for kundekontekstene. De støtter de dokumenterte Power BI REST-API-, .NET SDK- og XMLA/TOM-grensesnittene, men ikke Fabric REST-API-er. Profiler mangler også uavhengige Entra-påloggingsposter og arbeidsbelastningsidentitet per profil betinget tilgang, og forblir bundet til den overordnede.
En overordnet administrert identitet kan godkjennes uten lagrede programhemmeligheter, men gjør ikke profilene om til uavhengige Entra-identiteter eller utvideR API-støtten.
Evaluer fordelene og begrensningene til den valgfrie profilløsningen før du velger den. Separate kundearbeidsområder og semantiske modeller kan støtte en av identitetsmodellene. disse fordelene med datautforming er ikke eksklusive for profiler.
Finn den aktuelle implementeringsveiledningen
Bruk veiledningen som samsvarer med den valgte modellen og den gjeldende løsningen:
| Situasjon | Start her |
|---|---|
| Bygg en ny løsning med dedikerte kundekontohavere | Implementeringsveiledning. Profillageret og avviklingsfasene gjelder ikke for et nytt program. |
| Velg profiler for et nytt eller eksisterende program | Tjenestekontohaverprofiler: En valgfri løsning for multitenancy, etterfulgt av detaljert profilkonfigurasjon. |
| Bruk profilmodellen gjennom SDK | Power BI SDK- og tjenestekontohaverprofiler. |
| Eksisterende profiler oppfyller kravene dine | Fortsett å bruke dem og vedlikehold de nødvendige kontrollene for kunderuting, tillatelser og livssyklus. |
| Eksisterende profiler begrenser kravene dine | Erstatt tjenestekontohaverprofiler med tjenestekontohavere. |