Sikkerhed på rækkeniveau med Power BI EmbeddedRow-level security with Power BI Embedded

Sikkerhed på rækkeniveau (Row Level Security eller RLS) kan bruges til at begrænse brugeradgang til data i dashboards, felter, rapporter og datasæt.Row-level security (RLS) can be used to restrict user access to data within dashboards, tiles, reports, and datasets. Forskellige brugere kan arbejde med de samme artefakter og stadig få vist forskellige data.Different users can work with those same artifacts all while seeing different data. Integrering understøtter RLS.Embedding supports RLS.

Du bør læse denne artikel, hvis du integrerer for brugere, der ikke anvender Power Bi (appen ejer dataene), hvilket er typisk ved et Independent Software Vendor-scenarie (ISV).If you're embedding for non-Power BI users (app owns data), which is typically an ISV scenario, then this article is for you! Konfigurer integreringstokenet for at tage højde for brugeren og rollen.Configure the embed token to account for the user and role.

Hvis du integrerer til Power BI-brugere (brugeren ejer dataene) i din organisation, fungerer sikkerhed på rækkeniveau på samme måde, som det gør direkte i Power BI-tjenesten.If you're embedding to Power BI users (user owns data), within your organization, RLS works the same as it does within the Power BI service directly. Der er ikke mere, du skal gøre i dit program.There's nothing more you need to do in your application. Du kan finde flere oplysninger i Sikkerhed på rækkeniveau med Power BI.For more information, see Row-Level security (RLS) with Power BI.

Vigtige elementer i forbindelse med sikkerhed på rækkeniveau.

Hvis du vil benytte sikkerhed på rækkeniveau, er der tre vigtige begreber, du skal kende: brugere, roller og regler.To take advantage of RLS, it’s important you understand three main concepts; Users, Roles, and Rules. Lad os se nærmere på dem:Let’s take a closer look at each:

Brugere – slutbrugere, der får vist artefakten (dashboardet, feltet, rapporten eller datasættet).Users – End users viewing the artifact (dashboard, tile, report, or dataset). I Power BI Embedded identificeres brugerne ved hjælp af egenskaben username i et integreringstoken.In Power BI Embedded, users are identified by the username property in an embed token.

Roller – brugerne tilhører roller.Roles – Users belong to roles. En rolle er en objektbeholder til regler og kan have navne i stil med Sales Manager eller Sales Rep. Du opretter roller i Power BI Desktop.A role is a container for rules and can be named something like Sales Manager or Sales Rep. You create roles within Power BI Desktop. Du kan finde flere oplysninger i Sikkerhed på rækkeniveau med Power BI Desktop.For more information, see Row-level security (RLS) with Power BI Desktop.

Regler – rollerne har regler, og reglerne er de faktiske filtre, der anvendes på dataene.Rules – Roles have rules, and those rules are the actual filters that are going to be applied to the data. Reglerne kan f.eks. være noget så simpelt som "Country = USA" eller noget, der er meget mere dynamisk.The rules could be as simple as “Country = USA” or something much more dynamic. Resten af denne artikel indeholder et eksempel på, hvordan du opretter sikkerhed på rækkeniveau og derefter bruger det i et integreret program.For the rest of this article, there's an example of authoring RLS, and then consuming that within an embedded application. Vi bruger PBIX-filen Retail Analysis Sample i eksemplet.Our example uses the Retail Analysis Sample PBIX file.

Eksempel på rapport

Tilføj roller med Power BI DesktopAdding roles with Power BI Desktop

I eksemplet Retail Analysis vises salgstallene for alle butikkerne i en detailkæde.Our Retail Analysis sample shows sales for all the stores in a retail chain. Uden sikkerhed på rækkeniveau får områdecheferne vist de samme data, når de logger på og åbner rapporten.Without RLS, no matter which district manager signs in and views the report, they all see the same data. Den øverste ledelse har besluttet, at de enkelte områdechefer kun skal kunne se salgstallene for de butikker, som de styrer.Senior management has determined each district manager should only see the sales for the stores they manage. Ved hjælp af sikkerhed på rækkeniveau kan en øverste ledelse begrænse data på baggrund af en distriktschef.Using RLS allows Senior management to restrict data based on a district manager.

