Dela via

Generera en inbäddningstoken

  • Artikel

GÄLLER FÖR: Appen äger data Användaren äger data

Generera token är ett REST-API som gör att du kan generera en token för att bädda in en Power BI-rapport eller semantisk modell i en webbapp eller en portal. Den kan generera en token för ett enskilt objekt eller för flera rapporter eller semantiska modeller. Token används för att auktorisera din begäran mot Power BI-tjänst.

API:et för att generera token använder en enda identitet (en huvudanvändare eller tjänstens huvudnamn) för att generera en token för en enskild användare, beroende på användarens autentiseringsuppgifter i appen (effektiv identitet).

Efter lyckad autentisering beviljas åtkomst till relevanta data.

Kommentar

Generera token är det nyare version 2-API:et som fungerar för både rapporter och semantiska modeller och enskilda eller flera objekt. Det föredras framför api:erna för äldre version 1. För instrumentpaneler och paneler använder du V1-instrumentpanelerna GenerateTokenInGroup och Paneler GenerateTokenInGroup.

Skydda dina data

Om du hanterar data från flera kunder finns det två huvudsakliga metoder för att skydda dina data: Arbetsytebaserad isolering och säkerhetsbaserad isolering på radnivå. Du hittar en detaljerad jämförelse mellan dem i profiler för tjänstens huvudnamn och säkerhet på radnivå.

Vi rekommenderar att du använder arbetsytebaserad isolering med profiler, men om du vill använda RLS-metoden läser du avsnittet RLS i slutet av den här artikeln.

Tokenbehörigheter och säkerhet

I api:erna för att generera token beskriver avsnittet GenerateTokenRequest tokenbehörigheterna.

Åtkomstnivå

  • Använd parametern allowEdit för att ge användaren visnings- eller redigeringsbehörighet.

  • Lägg till arbetsytans ID i inbäddningstoken så att användaren kan skapa nya rapporter (antingen SaveAs eller CreateNew) på den arbetsytan.

Säkerhet på radnivå

Med säkerhet på radnivå (RLS) kan identiteten du använder skilja sig från identiteten för tjänstens huvudnamn eller huvudanvändare som du använder för att generera token. Genom att använda olika identiteter kan du visa inbäddad information enligt den användare som du riktar in dig på. I ditt program kan du till exempel be användarna att logga in och sedan visa en rapport som bara innehåller försäljningsinformation om den inloggade användaren är säljare.

Om du använder RLS kan du ibland utelämna användarens identitet (parametern EffectiveIdentity ). När du inte använder parametern EffectiveIdentity har token åtkomst till hela databasen. Den här metoden kan användas för att ge åtkomst till användare som administratörer och chefer, som har behörighet att visa hela semantikmodellen. Du kan dock inte använda den här metoden i varje scenario. Tabellen nedan visar de olika RLS-typerna och visar vilken autentiseringsmetod som kan användas utan att ange en användares identitet.

Tabellen visar också de överväganden och begränsningar som gäller för varje RLS-typ.

RLS-typ Kan jag generera en inbäddningstoken utan att ange det effektiva användar-ID:t? Beaktanden och begränsningar
Säkerhet på radnivå i molnet (Cloud RLS) ✔ Huvudanvändare
✖ Tjänstens huvudnamn
RDL (sidnumrerade rapporter) ✖ Huvudanvändare
✔ Tjänstens huvudnamn		 Du kan inte använda en huvudanvändare för att generera en inbäddningstoken för RDL.
Analysis Services (AS) lokalt live-anslutning ✔ Huvudanvändare
✖ Tjänstens huvudnamn		 Användaren som genererar inbäddningstoken behöver också någon av följande behörigheter:
  • Administratörsbehörigheter för gateway
  • Behörighet att personifiera datakälla (ReadOverrideEffectiveIdentity)
    		•
    Live-anslutning till Analysis Services (AS) i Azure ✔ Huvudanvändare
    ✖ Tjänstens huvudnamn    		 Identiteten för användaren som genererar inbäddningstoken kan inte åsidosättas. Anpassade data kan användas för att implementera dynamisk RLS eller säker filtrering.

    Obs! Tjänstens huvudnamn måste ange sitt objekt-ID som den effektiva identiteten (RLS-användarnamn).
    Enkel inloggning (SSO) ✔ Huvudanvändare
    ✖ Tjänstens huvudnamn    		 En explicit identitet (SSO) kan anges med egenskapen identitetsblob i ett effektivt identitetsobjekt
    Enkel inloggning och molnbaserad RLS ✔ Huvudanvändare
    ✖ Tjänstens huvudnamn    		 Du måste ange följande:
  • Explicit identitet (SSO) i identitetsblobegenskapen i ett effektivt identitetsobjekt
  • Gällande identitet (RLS) (användarnamn)
    		•

    Kommentar

    Tjänstens huvudnamn måste alltid ange följande information:

    • En identitet för alla objekt med en RLS-semantisk modell.
    • För en SSO-semantisk modell är en effektiv RLS-identitet med den kontextuella identiteten (SSO) definierad.

    DirectQuery för Power BI-semantiska modeller

    Om du vill bädda in Power BI-rapport som har en semantisk modell med en Direct Query-anslutning till en annan Power BI-semantisk modell gör du följande:

    Förnya token innan de upphör att gälla

    Token har en tidsgräns. Det innebär att när du har bäddat in ett Power BI-objekt har du en begränsad tid att interagera med det. Om du vill ge användarna en kontinuerlig upplevelse förnyar du (eller uppdaterar) token innan den upphör att gälla.

    Instrumentpaneler och paneler

    Generera token fungerar för rapporter och semantiska modeller. Om du vill generera en inbäddningstoken för en instrumentpanel eller panel använder du API:erna generateTokenInGroup eller paneler i version 1. Dessa API:er genererar token för endast ett objekt i taget. Du kan inte generera en token för flera objekt.

    För dessa API:er:

    • Använd parametern accessLevel för att fastställa användarens åtkomstnivå.

      • Visa – Bevilja användaren visningsbehörigheter.

      • Redigera – Bevilja användaren visnings- och redigeringsbehörigheter (gäller endast när du genererar en inbäddningstoken för en rapport).

      • Skapa – Ge användaren behörighet att skapa en ny rapport (gäller endast när du genererar en inbäddningstoken för att skapa en rapport). För att skapa rapporter måste du också ange parametern datasetId .

    • Använd booleska allowSaveAs för att låta användarna spara rapporten som en ny rapport. Den här inställningen är inställd på false som standard och gäller endast när du genererar en inbäddningstoken för en rapport.

    Beaktanden och begränsningar

    • Av säkerhetsskäl är livslängden för inbäddningstoken inställd på den återstående livslängden för den Microsoft Entra-token som används för att anropa API:et GenerateToken . Om du använder samma Microsoft Entra-token för att generera flera inbäddningstoken blir livslängden för de genererade inbäddningstoken kortare för varje anrop.

    • Om den semantiska modellen och objektet som ska bäddas in finns i två olika arbetsytor måste tjänstens huvudnamn eller huvudanvändare vara minst medlem i båda arbetsytorna.

    • Du kan inte skapa en inbäddningstoken för Min arbetsyta.

    Relaterat innehåll