Del via

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 Generer token 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. For instrumentbord og fliser kan du bruke V1 Dashboards GenerateTokenInGroup og Tiles 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 delen Generer token API-er beskriver GenerateTokenRequest-delen tokentillatelsene.

Tilgangsnivå

  • Hvis du vil gi brukeren visnings- eller redigeringstillatelser, bruker du allowEdit-parameteren.

  • Hvis du vil la brukeren opprette nye rapporter (enten SaveAs eller CreateNew) i arbeidsområdet, legger du til arbeidsområde-ID-en i innebyggingstokenet.

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:
  • Eksplisitt identitet (SSO) i identity blob-egenskapen i et effektivt identitetsobjekt
  • Effektiv identitet (RLS) (brukernavn)
    		•

    Merk

    Tjenestekontohavere må alltid oppgi:

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

    DirectQuery for Semantiske Modeller for Power BI

    Slik bygger du inn en Power BI-rapport som har en semantisk modell med en Direct Query-tilkobling til en annen semantisk Power BI-modell:

    Fornye tokener før de utløper

    Tokener leveres med en tidsbegrensning. Når du har bygg inn et Power BI-element, har du derfor 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 samme Microsoft Entra-token til å generere flere innebyggingstokener, blir derfor 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.

    • Innebygging av elementer ved hjelp av Data Lake Storage (DLS) krever V2 av Generer token-API-.

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

    Relatert innhold