Sikkerhed på rækkeniveau oprettes i Power BI Desktop.RLS is authored in Power BI Desktop. Når datasættet og rapporten åbnes, kan vi skifte til diagramvisning for at se skemaet:When the dataset and report are opened, we can switch to diagram view to see the schema:

Diagramvisning i Power BI Desktop

Her er nogle ting, du bør bemærke i dette skema:Here are a few things to notice with this schema:

  • Alle mål, f.eks. Total Sales, gemmes i faktatabellen Sales.All measures, like Total Sales, are stored in the Sales fact table.

  • Der er fire andre relaterede tabeller med mål: Item, Time, Store og District.There are four additional related dimension tables: Item, Time, Store, and District.

  • Pilene på relationslinjerne angiver, hvilken vej filtrene kan gå fra en tabel til en anden.The arrows on the relationship lines indicate which way filters can flow from one table to another. Hvis der f.eks. filtreres på Time[Date] , vil det kun være værdierne fra tabellen Sales, der medtages i det aktuelle skema.For example, if a filter is placed on Time[Date], in the current schema it would only filter down values in the Sales table. Ingen andre tabeller vil blive påvirket af dette filter, da alle pilene på relationslinjerne peger mod tabellen Sales og ikke væk fra den.No other tables are affected by this filter since all the arrows on the relationship lines point to the sales table and not away.

  • Tabellen District angiver, hvem der er chef for hvert område:The District table indicates who the manager is for each district:

    Rækker i tabellen District

Hvis vi ud fra dette skema anvender et filter på kolonnen District Manager i tabellen District, og hvis filteret stemmer overens med den bruger, der får vist rapporten, vil filteret også vise værdierne fra tabellerne Store og Sales, så det kun er data for den pågældende områdechef, der vises.Based on this schema, if we apply a filter to the District Manager column in the District table, and if that filter matches the user viewing the report, that filter down the Store and Sales tables to show data for that district manager.

Sådan gør du:Here's how:

  1. Vælg Administrer roller under fanen Udformning.On the Modeling tab, select Manage Roles.

    Fanen Udformning i Power BI Desktop

  2. Opret en ny rolle, der kaldes Manager.Create a new role called Manager.

    Opret en ny rolle

  3. Angiv DAX-udtrykket [District Manager] = USERNAME() i tabellen District.In the District table, enter this DAX expression: [District Manager] = USERNAME().

    DAX-udtryk til regel for sikkerhed på rækkeniveau

  4. Du kan kontrollere, at reglen virker, ved at vælge Vis som roller under fanen Udformning og derefter vælge både rollen Chef, som du har oprettet, og rollen Andre brugere.To make sure the rules are working, on the Modeling tab, select View as Roles, and then select both the Manager role you created, along with Other users. Angiv AndrewMa som bruger.Enter AndrewMa for the user.

    Dialogboksen Vis som roller

    De data, der nu bliver vist i rapporten, er dem, der bliver vist, når du logger på som AndrewMa.The reports show data as if you're signed in as AndrewMa.

Når du anvender filteret på den måde, som vi gjorde her, vises alle de relevante værdier fra tabellerne District, Store og Sales.Applying the filter, the way we did here, filters down all records in the District, Store, and Sales tables. Men på grund af filtreringsretningen for relationen mellem tabellerne Sales og Time, vises værdierne fra tabellerne Sales og Item og Item og Time ikke.However, because of the filter direction on the relationships between Sales and Time, Sales and Item, and Item and Time tables aren't filtered down. Du kan få mere at vide om tovejskrydsfiltrering ved at downloade hvidbogen Bidirectional cross-filtering in SQL Server Analysis Services 2016 and Power BI Desktop.To learn more about bidirectional cross-filtering, download the Bidirectional cross-filtering in SQL Server Analysis Services 2016 and Power BI Desktop whitepaper.

Anvend bruger og rolle for at integrere et tokenApplying user and role to an embed token

Nu hvor du har konfigureret roller i Power BI Desktop, er der nogle opgaver, du skal udføre i dit program, så du kan udnytte rollerne.Now that you have your Power BI Desktop roles configured, there's some work needed in your application to take advantage of the roles.

