Generer et innebyggingstoken

  • Artikkel

GJELDER FOR: Appen eier data Brukeren eier data

Generer token er en REST-API som lar deg generere et token for innebygging av en Power BI-rapport eller semantisk modell i en nettapp eller en portal. Det kan generere et token for ett enkelt element eller for flere rapporter eller semantiske modeller. Tokenet brukes til å godkjenne forespørselen mot Power Bi-tjeneste.

API-en for genereringstokenet bruker én enkelt identitet (en hovedbruker eller tjenestekontohaver) til å generere et token for en enkeltbruker, avhengig av brukerens legitimasjon i appen (effektiv identitet).

Etter vellykket godkjenning gis tilgang til de relevante dataene.

Merk

Generer token er den nyere, versjon 2 API som fungerer for både rapporter og semantiske modeller, og enkle eller flere elementer. Det er foretrukket fremfor eldre versjon 1 API-er. For instrumentbord og fliser kan du bruke V1 Dashboards GenerateTokenInGroup og Fliser GenerateTokenInGroup.

Sikre dataene dine

Hvis du håndterer data fra flere kunder, finnes det to hovedmetoder for å sikre dataene: Arbeidsområdebasert isolering og sikkerhetsbasert isolering på radnivå. Du kan finne en detaljert sammenligning mellom dem i tjenestekontohaverprofiler og sikkerhet på radnivå.

Vi anbefaler at du bruker arbeidsområdebasert isolering med profiler, men hvis du vil bruke RLS-tilnærmingen, kan du se gjennom RLS-delen på slutten av denne artikkelen.

Tokentillatelser og sikkerhet

I genereringstoken-API-er beskriver GenerateTokenRequest-delen tokentillatelsene.

Tilgangsnivå

  • Bruk allowEdit-parameteren til å gi brukeren visnings- eller redigeringstillatelser.

  • Legg til arbeidsområde-ID-en i innebyggingstokenet slik at brukeren kan opprette nye rapporter (enten SaveAs eller CreateNew) i arbeidsområdet.

Sikkerhet på radnivå

Med Sikkerhet på radnivå (RLS) kan identiteten du bruker være forskjellig fra identiteten til tjenestekontohaveren eller hovedbrukeren du bruker til å generere tokenet. Ved hjelp av ulike identiteter kan du vise innebygd informasjon i henhold til brukeren du målretter mot. I programmet kan du for eksempel be brukerne om å logge på, og deretter vise en rapport som bare inneholder salgsinformasjon hvis den påloggede brukeren er en salgsansatt.

Hvis du bruker RLS, kan du noen ganger utelate brukerens identitet (EffectiveIdentity-parameteren). Når du ikke bruker EffectiveIdentity-parameteren , har tokenet tilgang til hele databasen. Denne metoden kan brukes til å gi tilgang til brukere som administratorer og ledere, som har tillatelse til å vise hele semantiske modellen. Du kan imidlertid ikke bruke denne metoden i alle scenarioer. Tabellen nedenfor viser de ulike RLS-typene, og viser hvilken godkjenningsmetode som kan brukes uten å angi en brukers identitet.

Tabellen viser også hensyn og begrensninger som gjelder for hver RLS-type.

RLS-type Kan jeg generere et innebyggingstoken uten å angi den effektive bruker-ID-en? Hensyn og begrensninger
Sikkerhet på radnivå i skyen (Cloud RLS) ✔ Hovedbruker
✖ Tjenestekontohaver
RDL (paginerte rapporter) ✖ Hovedbruker
✔ Tjenestekontohaver		 Du kan ikke bruke en hovedbruker til å generere et innebyggingstoken for RDL.
Analysis Services (AS) på lokal live-tilkobling ✔ Hovedbruker
✖ Tjenestekontohaver		 Brukeren som genererer innebyggingstokenet, trenger også én av følgende tillatelser:
  • Administratortillatelser for gateway
  • Tillatelse for representasjon av datakilde (ReadOverrideEffectiveIdentity)
    		•
    Live-tilkobling for Analysis Services (AS) Azure ✔ Hovedbruker
    ✖ Tjenestekontohaver    		 Identiteten til brukeren som genererer innebyggingstokenet, kan ikke overstyres. Egendefinerte data kan brukes til å implementere dynamisk RLS eller sikker filtrering.

    Obs! Tjenestekontohaver må angi objekt-ID-en som den effektive identiteten (RLS-brukernavn).
    Enkel pålogging (SSO) ✔ Hovedbruker
    ✖ Tjenestekontohaver    		 En eksplisitt (SSO)-identitet kan angis ved hjelp av identitetsblobegenskapen i et effektivt identitetsobjekt
    SSO og skybasert RLS ✔ Hovedbruker
    ✖ Tjenestekontohaver    		 Du må angi følgende:
  • Eksplisitt identitet (SSO) i identity blob-egenskapen i et effektivt identitetsobjekt
  • Effektiv identitet (RLS) (brukernavn)
    		•

    Merk

    Tjenestekontohavere må alltid oppgi følgende informasjon:

    • En identitet for alle elementer med en semantisk RLS-modell.
    • For en SSO-semantisk modell er en effektiv RLS-identitet med den kontekstavhengige (SSO)-identiteten definert.

    DirectQuery for Semantiske Modeller for Power BI

    Gjør følgende for å bygge inn Power BI-rapporten som har en semantisk modell med en direktespørringstilkobling til en annen semantisk Power BI-modell:

    Fornye tokener før de utløper

    Tokener leveres med en tidsbegrensning. Dette betyr at når du bygger inn et Power BI-element, har du begrenset tid til å samhandle med det. Hvis du vil gi brukerne en kontinuerlig opplevelse, kan du fornye (eller oppdatere) tokenet før det utløper.

    Instrumentbord og fliser

    Generer-tokenet fungerer for rapporter og semantiske modeller. Hvis du vil generere et innebyggingstoken for et instrumentbord eller en flis, kan du bruke generateTokenInGroup- eller Fliser GenerateTokenInGroup-API-er for versjon 1. Disse API-ene genererer tokener for bare ett element om gangen. Du kan ikke generere et token for flere elementer.

    For disse API-ene:

    • Bruk accessLevel-parameteren til å bestemme brukerens tilgangsnivå.

      • Visning – Gi brukeren visningstillatelser.

      • Rediger – Gi brukeren visnings- og redigeringstillatelser (gjelder bare når du genererer et innebyggingstoken for en rapport).

      • Opprett – Gi brukeren tillatelse til å opprette en ny rapport (gjelder bare når du genererer et innebyggingstoken for å opprette en rapport). Når det gjelder oppretting av rapporter, må du også angi parameteren datasett-ID .

    • Bruk allowSaveAs boolean for å la brukere lagre rapporten som en ny rapport. Denne innstillingen er satt til usann som standard, og gjelder bare når du genererer et innebyggingstoken for en rapport.

    Hensyn og begrensninger

    • Av sikkerhetsgrunner er levetiden til innebyggingstokenet satt til den gjenværende levetiden til Microsoft Entra-tokenet som brukes til å kalle GenerateToken API-en. Hvis du bruker det samme Microsoft Entra-tokenet til å generere flere innebyggingstokener, blir levetiden til de genererte innebyggingstokenene kortere for hvert anrop.

    • Hvis den semantiske modellen og elementet som skal bygges inn, er i to forskjellige arbeidsområder, må tjenestekontohaveren eller hovedbrukeren være minst medlem av begge arbeidsområdene.

    • Du kan ikke opprette et innebyggingstoken for Mitt arbeidsområde.

    Relatert innhold