Sorszintű biztonság a Power BI EmbeddeddelRow-level security with Power BI Embedded

A sorszintű biztonság (RLS) a felhasználók adatokhoz való hozzáférésének korlátozására használható irányítópultoknál, csempéknél, jelentéseknél és adatkészleteknél.Row-level security (RLS) can be used to restrict user access to data within dashboards, tiles, reports, and datasets. Ugyanazokkal a összetevőkkel több felhasználó is dolgozhat egyszerre úgy, hogy más-másféle adatokat látnak.Different users can work with those same artifacts all while seeing different data. A beágyazás támogatja a RLS-t.Embedding supports RLS.

Ha nem Power BI-felhasználóknak végez beágyazást (alkalmazás tulajdonában lévő adatok, ez általában a szoftverszolgáltatóknál fordul elő), akkor ez a cikk Önnek szól.If you're embedding for non-Power BI users (app owns data), which is typically an ISV scenario, then this article is for you! Konfigurálnia kell a beágyazási tokent a felhasználó és a szerepkör figyelembe vételéhez.Configure the embed token to account for the user and role.

Ha Power BI-felhasználóknak végez beágyazást (a felhasználó az adatok tulajdonosa) a cégen belül, az RLS ugyanúgy működik, mintha közvetlenül a Power BI szolgáltatásban lenne.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. Nem kell semmi mást csinálnia az alkalmazásban.There's nothing more you need to do in your application. További információkat a Power BI sorszintű biztonság (RLS) használatával kapcsolatos részben találhat.For more information, see Row-Level security (RLS) with Power BI.

A sorszintű biztonságban szereplő elemek.

Az RLS kihasználása érdekében fontos megérteni a három fő alapelvet: a felhasználókat, a szerepköröket és a szabályokat.To take advantage of RLS, it’s important you understand three main concepts; Users, Roles, and Rules. Tekintsük meg közelebbről ezeket az alapelveket:Let’s take a closer look at these concepts:

Felhasználók – Az összetevőket (irányítópultokat, csempéket, jelentéseket vagy adatkészleteket) megtekintő tényleges végfelhasználók.Users – End users viewing the artifact (dashboard, tile, report, or dataset). A Power BI Embedded esetében a felhasználókat beágyazási jogkivonatban lévő felhasználónév tulajdonság azonosítja.In Power BI Embedded, users are identified by the username property in an embed token.

Szerepkörök – A felhasználók szerepkörökhöz tartoznak.Roles – Users belong to roles. A szerepkörök szabályok tárolói és olyan nevük lehet, mint Értékesítési igazgató vagy Értékesítési képviselő. A Power BI Desktopban hozhat létre szerepköröket.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. További információkat a sorszintű biztonság (RLS) Power BI Desktoppal való használatával kapcsolatos részben találhat.For more information, see Row-level security (RLS) with Power BI Desktop.

Szabályok – A szerepkörök szabályokkal rendelkeznek, és ezek a szabályok az adatokra alkalmazott tényleges szűrők.Rules – Roles have rules, and those rules are the actual filters that are going to be applied to the data. A szabályok lehetnek olyan egyszerűek, mint a „Country = USA”, vagy sokkal dinamikusabbak is lehetnek.The rules could be as simple as “Country = USA” or something much more dynamic. A cikk hátralévő részében egy példa szerepel az RLS elkészítésére és beágyazott alkalmazásban való használatára.For the rest of this article, there's an example of authoring RLS, and then consuming that within an embedded application. A példánk a Kiskereskedelmi elemzési minta PBIX-fájlját használja.Our example uses the Retail Analysis Sample PBIX file.

Jelentéspélda

Szerepkörök hozzáadása a Power BI DesktoppalAdding roles with Power BI Desktop