Brugerne godkendes af dit program, og integreringstokens bruges til at give en bruger adgang til en bestemt rapport i Power BI Embedded.Users are authenticated and authorized by your application and embed tokens are used to grant that user access to a specific Power BI Embedded report. Der findes ingen specifikke oplysninger om, hvem brugeren er, i Power BI Embedded.Power BI Embedded doesn’t have any specific information on who your user is. Hvis sikkerhed på rækkeniveau skal fungere, skal du overføre ekstra kontekst som en del af dit integreringstoken i form af identiteter.For RLS to work, you need to pass some additional context as part of your embed token in the form of identities. Du kan overføre identiteterne ved hjælp af API'en Integrer Token.You can pass the identities by using the Embed Token API.

API'en accepterer en liste over identiteter med angivelse af de relevante datasæt.The API accepts a list of identities with indication of the relevant datasets. Hvis sikkerhed på rækkeniveau skal fungere, skal du overføre nedenstående dele som en del af identiteten.For RLS to work, you need to pass the below pieces as part of the identity.

  • username (obligatorisk) – en streng, der kan bruges til at identificere brugeren, når reglerne for sikkerhed på rækkeniveau anvendes.username (mandatory) – A string that can be used to help identify the user when applying RLS rules. Du kan kun angive én enkelt bruger.Only a single user can be listed. Dit brugernavn kan oprettes med ASCII-tegn.Your username can be created with ASCII characters.
  • roles (obligatorisk) – en streng med de roller, der skal vælges, når reglerne for sikkerhed på rækkeniveau anvendes.roles (mandatory) – A string containing the roles to select when applying Row Level Security rules. Hvis du overfører mere end én rolle, skal de overføres som en strengmatrix.If passing more than one role, they should be passed as a string array.
  • dataset (obligatorisk) – det datasæt, der gælder for det artefakt, du integrerer.dataset (mandatory) – The dataset that is applicable for the artifact you're embedding.

Du kan oprette integreringstokenet ved hjælp af metoden GenerateTokenInGroupPowerBIClient.Reports.You can create the embed token by using the GenerateTokenInGroup method on PowerBIClient.Reports.

Du kan f.eks. ændre eksemplet PowerBIEmbedded_AppOwnsData.For example, you could change the PowerBIEmbedded_AppOwnsData sample. Services\EmbedService.cs line 76 and 77 kunne opdateres fra:Services\EmbedService.cs line 76 and 77 could be updated from:

// Generate Embed Token.
var generateTokenRequestParameters = new GenerateTokenRequest(accessLevel: "view");

var tokenResponse = await client.Reports.GenerateTokenInGroupAsync(GroupId, report.Id, generateTokenRequestParameters);

toto

var generateTokenRequestParameters = new GenerateTokenRequest("View", null, identities: new List<EffectiveIdentity> { new EffectiveIdentity(username: "username", roles: new List<string> { "roleA", "roleB" }, datasets: new List<string> { "datasetId" }) });

var tokenResponse = await client.Reports.GenerateTokenInGroupAsync("groupId", "reportId", generateTokenRequestParameters);

Hvis du kalder REST-API'en, accepterer den opdaterede API nu en ekstra JSON-matrix med navnet identities, der indeholder et brugernavn, en liste over strengroller og en liste over strengdatasæt.If you're calling the REST API, the updated API now accepts an additional JSON array, named identities, containing a username, list of string roles and list of string datasets.

Brug følgende kode som et eksempel:Use the following code below as an example:

{
    "accessLevel": "View",
    "identities": [
        {
            "username": "EffectiveIdentity",
            "roles": [ "Role1", "Role2" ],
            "datasets": [ "fe0a1aeb-f6a4-4b27-a2d3-b5df3bb28bdc" ]
        }
    ]
}

Nu hvor alle delene er samlet, vil brugerne kun se de data, de har tilladelse til at få vist ifølge sikkerheden på rækkeniveau, når de logger på programmet for at få vist dette artefakt.Now, with all the pieces together, when someone logs into your application to view this artifact, they’ll only see the data that they're allowed to see, as defined by our row-level security.

Arbejde med Analysis Services-liveforbindelserWorking with Analysis Services live connections

Sikkerhed på rækkeniveau kan bruges med Analysis Services-liveforbindelser for lokale servere.Row-level security can be used with Analysis Services live connections for on-premises servers. Der er nogle specifikke begreber, du bør kende, når du bruger denne type forbindelse.There are a few specific concepts that you should understand when using this type of connection.

