Tjenestekontohaverprofiler: En valgfri løsning for multitenancy

Tjenestekontohaverprofiler er en valgfri løsning for Power BI Embedded multitenancy-programmer. De gir lette kundeprofiler og støtter et stort antall kundearbeidsområder uten å kreve en separat Microsoft Entra programregistrering for hver kunde.

For nye løsninger for multitenancy anbefaler vi dedikerte kundeservicekontohavere, godkjent gjennom administrert identitet og legitimasjon for organisasjonsbasert identitet der verts- og klareringskravene oppfylles.

Profiler er fortsatt et gyldig alternativ for nye og eksisterende programmer med krav som passer deres funksjoner. De er ikke avskrevet. Eksisterende programmer som er fornøyd med profiler, kan fortsette å bruke dem. Denne artikkelen forklarer fordelene, begrensningene og konfigurasjonen på høyt nivå. Hvis du vil ha eksempler på API, kan du se den detaljerte profilveiledningen.

Der tjenestekontohaverprofiler passer

Vurder profiler når programmet bruker grensesnittene som støttes, drar nytte av skalerings- og administrasjonsmodellen og kan godta identitets- og driftsbegrensningene. En kunde er en logisk kunde av programmet, ikke nødvendigvis en separat Microsoft Entra leier.

Fordel Hva det betyr for løsningen
Lette kundekontekster Opprett profiler under én overordnet uten separat programregistrering og tjenestekontohaver for hver kunde.
Skalering av arbeidsområde som støttes En forelder kan opprette opptil 100 000 profiler, hver med tilgang til opptil 1000 arbeidsområder. Evaluer også gjeldende ressurs- og kapasitetsgrenser.
Automatisert livssyklus Opprett og administrer profiler og klargjør kundeinnhold gjennom støttede REST-API-er.
Kundeomfang for innholdsadministrasjon Bruk kundeprofilen til å administrere arbeidsområdetillatelser, eierskap av semantisk modell og legitimasjon for datakilder. Riktig programruting og tillatelser er fortsatt viktig.

Profiler kan redusere klargjøring per kundekatalog, men likevel kreve automatisering av programlivssyklus. Det kan hende at et lite program ikke trenger skalamodellen. Hvis programmet allerede bruker dedikerte hovedstoler og oppfyller kravene, er det ikke nødvendig å bytte til profiler.

Begrensninger og avveininger

Evaluer disse begrensningene sammen med fordelene:

  • Profiler er ikke uavhengige Microsoft Entra identiteter og produserer ikke uavhengige per kunde Entra-påloggingsposter.
  • Profiler kan ikke motta policyer for betinget tilgang for arbeidsbelastning eller nedstrøms tjenestetillatelser som uavhengige Entra-identiteter.
  • Profiler støtter ikke Fabric REST-API-er. Kontroller støttede grensesnitt og skalagrenser.
  • Profiler forblir bundet til å opprette overordnede og har API-administrasjon.
  • Forelderen kan handle gjennom alle profilene sine. Profiler oppretter ikke kryptografisk kundeisolasjon.

Hvis du vil ha fullstendige begrensninger, kan du se Begrensninger for identitet og API. Dedikerte hovedstoler krever også planlegging av katalogkapasitet og livssyklusadministrasjon. ingen av identitetsmodellene erstatter ressurstillatelser eller sikker kunderuting.

Separate kundearbeidsområder og semantiske modeller kan forbedre kapasitetsstyringen i begge identitetsmodellene. Disse fordelene krever ikke profiler. Hvis et eksisterende profilbasert program trenger funksjoner utenfor profilmodellen, kan du se Erstatte tjenestekontohaverprofiler med tjenestekontohavere.

Slik fungerer profilmodellen

Programmets overordnede tjenestekontohaver oppretter en profil for hver grense for kundeautorisasjon. Programmet tilordner en godkjent kunde til riktig profil og tilhørende tillatte arbeidsområder og innhold.

Bruk den overordnedes Microsoft Entra tilgangstoken og toppteksten X-PowerBI-Profile-Id for profilomfang. Profilen velger kundekonteksten. det er ikke et eget Entra-tilgangstoken. Se profiltillatelser.

Forutsetning

Når du har valgt profilmodellen, kan du se gjennom den detaljerte konfigurasjonsveiledningen.

Du må også gjøre følgende:

Skjermbilde av administrasjonsportalen som viser aktiver oppretting av profilbryter.

Konfigurere en profilbasert løsning

Hvis du velger profiler, konfigurerer du kundekonteksten, ressursene og programforespørslene:

  1. Opprett kundeprofiler.
  2. Organiser kundearbeidsområder og innhold.
  3. Konfigurer profilavhengige programforespørsler.
  4. Valider kundetilgang og -operasjoner.

Opprett kundeprofiler

Bruk REST-API-en for profiler med overordnet tjenestekontohaver til å opprette en profil for hver grense for kundeautorisasjon.