A Kiskereskedelmi elemzési minta egy kiskereskedelmi láncban lévő összes áruház értékesítéseit jeleníti meg.Our Retail Analysis sample shows sales for all the stores in a retail chain. Az RLS nélkül nem számít, hogy melyik kerület menedzsere jelentkezik be és tekinti meg a jelentést, mindegyik ugyanazokat az adatokat látja.Without RLS, no matter which district manager signs in and views the report, they all see the same data. A felső vezetőség meghatározta, hogy mindegyik kerületi menedzser csak az általuk kezelt áruházak értékesítéseit láthatja.Senior management has determined each district manager should only see the sales for the stores they manage. Az RLS használata lehetővé teszi, hogy a felső vezetőség az adatokat a kerületi menedzser alapján korlátozza.Using RLS allows Senior management to restrict data based on a district manager.

Az RLS a Power BI Desktopban készül.RLS is authored in Power BI Desktop. Az adatkészlet és a jelentés megnyitásakor diagramnézetre válthatunk a séma megtekintéséhez:When the dataset and report are opened, we can switch to diagram view to see the schema:

Diagramnézet a Power BI Desktopban

Ebben a sémában a következőket érdemes megfigyelni:Here are a few things to notice with this schema:

  • Minden mérték (például a Total Sales (Összes értékesítés)) a Sales (Értékesítések) ténytáblában van tárolva.All measures, like Total Sales, are stored in the Sales fact table.

  • Négy további kapcsolódó dimenziótábla van: Item (Tétel), Time (Idő), Store (Áruház) és District (Kerület).There are four additional related dimension tables: Item, Time, Store, and District.

  • A kapcsolatvonalakon lévő nyilak jelzik, milyen irányba haladhatnak a szűrők az egyik táblából egy másikba.The arrows on the relationship lines indicate which way filters can flow from one table to another. Ha például egy szűrő a Time[Date] (Idő [Dátum]) táblára van helyezve, a jelenlegi sémában csak a Sales (Értékesítések) táblába szűrne lefelé értékeket.For example, if a filter is placed on Time[Date], in the current schema it would only filter down values in the Sales table. Ez a szűrő nincs hatással más táblákra, mert a kapcsolatvonalakon lévő összes nyíl az értékesítések táblára mutat, és nem a másik irányba.No other tables are affected by this filter since all the arrows on the relationship lines point to the sales table and not away.

  • A District (Kerület) tábla jelzi, hogy ki az egyes kerületek menedzsere:The District table indicates who the manager is for each district:

    A District (Kerület) táblában lévő sorok

Ezen séma alapján, ha szűrőt alkalmazunk a District (Kerület) táblában lévő District Manager (Kerületi menedzser) oszlopra, és ha ez a szűrő megfelel a jelentést megtekintő felhasználónak, akkor a szűrő a Store (Áruház) és a Sales (Értékesítések) táblákra is szűr, hogy az adott menedzser adatait jelenítse meg.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.

Ezt a következőképpen teheti meg:Here's how:

  1. A Modellezés lapon válassza a Szerepkörök kezelése lehetőséget.On the Modeling tab, select Manage Roles.

    Modellezés lap a Power BI Desktopban

  2. Hozzon létre egy Manager (Menedzser) nevű új szerepkört.Create a new role called Manager.

    Új szerepkör létrehozása

  3. A District (Kerület) táblában írja be ezt a DAX-kifejezést: [District Manager] = USERNAME() .In the District table, enter this DAX expression: [District Manager] = USERNAME().

    DAX-utasítás RLS-szabályhoz

  4. A szabályok működésének biztosítása érdekében a Modellezés lapon válassza a Megtekintés szerepkörökként lehetőséget, majd válassza ki a most létrehozott Manager szerepkört és az Egyéb felhasználó szerepkört is.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. Írja be felhasználóként az AndrewMa nevet.Enter AndrewMa for the user.

    Megtekintés szerepkörökként párbeszédpanel

    A jelentések most úgy jelenítenek meg adatokat, mintha AndrewMa néven lenne bejelentkezve.The reports show data as if you're signed in as AndrewMa.