Den faktiske identitet, der leveres for egenskaben brugernavn, skal være en Windows-bruger med tilladelser til Analysis Services-serveren.The effective identity that is provided for the username property must be a Windows user with permissions on the Analysis Services server.

Konfigurer en datagateway i det lokale miljøOn-premises data gateway configuration

En datagateway i det lokale miljø bruges, når du arbejder med Analysis Services-liveforbindelser.An On-premises data gateway is used when working with Analysis Services live connections. Når du genererer et integreringstoken med et id angivet, skal den overordnede konto være angivet som en administrator af gatewayen.When generating an embed token, with an identity listed, the master account needs to be listed as an admin of the gateway. Hvis den overordnede konto ikke er angivet, anvendes sikkerhed på rækkeniveau ikke på egenskaben for dataene.If the master account isn't listed, the row-level security isn't applied to the property of the data. En bruger uden administrative rettigheder kan levere roller, men skal angive sit eget brugernavn til den eksisterende identitet.A non-admin of the gateway can provide roles, but must specify its own username for the effective identity.

Brug af rollerUse of roles

Roller kan angives med identiteten i et integreringstoken.Roles can be provided with the identity in an embed token. Hvis der ikke angives nogen rolle, bruges det brugernavn, der blev angivet, til at løse de tilknyttede roller.If no role is provided, the username that was provided can be used to resolve the associated roles.

Brug af funktionen CustomDataUsing the CustomData feature

Funktionen CustomData fungerer kun for modeller, der findes i Azure Analysis Services, og den fungerer kun i Connect-livetilstand.The CustomData feature only works for models that lie in Azure Analysis Services, and it only works in Connect live mode. Til forskel fra brugere og roller kan CustomData-funktionen ikke angives i en PBIX-fil.Unlike users and roles, the Custom data feature can't be set inside a .pbix file. Når et token genereres med funktionen CustomData, skal du have et brugernavn.When generating a token with the Custom data feature, you need to have a username.

Funktionen CustomData gør det muligt for dig at tilføje et rækkefilter, når du får vist Power BI-data i dit program, mens du bruger Azure Analysis Services som datakilde (visning af Power BI-data, der er forbundet med Azure Analysis Services i dit program).The CustomData feature allows you to add a Row filter when viewing Power BI data in your application when using Azure Analysis Services as your data source (viewing Power BI data connected to Azure Analysis Services in your application).

Funktionen CustomData gør det muligt at fortolke fritekst (streng) vha. egenskaben CustomData for forbindelsesstrengen.The CustomData feature allows passing free text (string) using the CustomData connection string property. Analysis Services bruger denne værdi via funktionen CUSTOMDATA() .Analysis Services use this value via the CUSTOMDATA() function.

Den eneste måde, du kan få dynamisk sikkerhed på rækkeniveau (som bruger dynamiske værdier til filterevaluering) i Azure Analysis Services er at bruge funktionen CUSTOMDATA() .The only way to have dynamic RLS (which uses dynamic values for filter evaluation) in Azure Analysis Services, is using the CUSTOMDATA() function.

Du kan bruge den i rollen DAX-forespørgsel, og du kan bruge den uden en rolle i en DAX-målingsforespørgsel.You can use it inside the role DAX query, and you can use it without any role in a measure DAX query. Funktionen CustomData er en del af vores tokengenerations funktionalitet for følgende artefakter: dashboard, rapport og felt.CustomData feature is part of our token generation functionality for the following artifacts: dashboard, report, and tile. Dashboards kan have flere CustomData-identiteter (én pr. felt/model).Dashboards can have multiple CustomData identities (one per tile/model).

CustomData SDK-tilføjelserCustomData SDK Additions

Strengegenskaben CustomData blev føjet til vores effektive identitet i tokengenerationsscenariet.The CustomData string property was added to our effective identity in the token generation scenario.

[JsonProperty(PropertyName = "customData")]
public string CustomData { get; set; }

Identiteten kan oprettes med brugerdefinerede data vha. følgende kald:The identity can be created with custom data using the following call:

public EffectiveIdentity(string username, IList<string> datasets, IList<string> roles = null, string customData = null);

CustomData SDK-forbrugCustomData SDK Usage

