Del via

Generér et integreringstoken

  • Artikel

GÆLDER FOR: Appen ejer data Brugeren ejer data

Generér token er en REST-API, der giver dig mulighed for at generere et token til integrering af en Power BI-rapport eller semantisk model i en webapp eller en portal. Det kan generere et token for et enkelt element eller for flere rapporter eller semantiske modeller. Tokenet bruges til at godkende din anmodning mod Power BI-tjeneste.

API'en Generér token bruger en enkelt identitet (en masterbruger eller en tjenesteprincipal) til at generere et token for en individuel bruger, afhængigt af brugerens legitimationsoplysninger i appen (effektiv identitet).

Når godkendelsen er fuldført, gives der adgang til de relevante data.

Bemærk

Generér token er den nyere version 2-API, der fungerer for både rapporter og semantiske modeller og enkelte eller flere elementer. For dashboards og felter skal du bruge V1 Dashboards GenerateTokenInGroup og Felter GenerateTokenInGroup.

Sikring af dine data

Hvis du håndterer data fra flere kunder, er der to primære metoder til at beskytte dine data: Arbejdsområdebaseret isolation og sikkerhedsbaseret isolation på rækkeniveau. Du kan finde en detaljeret sammenligning mellem dem i tjenesteprincipalprofiler og sikkerhed på rækkeniveau.

Vi anbefaler, at du bruger arbejdsområdebaseret isolation med profiler, men hvis du vil bruge RLS-metoden, skal du gennemse afsnittet sikkerhed på rækkeniveau i slutningen af denne artikel.

Tokentilladelser og sikkerhed

I afsnittet Generér token API'er beskrives tokentilladelserne i afsnittet GenerateTokenRequest.

Adgangsniveau

  • Hvis du vil tildele brugeren visnings- eller redigeringstilladelser, skal du bruge parameteren allowEdit.

  • Hvis du vil give brugeren tilladelse til at oprette nye rapporter (enten SaveAs- eller CreateNew) i det pågældende arbejdsområde, skal du føje arbejdsområde-id'et til integreringstokenet.

Sikkerhed på rækkeniveau

Med sikkerhed på rækkeniveau kan den identitet, du bruger, være forskellig fra identiteten for den tjenesteprincipal eller masterbruger, du bruger til at generere tokenet. Ved hjælp af forskellige identiteter kan du få vist integrerede oplysninger i henhold til den bruger, du er målrettet til. I dit program kan du f.eks. bede brugerne om at logge på og derefter få vist en rapport, der kun indeholder salgsoplysninger, hvis den bruger, der er logget på, er en salgsmedarbejder.

Hvis du bruger sikkerhed på rækkeniveau, kan du nogle gange udelade brugerens identitet (parameteren EffectiveIdentity ). Når du ikke bruger parameteren EffectiveIdentity , har tokenet adgang til hele databasen. Denne metode kan bruges til at give adgang til brugere, f.eks. administratorer og ledere, som har tilladelse til at få vist hele den semantiske model. Du kan dog ikke bruge denne metode i alle scenarier. I følgende tabel vises de forskellige typer sikkerhed på rækkeniveau, og den viser, hvilken godkendelsesmetode der kan bruges uden at angive en brugers identitet.

Tabellen viser også de overvejelser og begrænsninger, der gælder for hver RLS-type.

RLS-type Kan jeg generere et integreringstoken uden at angive det effektive bruger-id? Overvejelser og begrænsninger
Cloud Row Level Security (Cloud RLS) ✔ Masterbruger
✖ Tjenesteprincipal
RDL (sideinddelte rapporter) ✖ Masterbruger
✔ Tjenesteprincipal		 Du kan ikke bruge en masterbruger til at generere et integreringstoken til RDL.
Direkte forbindelse til Analysis Services (AS) i det lokale miljø ✔ Masterbruger
✖ Tjenesteprincipal		 Den bruger, der genererer integreringstokenet, skal også have en af følgende tilladelser:
  • Tilladelser til gatewayadministrator
  • Datasource repræsenter tilladelse (ReadOverrideEffectiveIdentity)
    		•
    Direkte forbindelse til Analysis Services (AS) Azure ✔ Masterbruger
    ✖ Tjenesteprincipal    		 Identiteten for den bruger, der genererer integreringstokenet, kan ikke tilsidesættes. Brugerdefinerede data kan bruges til at implementere dynamisk RLS eller sikker filtrering.

    Bemærk! Tjenesteprincipalen skal angive sit objekt-id som den effektive identitet (RLS-brugernavn).
    Enkeltlogon (SSO) ✔ Masterbruger
    ✖ Tjenesteprincipal    		 Der kan angives en eksplicit identitet (SSO) ved hjælp af identitetsblobegenskaben i et effektivt identitetsobjekt
    SSO og cloud RLS ✔ Masterbruger
    ✖ Tjenesteprincipal    		 Du skal angive:
  • Eksplicit (SSO)-identitet i identitetsblobegenskaben i et effektivt identitetsobjekt
  • Gældende identitet (RLS) (brugernavn)
    		•

    Bemærk

    Tjenesteprincipaler skal altid levere:

    • En identitet for et element med en semantisk RLS-model
    • En effektiv RLS-identitet med den kontekstafhængige identitet (SSO) defineret (for en semantisk SSO-model)

    DirectQuery til semantiske Power BI-modeller

    Sådan integrerer du en Power BI-rapport, der har en semantisk model med en Direct Query-forbindelse til en anden semantisk Power BI-model:

    Forny tokens, før de udløber

    Tokens har en tidsgrænse. Når du har integreret et Power BI-element, har du derfor begrænset tid til at interagere med det. Hvis du vil give dine brugere en kontinuerlig oplevelse, skal du forny (eller opdatere) tokenet, før det udløber.

    Dashboards og felter

    Tokenet Generér fungerer for rapporter og semantiske modeller. Hvis du vil generere et integreringstoken for et dashboard eller et felt, skal du bruge API'erne GenerateTokenInGroup eller Tiles GenerateTokenInGroup i version 1. Disse API'er genererer tokens for kun ét element ad gangen. Du kan ikke oprette et token for flere elementer.

    For disse API'er:

    • Brug parameteren accessLevel til at bestemme brugerens adgangsniveau.

      • View – Tildel brugeren visningstilladelser.

      • Edit – Tildel brugeren visnings- og redigeringstilladelser (gælder kun, når der genereres et integreringstoken for en rapport).

      • Opret – Giv brugeren tilladelse til at oprette en ny rapport (gælder kun, når der oprettes et integreringstoken til oprettelse af en rapport). Hvis du vil oprette en rapport, skal du også angive parameteren datasetId .

    • Brug booleske allowSaveAs til at lade brugerne gemme rapporten som en ny rapport. Denne indstilling er som standard angivet til falsk og gælder kun, når der genereres et integreringstoken for en rapport.

    Overvejelser og begrænsninger

    • Af sikkerhedsmæssige årsager angives levetiden for integreringstokenet til den resterende levetid for det Microsoft Entra-token, der bruges til at kalde API'en GenerateToken . Hvis du bruger det samme Microsoft Entra-token til at generere flere integreringstokens, bliver levetiden for de genererede integreringstokens derfor kortere ved hvert kald.

    • Hvis den semantiske model og det element, der skal integreres, er i to forskellige arbejdsområder, skal tjenesteprincipalen eller masterbrugeren som minimum være medlem af begge arbejdsområder.

    • Integrering af elementer ved hjælp af Data Lake Storage (DLS) kræver V2 af api'en Generate token.

    • Du kan ikke oprette et integreringstoken til Mit arbejdsområde.

    Relateret indhold