A szűrő alkalmazásával, ahogyan itt tettük, a District (Kerület), Store (Áruház) és Sales (Értékesítések) táblákban lévő összes rekordot szűri.Applying the filter, the way we did here, filters down all records in the District, Store, and Sales tables. A Sales (Értékesítések) és a Time (Idő) közötti kapcsolat szűrőiránya miatt azonban a Sales (Értékesítések) és az Item (Tétel), illetve az Item (Tétel) és a Time (Idő) táblákra nem szűr le.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. A kétirányú keresztszűrésről további információért töltse le az SQL Server Analysis Services 2016-ban és a Power BI Desktopban használatható kétirányú keresztszűrést ismertető tanulmányt.To learn more about bidirectional cross-filtering, download the Bidirectional cross-filtering in SQL Server Analysis Services 2016 and Power BI Desktop whitepaper.

Felhasználó és szerepkör alkalmazása beágyazási tokenreApplying user and role to an embed token

Most, hogy konfigurálva vannak a Power BI Desktop-szerepkörök, el kell végezni néhány dolgot az alkalmazásban a szerepkörök kihasználása érdekében.Now that you have your Power BI Desktop roles configured, some more work needs to be done in your application to take advantage of the roles.

Az alkalmazás hitelesíti és engedélyezi a felhasználókat és beágyazási tokenekkel ad hozzáférést ezeknek a felhasználóknak egy adott Power BI Embedded-jelentéshez.Users are authenticated and authorized by your application and embed tokens are used to grant a user access to a specific Power BI Embedded report. A Power BI Embedded nem rendelkezik konkrét információkkal arról, hogy ki a felhasználó.Power BI Embedded doesn’t have any specific information on who your user is. Az RLS működéséhez további kontextust kell megadnia a beágyazási token részeként identitások formájában.For RLS to work, you need to pass some additional context as part of your embed token in the form of identities. Az identitásokat a Beágyazási token API-val adhatja át.You can pass the identities by using the Embed Token API.

Az API olyan identitások listáját fogadja el, amelyben jelezve vannak a kapcsolódó adatkészletek.The API accepts a list of identities with indication of the relevant datasets. Annak érdekében, hogy az RLS működjön, az alábbiakat kell átadnia az identitás részeként.For RLS to work, you need to pass the below pieces as part of the identity.

  • username (kötelező) – Egy sztring, amellyel azonosítható a felhasználó az RLS-szabályok alkalmazásakor.username (mandatory) – A string that can be used to help identify the user when applying RLS rules. Csak egyetlen felhasználó sorolható fel.Only a single user can be listed. Az Ön felhasználóneve ASCII karakterekkel hozható létre.Your username can be created with ASCII characters.
  • roles (kötelező) – Sorszintű biztonsági szabályok alkalmazásakor kiválasztható szerepköröket tartalmazó sztring.roles (mandatory) – A string containing the roles to select when applying Row Level Security rules. Több szerepkör átadásakor sztringtömbként kell azokat átadni.If passing more than one role, they should be passed as a string array.
  • dataset (kötelező) – Az épp beágyazott összetevőre érvényes adatkészlet.dataset (mandatory) – The dataset that is applicable for the artifact you're embedding.

A beágyazási token létrehozásához használja a PowerBIClient.Reports GenerateTokenInGroup metódusát.You can create the embed token by using the GenerateTokenInGroup method on PowerBIClient.Reports.

Módosíthatja például a PowerBIEmbedded_AppOwnsData mintát.For example, you could change the PowerBIEmbedded_AppOwnsData sample. A Services\EmbedService.cs 76. és 77. sora a következőről frissíthető: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);

Ha a REST API-t hívja meg, a frissített API már elfogad egy további, identities nevű JSON-tömböt, amely tartalmaz egy felhasználónevet, a szerepkörök sztringlistáját és az adatkészletek karakterlánclistájá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.

Használja példaként az alábbi kódot:Use the following code below as an example:

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

Most, hogy minden együtt van, amikor valaki bejelentkezik az alkalmazásba az összetevő megtekintéséhez, csak a számukra engedélyezett adatokat láthatja, ahogyan azt a sorszintű biztonság meghatározza.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.