Hvis du kalder REST-API'en, kan du tilføje brugerdefinerede data i hver enkelt identitet, f.eks.:If you're calling the REST API, you can add custom data inside each identity, for example:

{
    "accessLevel": "View",
    "identities": [
        {
            "username": "EffectiveIdentity",
            "roles": [ "Role1", "Role2" ],
            "customData": "MyCustomData",
            "datasets": [ "fe0a1aeb-f6a4-4b27-a2d3-b5df3bb28bdc" ]
        }
    ]
}

Her er trinnene, så du kan begynde at konfigurere funktionen CustomData() med dit Power BI Embedded-program.Here are the steps to begin setting up the CustomData() feature with your Power BI Embedded application.

  1. Opret din Azure Analysis Services-database.Create your Azure Analysis Services database. Log på din Azure Analysis Services-server via SQL Server Management Studio.Then sign in to your Azure Analysis Services server via SQL Server Management Studio.

    Opret en Azure Analysis Services-database

    Analysis Services-database

  2. Opret en rolle på Analysis Services-serveren.Create a Role in the Analysis Services server.

    Opret rolle

  3. Angiv dine generelle indstillinger.Set your General settings. Her angiver du rollenavn og angiver databasetilladelserne til Skrivebeskyttet.Here you give the Role Name and set the database permissions to Read only.

    Opret rolle – angiv generelle indstillinger

  4. Angiv indstillingerne for Medlemskab.Set the Membership settings. Her kan du tilføje de brugere, der berøres af denne rolle.Here you add te users that are affected by this role.

    Opret rolle – angiv indstillinger for medlemskab

  5. Angiv din DAX-forespørgsel for rækkefiltre ved hjælp af funktionenCUSTOMDATA() .Set your Row filters DAX query using the CUSTOMDATA() function.

    Opret rolle – angiv rækkefiltre

  6. Byg en PBI-rapport, og publicer den i et arbejdsområde med dedikeret kapacitet.Build a PBI report and publish it to a workspace with dedicated capacity.

    Eksempel på PBI-rapport

  7. Brug Power BI-API'er til at anvende funktionen CustomData i dit program.Use the Power BI APIs to use the CustomData feature in your application. Når et token genereres med funktionen CustomData, skal du have et brugernavn.When generating a token with the Custom data feature, you need to have a username. Brugernavnet skal være lig med UPN for masterbrugeren.The username must be equal to the UPN of the master user. Masterbrugeren skal være medlem af den eller de roller, du har oprettet.The master user must be a member of the role(s) you created. Hvis der ikke er angivet nogen roller, bruges alle de roller, masterbrugeren er medlem af, til evaluering af sikkerhed på rækkeniveau.If no role(s) are specified, then all the roles the master user is a member of are used for RLS evaluation.

    Når du arbejder med en tjenesteprincipal, skal du også udføre trinnene ovenfor i stedet for at bruge en masterkonto.When working with a service principal, you also need to do the above steps in place of using a master account. Når du genererer et integreret token, skal du bruge den tjenesteprincipalens objekt-id som brugernavn.When generating embed token, use the service principal object ID as the username.

    Bemærk

    Når du er klar til at udrulle dit program til produktion, må feltet eller indstillingen for masterbrugerkontoen ikke være synlig for slutbrugeren.When you're ready to deploy your application to production, the master user account field or option should not be visible to the end user.

    Få vist den kode, der skal føjes til funktionen CustomData.View the code to add the CustomData feature.

  8. Du kan nu få vist rapporten i dit program, før du anvender CustomData-værdierne, for at se alle de data rapporten indeholder.Now you can view the report in your application before applying the Custom data value(s) to see all the data your report holds.

    Inden CustomData anvendes

    Derefter skal du anvende Customdata-værdierne for at se, hvordan rapporten viser et andet sæt data.Then apply the Custom data value(s) to see how the report displays a different set of data. Når CustomData er anvendtAfter CustomData is applied

Brug af sikkerhed på rækkeniveau i forhold til JavaScript-filtreUsing RLS vs. JavaScript filters

Når du beslutter dig for at filtrere dine data i en rapport, kan du bruge RLS (sikkerhed på rækkeniveau) eller JavaScript-filtre.When deciding on filtering your data in a report, you can use row-level security (RLS) or JavaScript filters.

