Vygenerování tokenu pro vložení

Platí pro:✅ Power BI vložené analýzy pro vaše zákazníky (data vlastní aplikace)

Generování tokenu je rozhraní REST API, které umožňuje vygenerovat token pro vložení sestavy Nebo sémantického modelu Power BI do webové aplikace nebo portálu. Může vygenerovat token pro jednu položku nebo pro více sestav nebo sémantických modelů. Token slouží k autorizaci vaší žádosti proti služba Power BI.

Rozhraní API vygenerovat token používá jedinou identitu (hlavního uživatele nebo služebního principála) k vygenerování tokenu pro jednotlivého uživatele v závislosti na jeho přihlašovacích údajích v aplikaci (efektivní identita).

Po úspěšném ověření se udělí přístup k příslušným datům.

Poznámka:

Generování tokenu je novější rozhraní API verze 2, které funguje pro sestavy i sémantické modely a jednu nebo více položek. Pro řídicí panely a dlaždice použijte řídicí panely V1 GenerateTokenInGroup a dlaždice GenerateTokenInGroup.

Zabezpečení dat

Pokud zpracováváte data od více zákazníků, existují dva hlavní přístupy k zabezpečení dat: izolace založená na pracovních prostorech a izolace založená na zabezpečení na úrovni řádků. Podrobné porovnání mezi nimi najdete v profilech služebního principálu a na úrovni řádkového zabezpečení.

Doporučujeme používat izolaci založenou na pracovním prostoru s profily, ale pokud chcete použít přístup RLS, projděte si část RLS na konci tohoto článku.

Oprávnění tokenu a zabezpečení

V rozhraních API Generate token popisuje oddíl GenerateTokenRequest oprávnění tokenu.

Úroveň přístupu

  • Pokud chcete uživateli udělit oprávnění k prohlížení nebo úpravám, použijte parametr allowEdit.

  • Pokud chcete uživateli povolit vytváření nových sestav (SaveAs nebo CreateNew) v daném pracovním prostoru, přidejte ID pracovního prostoru do tokenu pro vložení.

Zabezpečení na úrovni řádků

U zabezpečení na úrovni řádků (RLS) se identita, kterou používáte, může lišit od identity podnikového uživatele nebo hlavního uživatele, kterého používáte pro generování tokenu. Pomocí různých identit můžete zobrazit vložené informace podle uživatele, na který cílíte. V aplikaci můžete například požádat uživatele, aby se přihlásili, a pak zobrazit sestavu, která obsahuje jenom prodejní údaje, pokud je přihlášený uživatel zaměstnancem prodeje.

Pokud používáte zabezpečení na úrovni řádků (RLS), můžete někdy vynechat identitu uživatele (parametr EffectiveIdentity). Pokud nepoužíváte parametr EffectiveIdentity , má token přístup k celé databázi. Tuto metodu lze použít k udělení přístupu uživatelům, jako jsou správci a manažeři, kteří mají oprávnění k zobrazení celého sémantického modelu. Tuto metodu ale nemůžete použít v každém scénáři. Následující tabulka uvádí různé typy zabezpečení na úrovni řádků a ukazuje, jakou metodu ověřování je možné použít bez zadání identity uživatele.

Tabulka také ukazuje úvahy a omezení platná pro jednotlivé typy RLS.