Élő Analysis Services-kapcsolatok használataWorking with Analysis Services live connections

A sorszintű biztonság használható az élő Analysis Services-kapcsolatokkal a helyszíni kiszolgálókhoz.Row-level security can be used with Analysis Services live connections for on-premises servers. Néhány speciális alapelvet meg kell értenie, amikor ilyen típusú kapcsolatot használ.There are a few specific concepts that you should understand when using this type of connection.

A felhasználónév tulajdonsághoz megadott hatályos identitásnak Windows-felhasználónak kell lennie, amely rendelkezik engedélyekkel az Analysis Services-kiszolgálóhoz.The effective identity that is provided for the username property must be a Windows user with permissions on the Analysis Services server.

Helyszíni adatátjáró konfigurációjaOn-premises data gateway configuration

Az élő Analysis Services-kapcsolatok használatakor helyszíni adatátjárót kell használni.An On-premises data gateway is used when working with Analysis Services live connections. Az identitást tartalmazó beágyazási token létrehozásakor a fő fióknak az átjáró rendszergazdájaként kell szerepelnie.When generating an embed token, with an identity listed, the master account needs to be listed as an admin of the gateway. Ha a fő fiók nincs felsorolva, a sorszintű biztonság nem fog érvényesülni az adatok tulajdonságán.If the master account isn't listed, the row-level security isn't applied to the property of the data. Az átjáró nem rendszergazda felhasználója megadhat szerepköröket, de a saját felhasználónevét kell megadnia a hatályos identitáshoz.A non-admin of the gateway can provide roles, but must specify its own username for the effective identity.

Szerepkörök használataUse of roles

A szerepkörök az identitással adhatók meg a beágyazási tokenekben.Roles can be provided with the identity in an embed token. Ha nincs megadva szerepkör, a rendszer a megadott felhasználónévvel oldja fel a társított szerepköröket.If no role is provided, the username that was provided can be used to resolve the associated roles.

A CustomData funkció használataUsing the CustomData feature

A CustomData funkció csak az Azure Analysis Services szolgáltatásban található modelleken, és csak az Élő csatlakozás módban működik.The CustomData feature only works for models that lie in Azure Analysis Services, and it only works in Connect live mode. A felhasználókkal és a szerepkörökkel ellentétben a CustomData funkció nem használható .pbix-fájlokban.Unlike users and roles, the Custom data feature can't be set inside a .pbix file. Ha a CustomData funkcióval hoz létre tokent, felhasználónévvel kell rendelkeznie.When generating a token with the Custom data feature, you need to have a username.

A CustomData funkció lehetővé teszi sorszűrő hozzáadását, amikor Power BI-adatokat tekint meg az alkalmazásában az Azure Analysis Services adatforrásként való használatakor (az Azure Analysis Serviceshez kapcsolódó Power BI-adatok megtekintésekor az alkalmazásban).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).

A CustomData funkció lehetővé teszi szabad szöveg (sztring) átadását a CustomData kapcsolatisztring-tulajdonság használatával.The CustomData feature allows passing free text (string) using the CustomData connection string property. Az Analysis Services ezt az értéket a CUSTOMDATA() függvényen keresztül használja.Analysis Services use this value via the CUSTOMDATA() function.

Az Azure Analysis Services szolgáltatásban a dinamikus RLS (amely dinamikus értékeket használ a szűrő kiértékelésére) használatának egyetlen módja a CUSTOMDATA() függvény alkalmazása.The only way to have dynamic RLS (which uses dynamic values for filter evaluation) in Azure Analysis Services, is using the CUSTOMDATA() function.

A szerepkör DAX-lekérdezésében is használhatja, valamint szerepkör nélkül egy mérték DAX-lekérdezésében.You can use it inside the role DAX query, and you can use it without any role in a measure DAX query. A CustomData funkció az alábbi összetevők tokenlétrehozási funkcióinak egyik eleme: irányítópult, jelentés és csempe.CustomData feature is part of our token generation functionality for the following artifacts: dashboard, report, and tile. Az irányítópultok több CustomData-identitással rendelkezhetnek (csempénként/modellenként eggyel).Dashboards can have multiple CustomData identities (one per tile/model).