Sikkerhed på rækkeniveau er en funktion, der filtrerer data på datamodelniveau.Row-level security is a feature that filters data at the data model level. Din backend-datakilde styrer dine RLS-indstillinger.Your backend data source controls your RLS settings. Den integrerede tokengeneration, der er baseret på din datamodel, angiver brugernavnet og rollerne for sessionen.Based on your data model, the embed token generation sets the username and the roles for the session. Den kan ikke tilsidesættes, fjernet eller styres af koden på klientsiden, og derfor anses den for at være sikker.It cannot be overridden, removed, or controlled by the client-side code and that’s why it’s considered secure. Vi anbefaler brugen af RLS til filtrering af data på en sikker måde.We recommend using RLS for filtering data securely. Du kan filtrere data med RLS ved hjælp af en af nedenstående indstillinger.You can filter data with RLS by using one of the options below.

  • Konfiguration af roller i en Power BI-rapport.Configuring roles in a Power BI report.
  • Konfiguration af roller på datakildeniveau (kun direkte forbindelse til Analysis Services).Configuring roles at the data source level (Analysis Services live connection only).
  • Ved hjælp af programmering med et Integreringstoken via EffectiveIdentity.Programmatically with an Embed Token using EffectiveIdentity. Når du bruger et integreringstoken, går det faktiske filter gennem integreringstokenet for en bestemt session.When using an embed token, the actual filter passes through the embed token for a specific session.

JavaScript-filtre bruges til at tillade brugeren at forbruge en reduceret, omfangsangivet eller filtreret visning af dataene.JavaScript filters are used to allow the user to consume reduced, scoped, or a filtered view of the data. Men brugeren stadig har adgang til modelskematabeller, -kolonner og -målinger og kan potentielt få adgang til alle dataene der.However, the user still has access to the model schema tables, columns, and measures and potentially can access any data there. Begrænset dataadgang kan kun anvendes med sikkerhed på rækkeniveau og ikke via filtrerings-API'er på klientsiden.Restricted access to the data can only be applied with RLS and not through client-side filtering APIs.

Tokenbaseret identitet med Azure SQL Database (prøveversion)Token-based Identity with Azure SQL Database (Preview)

Den tokenbaserede identitet giver dig mulighed for at angive den eksisterende identitet for et indlejringstoken ved hjælp af adgangstokenet AAD (Azure Active Directory) til en Azure SQL Database.The token-based identity allows you to specify the effective identity for an embed token using Azure Active Directory (AAD) access token for an Azure SQL Database.

Kunder, der har deres data i Azure SQL Database, kan nu få glæde af en ny funktionalitet til at administrere brugere og deres adgang til data i Azure SQL, når der integreres med Power BI Embedded.Customers that hold their data in Azure SQL Database can now enjoy a new capability to manage users and their access to data in Azure SQL when integrating with Power BI Embedded.

Når du genererer indlejringstokenet, kan du angive den eksisterende identitet for en bruger i Azure SQL.When you're generating the embed token, you can specify the effective identity of a user in Azure SQL. Du kan angive den eksisterende identitet for en bruger ved at overføre AAD-adgangstokenet til serveren.You can specify the effective identity of a user by passing the AAD access token to the server. Adgangstokenet bruges til at hente de relevante data for den pågældende bruger fra Azure SQL i den pågældende session.The access token is used to pull only the relevant data for that user from Azure SQL, for that specific session.

Det kan bruges til at administrere visningen af hver enkelt bruger i Azure SQL eller til at logge på SQL Azure som en bestemt kunde i en database med flere lejere.It can be used to manage each user’s view in Azure SQL or to sign in to Azure SQL as a specific customer in a multi-tenant DB. Det kan også bruges til at anvende sikkerhed på rækkeniveau i den pågældende session i Azure SQL og kun hente de relevante data for den pågældende session, hvilket fjerner behovet for at administrere sikkerhed på rækkeniveau i Power BI.It can also apply row-level security on that session in Azure SQL and retrieve only the relevant data for that session, removing the need to manage RLS in Power BI.

