Bygge inn en rapport med RLS
GJELDER FOR: Appen eier data Brukeren eier data
Denne artikkelen forklarer hvordan du bygger inn Power BI-innhold som bruker RLS i en standard Power BI-app eier dataprogram.
Forutsetning
Hvis du vil ha en detaljert forklaring på hvordan du konfigurerer RLS, kan du se Sikkerhet på radnivå (RLS) med Power BI.
Når du definerer RLS-rollene, må du huske på at DAX-uttrykket du bruker, bestemmer om RLS-modellen er statisk eller dynamisk.
Når du skal bruke statisk og dynamisk sikkerhet
Statisk sikkerhet bruker en fast verdi i DAX-filteret til å definere hver rolle. Det er enkelt å implementere, men vanskelig å vedlikeholde når det er mange brukere eller organisasjoner involvert.
Statisk sikkerhet fungerer best for en ISV som betjener én eller noen få store kunder der hver avdeling trenger tilgang til forskjellige data.
Dynamisk sikkerhet bruker en DAX-funksjon (username()
eller userprincipalname()
) til å definere rollene. Dynamisk sikkerhet gir mer fleksibilitet og lar deg administrere dataene ved hjelp av færre roller og mindre vedlikehold.
Statisk sikkerhet
Med statiske roller sender du rollen til Power BI når du genererer et innebyggingstoken, og brukeren ser data i henhold til denne rollen. Hvis du vil opprette statiske sikkerhetsroller, skriver du inn en fast verdi i DAX-filteret.
Du kan for eksempel definere rollen som Øst-USA som [Region] = "East"
La oss si at john@contoso.com det er en bruker av appen din. Du vil gi John tilgang til data fra rollen øst i USA . Hvis du vil bygge inn en rapport for john@contoso.com, kan du generere et innebyggingstoken ved hjelp av rollen For øst-USA . De resulterende dataene filtreres for [Region] = "East"
.
Merk
Når du genererer innebyggingstokenet, må du angi et brukernavn, men brukernavnet kan være en hvilken som helst streng. Statiske roller har en fast verdi som ikke er avhengig av et brukernavn, så når ISV bestemmer brukerens rolle og sender den til innebyggingstokenet, filtreres dataene i henhold til denne rollen, uavhengig av hvilket brukernavn som ble sendt.
Dynamisk sikkerhet
Dynamisk sikkerhet bruker DAX-funksjonen (username()
eller userprincipalname()
) til å definere rollen.
I brukerens eier datascenario filtrerer RLS-modellen automatisk data basert på rollene til den bestemte brukeren.
Med appen eier data, kjenner ikke Power BI brukernavnene til ISV-kunder, slik at du kan bruke username()
funksjonen til å filtrere dataene dynamisk.
Opprett en rolle i Power BI Desktop ved hjelp av brukernavn()-funksjonen. Du kan for eksempel opprette en rolle kalt CountryDynamic og definere den som [CountryRegionCode] = username()
La oss si at du vil gi brukeren, jane@contoso.com, tilgang til data for Frankrike. Når du genererer et innebyggingstoken for jane@contoso.com, sender du strengen Frankrike som brukernavn i rollen CountryDynamic . Dataene filtreres i henhold til [CountryRegionCode] = Frankrike.
{
"accessLevel": "View",
"identities": [
{
"username": "France",
"roles": [ "CountryDynamic"],
"datasets": [ "fe0a1aeb-f6a4-4b27-a2d3-b5df3bb28bdc" ]
}
]
}
Når du bruker dynamisk sikkerhet i dette scenarioet, trenger du bare én rolle for alle områder. Områdenavnet brukes som den effektive identiteten.
Generer et innebyggingstoken
Når du er klar til å bygge inn rapporten i appen, må du generere et innebyggingstoken. Hvis du vil generere et token ved hjelp av API-en for innebyggingstoken, sender du følgende informasjon til API-en.
- brukernavn (obligatorisk) – Hvis rollene er dynamiske, brukes brukernavnstrengen som filter. For statiske roller påvirker ikke brukernavnet RLS og kan være en hvilken som helst streng i det hele tatt. Bare ett enkelt brukernavn kan være oppført.
- roller (obligatorisk) – rollen(e) som brukes ved bruk av regler for sikkerhet på radnivå. Hvis du sender mer enn én rolle, bør de sendes som en strengmatrise.
- datasett (obligatorisk) – datasettet som gjelder for elementet du bygger inn.
Nå kan du bygge inn rapporten i appen. Rapporten filtrerer data i henhold til RLS som brukes.
public EmbedToken GetEmbedToken(Guid reportId, IList<Guid> datasetIds, [Optional] Guid targetWorkspaceId)
{
PowerBIClient pbiClient = this.GetPowerBIClient();
// Defines the user identity and roles.
var rlsIdentity = new EffectiveIdentity(
username: "France",
roles: new List<string>{ "CountryDynamic" },
datasets: datasetIds.Select(id => id.ToString()).ToList());
);
// Create a request for getting an embed token for the rls identity defined above
var tokenRequest = new GenerateTokenRequestV2(
reports: new List<GenerateTokenRequestV2Report>() { new GenerateTokenRequestV2Report(reportId) },
datasets: datasetIds.Select(datasetId => new GenerateTokenRequestV2Dataset(datasetId.ToString())).ToList(),
targetWorkspaces: targetWorkspaceId != Guid.Empty ? new List<GenerateTokenRequestV2TargetWorkspace>() { new GenerateTokenRequestV2TargetWorkspace(targetWorkspaceId) } : null,
identities: new List<EffectiveIdentity> { rlsIdentity }
);
// Generate an embed token
var embedToken = pbiClient.EmbedToken.GenerateToken(tokenRequest);
return embedToken;
}
Hensyn og begrensninger
- Avhengig av oppsettet må du kanskje utføre flere trinn før du kan generere et innebyggingstoken. Hvis du vil ha informasjon om de ulike scenariene, kan du se Bygge inn en rapport som bruker sikkerhetsfunksjoner.
- Brukeren som genererer innebyggingstokenet, må være medlem eller administrator i begge arbeidsområdene (datasettarbeidsområdet og rapportarbeidsområdet).
- Når du genererer innebyggingstokenet, må du angi et brukernavn og en rolle. Hvis du ikke gjør det, skjer én av følgende hendelser, avhengig av om tokenet genereres av tjenestekontohaver eller hovedbruker:
- Tokengenerering mislykkes for en tjenestekontohaver.
- Tokengenerering lykkes for en hovedbruker, men dataene filtreres ikke (alle dataene returneres).
Relatert innhold
Flere spørsmål? Prøv Power BI-fellesskap.