A CustomData SDK-bővítményeiCustomData SDK Additions

A CustomData sztringtulajdonságot hozzáadtuk a tokenlétrehozási forgatókönyvbeli hatályos identitásunkhoz.The CustomData string property was added to our effective identity in the token generation scenario.

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

Az identitás egyéni adatokkal, az alábbi hívással hozható létre: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);

A CustomData SDK-használataCustomData SDK Usage

A REST API meghívásánál minden identitáshoz egyéni adatokat adhat meg, például: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" ]
        }
    ]
}

Az alábbi lépések követésével megkezdheti a CustomData() függvény beállítását a Power BI Embedded alkalmazáshoz.Here are the steps to begin setting up the CustomData() feature with your Power BI Embedded application.

  1. Hozzon létre egy Azure Analysis Services-adatbázist.Create your Azure Analysis Services database. Majd jelentkezzen be az Azure Analysis Services-kiszolgálóra az SQL Server Management Studióval.Then sign in to your Azure Analysis Services server via SQL Server Management Studio.

    Azure Analysis Services-adatbázis létrehozása

    Analysis Services-adatbázis

  2. Hozzon létre egy szerepkört az Analysis Services-kiszolgálón.Create a Role in the Analysis Services server.

    Szerepkör létrehozása

  3. Adja meg az Általános beállításokat.Set your General settings. Itt megadhatja a Szerepkörnév értékét, és beállíthatja a csak olvasható adatbázis-jogosultságot.Here you give the Role Name and set the database permissions to Read only.

    Szerepkör létrehozása – általános beállítások megadása

  4. Adja meg a Tagság beállításait.Set the Membership settings. Itt veheti fel a szerepkör által érintett felhasználókat.Here you add te users that are affected by this role.

    Szerepkör létrehozása – tagsági beállítások megadása

  5. Állítsa be a Sorszűrők DAX-lekérdezését a CUSTOMDATA() függvénnyel.Set your Row filters DAX query using the CUSTOMDATA() function.

    Szerepkör létrehozása – sorszűrők beállítása

  6. Hozzon létre egy PBI-jelentést, és tegye közzé egy dedikált kapacitással rendelkező munkaterületen.Build a PBI report and publish it to a workspace with dedicated capacity.

    PBI-jelentésminta

  7. Használja a Power BI API-kat a CustomData funkció használatára az alkalmazásában.Use the Power BI APIs to use the CustomData feature in your application. Ha a CustomData funkcióval hoz létre tokent, felhasználónévvel kell rendelkeznie.When generating a token with the Custom data feature, you need to have a username. A felhasználónévnek meg kell egyeznie a fő felhasználó egyszerű felhasználónevével.The username must be equal to the UPN of the master user. A fő felhasználónak a létrehozott szerepkör tagjának kell lennie.The master user must be a member of the role(s) you created. Ha nincs szerepkör megadva, akkor a rendszer minden szerepkört felhasznál az RLS kiértékelésére, amelynek a fő felhasználó a tagja.If no role(s) are specified, then all the roles the master user is a member of are used for RLS evaluation.

    Ha szolgáltatásnévvel dolgozik, fő fiók használata helyett a fenti lépéseket kell elvégeznie.When working with a service principal, you also need to do the above steps in place of using a master account. Beágyazási token létrehozásakor a felhasználónévnek használja a szolgáltatásnév objektumazonosítóját felhasználónévként.When generating embed token, use the service principal object ID as the username.

    Megjegyzés

    Ha készen áll az alkalmazás éles környezetben történő üzembe helyezésére, a fő felhasználói fiók mezője vagy beállítása nem lehet látható a végfelhasználó számára.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.

    Tekintse meg a kódot a CustomData funkció hozzáadásához.View the code to add the CustomData feature.

  8. Most megtekintheti a jelentést az alkalmazásában a CustomData-érték(ek) alkalmazása előtt a jelentésben lévő összes adat megjelenítéséhez.Now you can view the report in your application before applying the Custom data value(s) to see all the data your report holds.

    A CustomData alkalmazása előtt

    Ezután alkalmazza a Customdata-értéke(ke)t, hogy láthassa, hogyan jelenít meg a jelentés egy másik adatkészletet.Then apply the Custom data value(s) to see how the report displays a different set of data. A CustomData alkalmazása utánAfter CustomData is applied