Typ RLS (zabezpečení na úrovni řádků) Můžu vygenerovat token pro vložení bez zadání platného ID uživatele? Úvahy a omezení
Cloud zabezpečení na úrovni řádku (Cloud RLS) ✔ Hlavní uživatel
✖ Služební principál
RDL (stránkované sestavy) ✖ Hlavní uživatel
✔ Aplikační objekt		 Hlavního uživatele nemůžete použít k vygenerování tokenu pro vložení pro RDL.
Živé místní připojení ke službě Analysis Services (AS) ✔ Hlavní uživatel
✖ Služební principál		 Uživatel, který generuje token pro vložení, potřebuje také jedno z následujících oprávnění:
  • Oprávnění správce brány
  • Oprávnění zosobnění zdroje dat (ReadOverrideEffectiveIdentity)
    		•
    Živé připojení pro Azure Analysis Services (AS) ✔ Hlavní uživatel
    ✖ Služební principál    		 Identitu uživatele, který generuje token pro vložení, nejde přepsat. Vlastní data se dají použít k implementaci dynamického RLS nebo zabezpečeného filtrování.

    Poznámka: Instanční objekt musí jako efektivní identitu (uživatelské jméno RLS) zadat ID objektu.
    Jednotné přihlašování (SSO) ✔ Hlavní uživatel
    ✖ Služební principál    		 Explicitní identitu (SSO) je možné poskytnout pomocí vlastnosti objektu blob identity v efektivním objektu identity.
    Jednotné přihlašování a cloudová zabezpečení na úrovni řádků (RLS) ✔ Hlavní uživatel
    ✖ Služební principál    		 Musíte zadat:
  • Explicitní identita (SSO) ve vlastnosti informačního blobu identity v efektivním identitním objektu
  • Platná identita (RLS) (uživatelské jméno)
    		•

    Poznámka:

    Principály služby musí vždy poskytovat:

    • Identita pro libovolnou položku sémantickým modelem zabezpečení na úrovni řádků
    • Efektivní identita RLS s definovanou kontextovou identitou (SSO) (pro sémantický model jednotného přihlašování)

    DirectQuery pro sémantické modely Power BI

    Vložení sestavy Power BI, která má sémantický model s připojením Direct Query k jinému sémantickému modelu Power BI:

    V tomto scénáři se musí všechny sémantické modely nacházet v pracovním prostoru Premium. Zkušební tokeny pro vkládání nelze použít k vložení tohoto typu sestavy.

    Prodloužení platnosti tokenů před vypršením jejich platnosti

    Tokeny mají časový limit. Proto po vložení položky Power BI máte omezenou dobu na interakci s ní. Pokud chcete uživatelům poskytnout nepřetržité prostředí, obnovte (nebo aktualizujte) token před vypršením jeho platnosti.

    Řídicí panely a dlaždice

    Token Generate funguje pro sestavy a sémantické modely. Pokud chcete vygenerovat token pro vložení pro řídicí panel nebo dlaždici, použijte rozhraní API verze 1, Dashboards GenerateTokenInGroup nebo Tiles GenerateTokenInGroup. Tato rozhraní API generují tokeny pouze pro jednu položku najednou. Token pro více položek nejde vygenerovat.

    Pro tato rozhraní API:

    • K určení úrovně přístupu uživatele použijte parametr accessLevel.

      • Zobrazení – udělte uživateli oprávnění k zobrazení.

      • Upravit – Udělte uživateli oprávnění k prohlížení a úpravám (platí jenom při generování tokenu pro vložení pro sestavu).

      • Vytvořit – Umožnit uživateli oprávnění k vytvoření nové zprávy (platí pouze při generování tokenu pro vložení pro vytvoření zprávy). Při vytváření sestavy musíte také zadat parametr datasetId.

    • Pomocí logické hodnoty allowSaveAs umožníte uživatelům uložit sestavu jako novou sestavu. Toto nastavení je ve výchozím nastavení nastavené na false a platí pouze při generování tokenu pro vložení pro sestavu.

    Úvahy a omezení

    • Z bezpečnostních důvodů je životnost tokenu pro vložení nastavená na zbývající dobu životnosti tokenu Microsoft Entra použitého GenerateToken k volání rozhraní API. Proto pokud použijete stejný token Microsoft Entra k vygenerování několika tokenů pro vložení, životnost vygenerovaných tokenů pro vložení se s každým voláním zkracuje.

    • Pokud je sémantický model a položka, které se mají vložit, nacházejí ve dvou různých pracovních prostorech, musí být instanční objekt nebo hlavní uživatel alespoň členem obou pracovních prostorů.

    • Vkládání položek pomocí služby Data Lake Storage (DLS) vyžaduje V2 rozhraní API pro generování tokenů.

    • Nejde vytvořit token pro vložení obsahu pro Můj pracovní prostor.

    • omezení zdroje dat SSO (App-owns-data): Při použití jednotného přihlašování s App-owns-data integrací (služební principál nebo primární uživatel) je jediný podporovaný zdroj dat DirectQuery Azure SQL Database. Jiné typy zdrojů dat DirectQuery v tomto scénáři nepodporují jednotné přihlašování.

    • Požadavek IdentityBlob: Při generování tokenu pro vložení pro sestavu se zdroji dat s povoleným jednotným přihlašováním musíte zadat datasourceIdentities záznam s platným identityBlob pro každý zdroj dat s povoleným jednotným přihlašováním. Vynechání jakýchkoli identityBlob způsobí selhání generování tokenů.

    Související obsah

    • Last updated on