Lagre kunde-til-profil-tilordningen i klarert konfigurasjon på serversiden. Valider kundemedlemskap før du velger en profil eller ressurs. ikke godta vilkårlige profil-ID-er fra klienten.

Organisere arbeidsområdene

Den enkleste måten å administrere dataene på, er å opprettholde ett arbeidsområde per kunde. Hvis appen allerede bruker denne modellen, trenger du ikke å opprette nye arbeidsområder. Du må imidlertid fortsatt gi hver profil administratortilgang til det tilsvarende arbeidsområdet ved hjelp av API-en legg til gruppebruker.

Hvis du ikke har ett arbeidsområde per kunde, kan du bruke den tilsvarende profilen til å kalle opprett gruppe-API-en for å opprette et nytt arbeidsområde for hver kunde.

Organisere elementer i arbeidsområder

Når du har opprettet eller tilordnet kundearbeidsområder, importerer du rapporter og semantiske modeller der det er nødvendig. Behold eksisterende innhold der den valgte utformingen støtter det. Velg semantisk modell og datakildeutforming for dine krav:

  • Hvis appen bruker en egen semantisk modell for hver kunde, kan den semantiske modellutformingen fungere som den er.

  • Hvis utformingen drar nytte av separate modeller, kan du konfigurere en semantisk modell for hver kunde. Evaluer kapasitets-, oppdaterings- og administrasjonskostnader i stedet for å anta at profiler alene forbedrer skalerbarheten for hvert program.

  • Hvis utformingen bruker sikkerhet på radnivå (RLS), validerer du den effektive identiteten og rollene som ble angitt under generering av innebyggingstoken, inkludert det forventede UserName() resultatet for dynamisk RLS og rollevalg for statisk RLS. Du kan bruke RLS i en kundes semantiske modell for å skille tilgang mellom brukerne.

Når elementene er klare, importerer du dem til de relevante arbeidsområdene. Hvis du vil automatisere prosessen, kan du vurdere å bruke import-API-en.

For en eksisterende semantisk modell som kundeprofilen må administrere gjennom bare eieroperasjoner, må du kontrollere at profilen eier modellen. Der det støttes, kan du bruke API-en Take Over In Group som denne profilen for å overføre eierskap. Konfigurer de nødvendige tilkoblingsidentitetene og legitimasjonen for datakilden før du bytter disse operasjonene til profilen. Administratortilgang for arbeidsområde overfører ikke eierskap eller konfigurerer ikke disse innstillingene.

Profilavhengige programforespørsler

Bruk den tilordnede kundeprofilen konsekvent for støttede kundeoperasjoner:

  • Godkjenning og profilvalg: Hent den overordnedes tilgangstoken gjennom den konfigurerte godkjenningsmetoden. Velg kundeprofilen ved hjelp av profilhodet eller SDK-profilkonfigurasjonen. En profil bruker det overordnede tokenet. ikke behandle en profil-ID som en Entra-hoved-ID.
  • Kundeklargjøring: Opprett en kundeprofil, og bruk den til å opprette og administrere kundens arbeidsområde og innhold. Automatiser import, tilkoblingskonfigurasjon og livssyklusendringer der det er nødvendig.
  • Generering av innebyggingstoken: Bruk den tiltenkte kundeprofilkonteksten til å kalle GenerateToken-API-en. Omfang forespørselen til kundens tillatte innhold og gi den nødvendige RLS effektiv identitet og roller der det er aktuelt. Forelderen kan handle gjennom profilene sine. en profil er ikke en uavhengig sikkerhetsgrense.

Valider kundetilgang

Test den valgte konfigurasjonen før produksjonsbruk:

  • Kontroller at hver godkjente kunde bare velger den tilordnede profilen og de tillatte ressursene. Test nektet forespørsler på tvers av kunder samt vellykkede forespørsler.
  • Bekreft tilgang til kundearbeidsområde, innebyggingstokenomfang, rapportgjengivelse og gjeldende RLS-virkemåte.
  • Bekreft eierskap av semantisk modell, tilkoblingsidentiteter, legitimasjon for datakilder, parameteroppdateringer og planlagt oppdatering.
  • Se gjennom ressursaktivitetslogger og overvåking av pålogging med overordnet identitet. Profiler oppretter ikke uavhengige per kunde Entra-pålogginger.
  • Automatiser kundeavlasting og se etter jobber eller innhold som fortsatt er avhengig av en profil, før du fjerner tilgangen eller sletter den.

Merk

Hvis du konfigurerer et eksisterende program på nytt, beholder du den forrige kodebanen og nødvendige tillatelser som er tilgjengelige i løpet av en testutrullings- og tilbakerullingsperiode. Eksisterende brede tillatelser kan maskere feil kunderuting selv når rapporter gjengis. Registrere og teste gjenoppretting av endret eierskap, tilkoblinger, legitimasjon og tillatelser før den gamle konfigurasjonen trekkes tilbake. Fjern foreldet kode, arbeidsområder og gir bare etter kontroll av avhengigheter.