Az RLS és a JavaScript-szűrők használatának összehasonlításaUsing RLS vs. JavaScript filters

Ha a jelentés adainak szűrése mellett dönt, használhat sorszintű biztonságot (RLS) vagy JavaScript-szűrőket.When deciding on filtering your data in a report, you can use row-level security (RLS) or JavaScript filters.

A sorszintű biztonság olyan szolgáltatás, amely az adatmodell szintjén szűri az adatokat.Row-level security is a feature that filters data at the data model level. A háttéralkalmazás adatforrása szabályozza az RLS-beállításait.Your backend data source controls your RLS settings. Az adatmodell alapján a beágyazási tokengenerálás állítja be a felhasználónevet és a szerepköröket a munkamenethez.Based on your data model, the embed token generation sets the username and the roles for the session. Nem lehet felülírni, eltávolítani vagy vezérelni az ügyféloldali kóddal, és ezért számít biztonságosnak.It cannot be overridden, removed, or controlled by the client-side code and that’s why it’s considered secure. Az adatok biztonságos szűréséhez az RLS-t ajánljuk.We recommend using RLS for filtering data securely. Az adatokat az RLS-sel az alábbi lehetőségek egyikének használatával szűrheti.You can filter data with RLS by using one of the options below.

  • Szerepkörök konfigurálása Power BI-jelentésekben.Configuring roles in a Power BI report.
  • Szerepkörök konfigurálása az adatforrás szintjén (csak Analysis Services élő kapcsolat esetén).Configuring roles at the data source level (Analysis Services live connection only).
  • Programozott módon egy beágyazási tokennel az EffectiveIdentity használatával.Programmatically with an Embed Token using EffectiveIdentity. Beágyazási token használatakor a tényleges szűrő áthalad a beágyazási tokenen az adott munkamenetnél.When using an embed token, the actual filter passes through the embed token for a specific session.

A JavaScript-szűrők lehetővé teszik, hogy a felhasználó csökkentett, hatókörön belüli vagy szűrt nézetet lásson az adatokról.JavaScript filters are used to allow the user to consume reduced, scoped, or a filtered view of the data. A felhasználó azonban továbbra is rendelkezik hozzáféréssel a modellséma tábláihoz, oszlopaihoz és mértékeihez, és elérheti az itt található bármely adatot.However, the user still has access to the model schema tables, columns, and measures and potentially can access any data there. Az adatok korlátozott elérése csak RLS-sel lehetséges, ügyféloldali szűrő API-kkal nem.Restricted access to the data can only be applied with RLS and not through client-side filtering APIs.

Jogkivonat alapú identitás Azure SQL Database esetén (előzetes verzió)Token-based Identity with Azure SQL Database (Preview)

Jogkivonat-alapú identitással úgy adhatja meg egy beágyazási jogkivonat hatályos identitását, hogy Azure Active Directory (AAD) hozzáférési jogkivonatot használ az Azure SQL Database-hez.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.

Az adataikat Azure SQL Database-ben tároló ügyfelek új képesség kihasználásával kezelhetik felhasználóikat és azok adatokhoz való hozzáférését az Azure SQL-ben, a Power BI Embeddeddel való integráció esetén.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.

