Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Tjenesteprincipalprofiler er en valgfri løsning til Power BI Embedded programmer med flere netværk. De leverer letvægtskundeprofiler og understøtter et stort antal kundearbejdsområder uden at kræve en separat Microsoft Entra programregistrering for hver kunde.
For nye multitenancy-løsninger anbefaler vi dedikerede kundeserviceprincipaler, der er godkendt via administreret identitet og legitimationsoplysninger i organisationsnetværket, hvor hosting- og tillidskravene er opfyldt.
Profiler forbliver et gyldigt alternativ til nye og eksisterende programmer, hvis krav passer til deres egenskaber. De frarådes ikke. Eksisterende programmer, der er tilfredse med profiler, kan fortsætte med at bruge dem. I denne artikel forklares deres fordele, begrænsninger og konfiguration på højt niveau. Du kan finde API-eksempler i den detaljerede profilvejledning.
Hvor profiler for tjenesteprincipaler passer
Overvej profiler, når dit program bruger deres understøttede grænseflader, drager fordel af deres skalerings- og administrationsmodel og kan acceptere deres identitets- og driftsmæssige begrænsninger. En kunde er en logisk kunde i dit program, ikke nødvendigvis en separat Microsoft Entra lejer.
| Fordel | Hvad det betyder for din løsning |
|---|---|
| Letvægtskundekontekster | Opret profiler under én overordnet uden en separat programregistrering og en tjenesteprincipal for hver kunde. |
| Skalering af understøttet arbejdsområde | En overordnet kan oprette op til 100.000 profiler, hver med adgang til op til 1.000 arbejdsområder. Evaluer også de relevante ressource- og kapacitetsgrænser. |
| Automatiseret livscyklus | Opret og administrer profiler, og klargør kundeindhold via understøttede REST API'er. |
| Indholdsadministration med kundeomfang | Brug kundeprofilen til at administrere tilladelser til arbejdsområder, semantisk modelejerskab og legitimationsoplysninger for datakilden. Korrekt programdistribution og tilladelser er stadig vigtige. |
Profiler kan reducere klargøring af kataloger pr. kunde, men kræver stadig automatisering af programlivscyklus. Et lille program har muligvis ikke brug for deres skaleringsmodel. Hvis dit program allerede bruger dedikerede principper og opfylder kravene, er det ikke nødvendigt at skifte til profiler.
Begrænsninger og afvejninger
Evaluer disse begrænsninger sammen med fordelene:
- Profiler er ikke uafhængige Microsoft Entra identiteter og producerer ikke uafhængige entralogonposter pr. kunde.
- Profiler kan ikke modtage politikker for betinget adgang til arbejdsbelastningsidentitet eller tilladelser til downstream-tjenesten som uafhængige entra-identiteter.
- Profiler understøtter ikke Fabric REST API'er. Kontrollér de understøttede grænseflader og skaleringsgrænser.
- Profiler forbliver bundet til deres oprettelses overordnede og har api-only-administration.
- Den overordnede kan handle via en hvilken som helst af sine profiler. Profiler opretter ikke kryptografisk kundeisolation.
Du kan se de fulde begrænsninger under Begrænsninger for identitet og API. Dedikerede principaler kræver også planlægning af katalogkapacitet og livscyklusstyring. ingen af identitetsmodellen erstatter ressourcetilladelser eller sikker kundedistribution.
Separate kundearbejdsområder og semantiske modeller kan forbedre kapacitetsstyringen i begge identitetsmodeller. Disse fordele kræver ikke profiler. Hvis et eksisterende profilbaseret program skal bruge egenskaber uden for profilmodellen, skal du se Erstat tjenesteprincipalprofiler med tjenesteprincipaler.
Sådan fungerer profilmodellen
Programmets overordnede tjenesteprincipal opretter en profil for hver kundegodkendelsesgrænse. Programmet knytter en godkendt kunde til den korrekte profil og dens tilladte arbejdsområder og indhold.
I forbindelse med profilbaserede REST-kald skal du bruge den overordnedes Microsoft Entra adgangstoken og headerenX-PowerBI-Profile-Id. Profilen vælger kundekonteksten. det er ikke et separat Entra-adgangstoken. Se Profiltilladelser.
Forudsætninger
Når du har valgt profilmodellen, skal du gennemse den detaljerede konfigurationsvejledning.
Du skal også udføre følgende trin:
- Konfigurer godkendelse og påkrævede lejerindstillinger for den overordnede tjenesteprincipal. Se konfiguration af tjenesteprincipal eller den overordnede indstilling for administreret identitet. Beskyt og roter alle gemte hemmeligheder eller certifikater, der bruges af din valgte godkendelsesmetode.
- Aktivér oprettelse af profiler i lejeren fra en Power BI-lejeradministratorkonto.
Konfigurer en profilbaseret løsning
Hvis du vælger profiler, skal du konfigurere kundekontekst, ressourcer og programanmodninger:
- Opret kundeprofiler.
- Organiser kundearbejdsområder og indhold.
- Konfigurer profilorienterede programanmodninger.
- Valider kundeadgang og -handlinger.
Opret kundeprofiler
Brug REST API'en Profiler med den overordnede tjenesteprincipal til at oprette en profil for hver kundegodkendelsesgrænse.
Gem kunde-til-profil-tilknytningen i serverkonfigurationen, der er tillid til. Valider kundemedlemskab, før du vælger en profil eller ressource. accepterer ikke vilkårlige profil-id'er fra klienten.
Organiser dine arbejdsområder
Den nemmeste måde at administrere dine data på er ved at vedligeholde ét arbejdsområde pr. kunde. Hvis din app allerede bruger denne model, behøver du ikke at oprette nye arbejdsområder. Du skal dog stadig give hver profil administratoradgang til det tilsvarende arbejdsområde ved hjælp af API'en Tilføj gruppebruger.
Hvis du ikke har ét arbejdsområde pr. kunde, kan du bruge den tilsvarende profil til at kalde API'en Opret gruppe for at oprette et nyt arbejdsområde for hver kunde.
Organiser elementer i arbejdsområder
Når du har oprettet eller tildelt kundearbejdsområder, skal du importere rapporter og semantiske modeller, hvor det er nødvendigt. Behold eksisterende indhold, hvor det valgte design understøtter det. Vælg den semantiske model og datakildedesignet til dine krav:
Hvis din app bruger en separat semantisk model for hver kunde, kan det semantiske modeldesign fungere, som det er.
Hvis dit design har fordel af separate modeller, skal du konfigurere en semantisk model for hver kunde. Evaluer omkostninger til kapacitet, opdatering og administration i stedet for at antage, at profiler alene forbedrer alle apps skalerbarhed.
Hvis dit design bruger sikkerhed på rækkeniveau, skal du validere den effektive identitet og de eksisterende roller, der angives under generering af integreringstoken, herunder det forventede
UserName()resultat for dynamisk sikkerhed på rækkeniveau og valg af rolle for statisk sikkerhed på rækkeniveau. Du kan bruge sikkerhed på rækkeniveau i en kundes semantiske model til at adskille adgang mellem brugerne.
Når elementerne er klar, skal du importere dem til de relevante arbejdsområder. Du kan automatisere processen ved at overveje at bruge import-API'en.
For en eksisterende semantisk model, som kundeprofilen skal administrere via handlinger, der kun er ejer, skal du sikre, at profilen ejer modellen. Hvis det understøttes, skal du bruge API'en Overtag i gruppe som denne profil til at overføre ejerskabet. Konfigurer de påkrævede forbindelsesidentiteter og legitimationsoplysninger for datakilden, før du skifter disse handlinger til profilen. Adgang til arbejdsområdeadministrator alene overfører ikke ejerskabet eller konfigurerer ikke disse indstillinger.
Profilorienterede programanmodninger
Brug den tilknyttede kundeprofil konsekvent til understøttede kundehandlinger:
- Godkendelse og profilvalg: Hent den overordnedes adgangstoken via den konfigurerede godkendelsesmetode. Vælg kundeprofilen ved hjælp af profilheaderen eller SDK-profilkonfigurationen. En profil bruger den overordnedes token. behandl ikke et profil-id som et Entra-hoved-id.
- Klargøring af kunder: Opret en kundeprofil, og brug den til at oprette og administrere kundens arbejdsområde og indhold. Automatiser import, forbindelseskonfiguration og ændringer af livscyklus, hvor det er nødvendigt.
- Generering af integreringstoken: Brug den tilsigtede kontekst for kundeprofilen til at kalde GenerateToken-API'en. Omfang anmodningen til kundens tilladte indhold, og angiv den påkrævede effektive RLS-identitet og -roller, hvor det er relevant. Den overordnede kan handle via sine profiler. en profil er ikke en uafhængig sikkerhedsgrænse.
Valider kundeadgang
Test den valgte konfiguration før produktionsbrug:
- Bekræft, at hver godkendt kunde kun vælger dens tildelte profil og tilladte ressourcer. Test af afviste anmodninger på tværs af kunder samt vellykkede anmodninger.
- Bekræft adgang til kundearbejdsområde, integreringstokenområde, rapportgengivelse og gældende funktionsmåde for sikkerhed på rækkeniveau.
- Kontrollér ejerskabet af semantiske modeller, forbindelsesidentiteter, legitimationsoplysninger for datakilden, parameteropdateringer og planlagt opdatering.
- Gennemse ressourceaktivitetslogge og overvågning af overordnet identitetslogon. Profiler opretter ikke uafhængige entralogon pr. kunde.
- Automatiser kundens offboarding, og kontrollér, om der er job eller indhold, der stadig afhænger af en profil, før du fjerner dens adgang eller sletter den.
Bemærk
Hvis du omkonfigurerer et eksisterende program, skal du bevare den forrige kodesti og de påkrævede tilladelser tilgængelige under en pilotudrulnings- og annulleringsperiode. Eksisterende brede tilladelser kan maskere forkert kundedistribution, selvom rapporter gengives korrekt. Registrer og test gendannelse af ændret ejerskab, forbindelser, legitimationsoplysninger og tilladelser, før den gamle konfiguration udgår. Fjern forældet kode, arbejdsområder og tildeler kun efter kontrol af afhængigheder.