Sådanne problemer med eksisterende identiteter gælder for RLS-regler direkte på Azure SQL Server.Such effective identity issues apply to RLS rules directly on the Azure SQL Server. Power BI Embedded bruger det angivne adgangstoken ved forespørgsler om data fra Azure SQL Server.Power BI Embedded uses the provided access token when querying data from the Azure SQL Server. UPN'et for brugerne (som adgangstokenet blev angivet for) er tilgængeligt som et resultat af funktionen USER_NAME() SQL.The UPN of the user (for which the access token was provided) is accessible as a result of the USER_NAME() SQL function.

Den tokenbaserede identitet gælder kun for DirectQuery-modeller på dedikeret kapacitet, som er forbundet med en Azure SQL Database, der er konfigureret til at tillade AAD-godkendelse (få mere at vide om AAD-godkendelse til Azure SQL Database).The token-based identity only works for DirectQuery models on dedicated capacity - connected to an Azure SQL Database, which is configured to allow AAD authentication (learn more about AAD authentication for Azure SQL Database). Datasættets datakilde skal konfigureres til at bruge slutbrugernes OAuth2-legitimationsoplysninger for at bruge en tokenbaseret identitet.The dataset’s data source must be configured to use end users’ OAuth2 credentials, to use a token-based identity.

Konfigurer Azure SQL Server

SDK-tilføjelser til tokenbaseret identitetToken-based Identity SDK additions

Identitetsblobegenskaben blev føjet til vores aktuelle identitet i tokengenereringsscenariet.The identity blob property was added to our effective identity in the token generation scenario.

[JsonProperty(PropertyName = "identityBlob")]
public IdentityBlob IdentityBlob { get; set; }

IdentityBlob-typen er en enkel JSON-struktur, der indeholder en værdistrengsegenskabThe IdentityBlob type is a simple JSON structure holding a value string property

[JsonProperty(PropertyName = "value")]
public string value { get; set; }

EffectiveIdentity kan oprettes med identitetsblob ved hjælp af følgende kald:The EffectiveIdentity can be created with identity blob using the following call:

public EffectiveIdentity(string username, IList<string> datasets, IList<string> roles = null, string customData = null, IdentityBlob identityBlob = null);

Identitetsblob kan oprettes ved hjælp af følgende kald.Identity blob can be created using the following call.

public IdentityBlob(string value);

Brug af tokenbaseret identitets-REST-APIToken-based Identity REST API Usage

Hvis du kalder REST-API'en, kan du tilføje identitetsblob i hver enkelt identitet.If you're calling the REST API, you can add identity blob inside each identity.

{
    "accessLevel": "View",
    "identities": [
        {
            "datasets": ["fe0a1aeb-f6a4-4b27-a2d3-b5df3bb28bdc"],
        “identityBlob”: {
            “value”: “eyJ0eXAiOiJKV1QiLCJh….”
         }
        }
    ]
}