A beágyazási jogkivonat generálása során megadható egy felhasználó Azure SQL-ben hatályos identitása.When you're generating the embed token, you can specify the effective identity of a user in Azure SQL. Egy felhasználó hatályos identitása úgy adható meg, hogy átadja az AAD hozzáférési jogkivonatot a kiszolgálónak.You can specify the effective identity of a user by passing the AAD access token to the server. A hozzáférési jogkivonat használatának célja az, hogy az adott munkamenetben csak a felhasználót illető adatok legyenek lekérve az Azure SQL-ből.The access token is used to pull only the relevant data for that user from Azure SQL, for that specific session.

Használható egy felhasználói nézet kezelésére az Azure SQL-ben, vagy több-bérlős környezetben az Azure SQL-be egy adott ügyfélként való bejelentkezéshez.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. Használatával sorszintű biztonság alkalmazható a munkamenet során az Azure SQL-ben, így a munkamenet során csak a megfelelő adatok lesznek lekérve, tehát az RLS-t nem szükséges a Power BI-ban kezelni.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.

A hatályos identitást érintő ilyen kérdések az RLS-szabályokra vonatkoznak, közvetlenül az Azure SQL Serveren.Such effective identity issues apply to RLS rules directly on the Azure SQL Server. A Power BI Embedded akkor használja a megadott hozzáférési jogkivonatot, amikor adatokat kérdez le az Azure SQL Serverről.Power BI Embedded uses the provided access token when querying data from the Azure SQL Server. A felhasználó egyszerű felhasználónevét (amelyhez a hozzáférési jogkivonat meg lett adva) a USER_NAME() SQL-függvénnyel lehet megállapítani.The UPN of the user (for which the access token was provided) is accessible as a result of the USER_NAME() SQL function.

A jogkivonat-alapú identitás csak DirectQuery-modelleknél működik, dedikált kapacitáson – olyan Azure SQL Database-hez csatlakozva, amely AAD-hitelesítés engedélyezésére van konfigurálva (további tudnivalók az Azure SQL Database-hez használt AAD-hitelesítésről).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). Jogkivonat-alapú identitás használatához az adathalmaz adatforrásának konfigurálva kell lennie a végfelhasználók OAuth2 hitelesítő adatainak használatára.The dataset’s data source must be configured to use end users’ OAuth2 credentials, to use a token-based identity.

Az Azure SQL Server konfigurálása

Jogkivonat-alapú identitás SDK-bővítményeiToken-based Identity SDK additions

Az IdentityBlob tulajdonságot hozzáadtuk a jogkivonat-létrehozási forgatókönyvbeli hatályos identitásunkhoz.The identity blob property was added to our effective identity in the token generation scenario.

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

Az IdentityBlob típus egy érték sztring tulajdonságot tároló, egyszerű JSON-struktúraThe IdentityBlob type is a simple JSON structure holding a value string property

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

Az EffectiveIdentity a következő hívással hozható létre identitásblobbal: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);

Identitásblob az alábbi hívással hozható létre.Identity blob can be created using the following call.

public IdentityBlob(string value);

Jogkivonat-alapú identitás REST API használataToken-based Identity REST API Usage

Ha meghívja a REST API-t minden identitásba felvehet identitásblobot.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….”
         }
        }
    ]
}

Az identitásblobban megadott értéknek az Azure SQL Serverhez érvényes hozzáférési jogkivonatnak kell lennie (a következő forrás URL-címmel: 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/).

Megjegyzés

Ahhoz, hogy hozzáférési jogkivonatot hozhasson létre az Azure SQL-hez, az alkalmazásnak rendelkeznie kell hozzáféréssel az Azure SQL DB-hez és a Data Warehouse-hoz, valamint delegált jogosultsággal az Azure SQL Database API-hoz az AAD alkalmazásregisztrációs konfigurációban az Azure Portalon.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.

Alkalmazásregisztráció

Helyszíni adatátjáró szolgáltatásnévvelOn-premises data gateway with service principal

Azok az ügyfelek, akik SQL Server Analysis Services (SSAS) helyszíni, élő kapcsolatú adatforrásával konfigurálják a sorszintű biztonságot (RLS), használhatják az új szolgáltatásnév képességet a felhasználók és adatelérésük kezelésére az SSAS-ben a Power BI Embeddeddel létrehozott integráció során.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.

