Ting å ta hensyn til når du genererer et innebyggingstoken

Generer token er et REST-API som lar deg generere et token for innebygging av et Power BI-element i en nettapp eller en portal. Tokenet brukes til å godkjenne forespørselen mot Power BI-tjenesten.

API-et for generering av token bruker én identitet (en hovedbruker eller tjenestekontohaver) til å generere et token for en individuell bruker, avhengig av brukerens legitimasjon i appen (gjeldende identitet).

Når godkjenningen er fullført, gis tilgang til de relevante dataene.

Obs!

Generer token er bare tilgjengelig når du bygger inn for kundene (også kjent som app eier data-scenarioet).

Du kan bruke følgende API-er til å generere et token:

Versjoner av arbeidsområder

Power BI har to versjoner av arbeidsområder, et klassisk arbeidsområde og et nytt arbeidsområde. Du kan finne ut mer om forskjellene mellom disse arbeidsområdene i forskjeller mellom nye og klassiske arbeidsområder.

Når du oppretter et innebyggingstoken, har forskjellige arbeidsområder forskjellige faktorer og krever ulike tillatelser.

Klassisk arbeidsområde Nytt arbeidsområde
Viktige faktorer
  • Datasettet og elementet må være i samme arbeidsområde
  • Kan ikke bruke tjenestekontohaver
  • Datasettet og elementet kan være i to forskjellige nye arbeidsområder
    Arbeidsområdetillatelser Hovedbrukeren må være administrator for arbeidsområdet Tjenestekontohaveren eller hovedbrukeren må minst være medlem av begge arbeidsområder

    Obs!

    • Du kan ikke opprette et innebyggingstoken for Mitt arbeidsområde.
    • Ordet element refererer til et Power BI-element, for eksempel et instrumentbord, en flis, spørsmål og svar eller en rapport.

    Sikring av dataene dine

    Når du oppretter løsningen, må du vurdere disse to metodene for å sikre dataene dine: Arbeidsområdebasert isolering og isolering basert på sikkerhet på radnivå. Du finner en detaljert sammenligning mellom dem i Multi-leierløsninger med Power BI innbygd analyse.

    Hvis du skal bruke RLS (sikkerhet på radnivå)-tilnærmingen, kan du se gjennom RLS-faktorer og -begrensninger i slutten av denne artikkelen.

    Token-tillatelser

    Delen GenerateTokenRequest beskriver tokentillatelsene i Generer token-API-ene.

    Obs!

    Token-tillatelsene som er oppført i denne delen, gjelder ikke for API-et Generer token for flere rapporter.

    Tilgangsnivå

    Bruk parameteren accessLevel til å fastslå brukerens tilgangsnivå.

    • Vis – gi brukeren visningstillatelser.

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

      Hvis du bruker API-et Generer token for flere rapporter, bruker du allowEdit-parameteren til å gi brukeren visning- og redigeringstillatelser.

    • Opprett – gi brukeren tillatelser til å opprette en rapport (gjelder bare når du genererer et innebyggingstoken for å opprette en rapport).

      Du må også angi datasetID-parameteren når du oppretter rapporter.

    Lagre en kopi av rapporten

    Bruk den boolske allowSaveAs for å la brukerne lagre rapporten som en ny rapport. Denne innstillingen er satt til usann som standard.

    Denne parameteren gjelder bare når du genererer et innebyggingstoken for en rapport.

    Sikkerhet på radnivå

    Med sikkerhet på radnivå (RLS) kan du velge å bruke en annen identitet enn identiteten til tjenestekontohaveren eller hovedbrukeren som du genererer tokenet med. Med dette alternativet kan du vise innebygd informasjon i henhold til brukeren du er rettet mot. I programmet kan du for eksempel be brukerne om å logge seg på og deretter vise en rapport som bare inneholder salgsinformasjon, hvis den påloggede brukeren er en salgsperson.

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

    Tabellen viser også faktorer og begrensning som gjelder for hver RLS-type.

    RLS-type Kan jeg generere et innebyggingstoken uten å angi gjeldende bruker-ID? Viktige faktorer og begrensninger
    Skysikkerhet på radnivå (sky-RLS) ✔ Hovedbruker
    ✖ Tjenestekontohaver
    RDL (sideformaterte rapporter) ✖ Hovedbruker
    ✔ Tjenestekontohaver
    Du kan ikke bruke en hovedbruker til å generere et innebyggingstoken for RDL.
    Lokal live-tilkobling til Analysis Services (AS) ✔ Hovedbruker
    ✖ Tjenestekontohaver
    Brukeren som genererer innebyggingstokenet, trenger også én av følgende tillatelser:
  • Administratortillatelser for gateway
  • Tillatelse for datakilderepresentasjon (ReadOverrideEffectiveIdentity)
  • Live-tilkobling til Azure Analysis Services (AS) ✔ Hovedbruker
    ✖ Tjenestekontohaver
    Identiteten til brukeren som genererer innebyggingskoden, kan ikke overstyres. Egendefinerte data kan brukes til å implementere dynamisk RLS eller sikker filtrering.

    Merk: Tjenestekontohaver må angi objekt-ID-en som den gjeldende identiteten (RLS-brukernavn).
    Enkel pålogging (SSO) ✔ Hovedbruker
    ✖ Tjenestekontohaver
    En eksplisitt identitet (SSO) kan angis ved hjelp av egenskapen for identitets-blob-en i et gjeldende identitetsobjekt
    SSO og sky-RLS ✔ Hovedbruker
    ✖ Tjenestekontohaver
    Du må angi følgende:
  • Eksplisitt identitet (SSO) i egenskapen for identitets-blob-en i et gjeldende identitetsobjekt
  • Gjeldende identitet (RLS) (brukernavn)
  • Obs!

    Tjenestekontohaver må alltid angi følgende:

    • En identitet for alle elementer for RLS-datasett.
    • En gjeldende RLS-identitet med egenskapen brukernavn angitt for SSO-datasett.

    Neste trinn