Værdien i den pågældende identitetsblob skal være et gyldigt adgangstoken til Azure SQL Server (med en URL-adresse til en ressource for (https://database.windows.net/).The value provided in the identity blob should be a valid access token to Azure SQL Server (with a resource URL of (https://database.windows.net/).

Bemærk

Hvis du vil oprette et adgangstoken til Azure SQL, skal programmet have adgang til Azure SQL Database og Data Warehouse og delegeret tilladelse til Azure SQL Database-API til AAD-konfiguration af appregistrering i Azure-portalen.To be able to create an access token for Azure SQL, the application must have Access Azure SQL DB and Data Warehouse delegated permission to Azure SQL Database API on AAD app registration configuration in the Azure portal.

Programregistrering

Datagateway i det lokale miljø med tjenesteprincipalOn-premises data gateway with service principal

Kunder, der konfigurerer sikkerhed på rækkeniveau ved hjælp af en datakilde med direkte forbindelse via SQL Server Analysis Services (SSAS) kan benytte sig af den nye funktionalitet med en tjenesteprincipal til at administrere brugere og deres adgang til data i SSAS, når der integreres med Power BI Embedded.Customers that configure row-level security (RLS) using an SQL Server Analysis Services (SSAS) on-premises live connection data source can enjoy the new service principal capability to manage users and their access to data in SSAS when integrating with Power BI Embedded.

Ved hjælp af REST API'er til Power BI kan du angive den eksisterende identitet for direkte forbindelser via SSAS i det lokale miljø for et integreringstoken ved hjælp af et objekt for tjenesteprincipal.Using Power BI REST APIs, allows you to specify the effective identity for SSAS on-premises live connections for an embed token using a service principal object.

Indtil nu skulle masterbrugeren, som skulle generere integreringstokenet, være gatewayadministrator for at kunne angive den eksisterende identitet for direkte forbindelser via SSAS. I stedet for at kræve at brugeren er gatewayadministrator, kan gatewayadministratoren give brugeren dedikeret tilladelse til den pågældende datakilde, hvilket giver brugeren mulighed for at tilsidesætte den eksisterende identitet, når integreringstokenet genereres.Until now, to be able to specify the effective identity for SSAS on-premises live connection, the master user generating the embed token had to be a gateway admin. Now, instead of requiring the user to be gateway admin, the gateway admin can give the user dedicated permission to that data source, that allows the user to override the effective identity when generating the embed token. Denne nye funktionalitet gør det muligt at integrere med en tjenesteprincipal i forbindelse med en direkte forbindelse via SSAS.This new ability enables embedding with service principal for a live SSAS connection.

For at muliggøre dette scenarie bruger gatewayadministratoren Tilføj REST API for bruger af datakilde for at tildele tjenesteprincipalen tilladelsen ReadOverrideEffectiveIdentity for Power BI Embedded.To enable this scenario, the gateway admin uses the Add Datasource User REST API to give the service principal the ReadOverrideEffectiveIdentity permission for Power BI Embedded.

Du kan ikke angive denne tilladelse ved hjælp af administrationsportalen.You can't set this permission using the admin portal. Denne tilladelse kan kun angives ved hjælp af API'en.This permission is only set with the API. På administrationsportalen kan du se en angivelse for brugere og tjenesters hovednavne med disse tilladelser.In the admin portal, you see an indication for users and SPNs with such permissions.

Overvejelser og begrænsningerConsiderations and limitations

  • Tildeling af brugere til roller i Power BI-tjenesten påvirker ikke sikkerheden på rækkeniveau, når du anvender et integreringstoken.Assignment of users to roles within the Power BI service doesn't affect RLS when using an embed token.
  • Selvom Power BI-tjenesten ikke anvender indstillingen for sikkerhed på rækkeniveau for administratorer eller medlemmer med redigeringsrettigheder, vil den blive anvendt på dataene, når du angiver en identitet med et indlejringstoken.While the Power BI service doesn't apply RLS setting to admins or members with edit permissions, when you supply an identity with an embed token, it applies to the data.
  • Analysis Services-liveforbindelser understøttes på lokale servere.Analysis Services live connections are supported for on-premises servers.
  • Direkte forbindelser i Azure Analysis Services understøtter filtrering efter roller.Azure Analysis Services live connections support filtering by roles. Dynamisk filtrering kan udføres ved hjælp af CustomData.Dynamic filtering can be done using CustomData.
  • Hvis der ikke skal bruges sikkerhed på rækkeniveau på det underliggende datasæt, må GenerateToken-anmodningen ikke indeholde en eksisterende identitet.If the underlying dataset doesn’t require RLS, the GenerateToken request must not contain an effective identity.
  • Hvis det underliggende datasæt er en cloudmodel (cachelagret model eller DirectQuery), skal den eksisterende identitet indeholde mindst én rolle, ellers tildeles der ikke en rolle.If the underlying dataset is a cloud model (cached model or DirectQuery), the effective identity must include at least one role, otherwise role assignment doesn't occur.
  • En liste over identiteter gør det muligt at have flere identitetstokens ved integrering i dashboardet.A list of identities enables multiple identity tokens for dashboard embedding. For alle andre artefakter vil listen indeholde en enkelt identitet.For all others artifacts, the list contains a single identity.

Begrænsninger for tokenbaseret identitet (prøveversion)Token-based Identity limitations (Preview)

  • Denne funktion begrænser kun brugen sammen med Power BI Premium.This capability restricts use with Power BI Premium only.
  • Denne funktion fungerer ikke sammen med SQL Server i det lokale miljø.This capability doesn’t work with SQL Server on-premises.
  • Denne funktion fungerer ikke sammen med Multi-Geo.This capability doesn't work with multi-geo.

Har du flere spørgsmål?More questions? Prøv at spørge Power BI-community'etTry asking the Power BI Community