A Power BI REST API-k lehetővé teszik az SSAS helyszíni, élő kapcsolatok hatályos identitásának meghatározását a beágyazási tokenhez egy szolgáltatásnév-objektum használatával.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.

Eddig az SSAS helyszíni, élő kapcsolatai hatályos identitásának meghatározásához a beágyazási tokent létrehozó fő felhasználónak az átjáró adminisztrátorának kellett lennie. Most a felhasználónak nem szükséges az átjáró adminisztrátorának lennie, hanem az átjáró adminisztrátora dedikált engedélyt adhat a felhasználónak az adatforráshoz, amely lehetővé teszi, hogy felülbírálja a hatályos identitást a beágyazási token létrehozásakor.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. Ez az új képesség lehetővé teszi a szolgáltatásnévvel történő beágyazást az élő SSAS-kapcsolatoknál.This new ability enables embedding with service principal for a live SSAS connection.

E szerint a forgatókönyv szerint az átjáró adminisztrátora az Adatforrás-felhasználó hozzáadása REST API-t használja, hogy megadja a szolgáltatásnévnek a ReadOverrideEffectiveIdentity engedélyt a Power BI Embeddedhez.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.

A felügyeleti portálon ezt az engedélyt nem lehet beállítani.You can't set this permission using the admin portal. Ennek az engedélynek a megadása kizárólag az API-val történik.This permission is only set with the API. A felügyeleti portál jelzi az ilyen engedéllyel rendelkező felhasználókat és egyszerű szolgáltatásneveket.In the admin portal, you see an indication for users and SPNs with such permissions.

Megfontolandó szempontok és korlátozásokConsiderations and limitations

  • A Power BI szolgáltatásban a felhasználók szerepkörökhöz rendelése nincs hatással az RLS-re beágyazási token használatakor.Assignment of users to roles within the Power BI service doesn't affect RLS when using an embed token.
  • Bár a Power BI szolgáltatás nem alkalmazza az RLS-beállítást a rendszergazdákra vagy a szerkesztési engedélyekkel rendelkező tagokra, amikor beágyazási tokennel ad meg egy identitást, azt az adatokra alkalmazza.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.
  • Az élő Analysis Services-kapcsolatok a helyszíni kiszolgálókhoz támogatottak.Analysis Services live connections are supported for on-premises servers.
  • Az Azure Analysis Services élő kapcsolatai támogatják a szerepkör szerinti szűrést.Azure Analysis Services live connections support filtering by roles. Dinamikus szűrést a CustomData használatával végezhet.Dynamic filtering can be done using CustomData.
  • Ha a mögöttes adatkészlethez nincs szükség RLS-re, a GenerateToken kérés nem tartalmazhat hatályos identitást.If the underlying dataset doesn’t require RLS, the GenerateToken request must not contain an effective identity.
  • Ha a mögöttes adatkészlet felhőalapú modell (gyorsítótárazott modell vagy DirectQuery), a hatályos identitásnak tartalmaznia kell legalább egy szerepkört, mert ellenkező esetben a szerepkör-hozzárendelés sikertelen lesz.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.
  • Az identitáslista lehetővé teszi, hogy az irányítópultok beágyazásánál több identitásból álló tokent is lehessen használni.A list of identities enables multiple identity tokens for dashboard embedding. A lista minden más összetevő esetében csak egyetlen identitást tartalmaz.For all others artifacts, the list contains a single identity.

Jogkivonat-alapú identitás-korlátozások (előzetes verzió)Token-based Identity limitations (Preview)

  • Ez a képesség csak a Power BI Premiummal való használatot korlátozza.This capability restricts use with Power BI Premium only.
  • A képesség helyszíni SQL Serverrel nem működik.This capability doesn’t work with SQL Server on-premises.
  • Ez a képesség több földrajzi hely esetén nem működik.This capability doesn't work with multi-geo.

További kérdései vannak?More questions? Kérdezze meg a Power BI közösségétTry asking the Power BI Community