Beágyazási tokent létrehozni

A következőkre vonatkozik:✅ Power BI beágyazott elemzés ügyfelei számára (App-owns-data)

Token generálása egy REST API, amellyel token-t hozhat létre Power BI jelentések vagy szemantikai modellek beágyazásához webalkalmazásban vagy portálon. Hozhat létre tokent egyetlen elemhez, több jelentéshez vagy szemantikai modellhez. A token a kérés engedélyezésére szolgál a Power BI szolgáltatás ellen.

A Token létrehozása API egyetlen identitást (fő felhasználót vagy szolgáltatásfiókot) használ egy token létrehozásához egyéni felhasználó számára, a felhasználó hitelesítő adatai alapján az alkalmazásban (érvényes identitás).

A sikeres hitelesítés után a rendszer hozzáférést biztosít a vonatkozó adatokhoz.

Megjegyzés

A token létrehozása az újabb, 2-es verziójú API, amely a jelentésekhez és szemantikai modellekhez, valamint egy vagy több elemhez is használható. Irányítópultok és csempék esetén használja a V1 Irányítópultok GenerateTokenInGroup és Csempék GenerateTokenInGroup.

Az adatok védelme

Ha több ügyfél adatait kezeli, az adatok védelmének két fő módszere van: a munkaterületalapú elkülönítés és a sorszintű biztonságalapú elkülönítés. A szolgáltatásnév-profilokban és a sorszintű biztonságban részletes összehasonlítást találhat közöttük.

Javasoljuk, hogy munkaterület-alapú elkülönítést használjon profilokkal, de ha az RLS-megközelítést szeretné használni, tekintse át a cikk végén található RLS szakaszt .

Token engedélyei és biztonsága

A Token létrehozása API-kban a GenerateTokenRequest szakasz írja le a token jogosultságait.

Hozzáférési szint

  • Ha megtekintési vagy szerkesztési engedélyeket szeretne adni a felhasználónak, használja az engedélyezettEdit paramétert.

  • Ha azt szeretné, hogy a felhasználó új jelentéseket hozzon létre (SaveAs vagy CreateNew) a munkaterületen, adja hozzá a munkaterület azonosítóját a beágyazási jogkivonathoz.

Sorszintű biztonság

A Sorszintű biztonság (RLS) esetében a használt identitás eltérhet a jogkivonat létrehozásához használt szolgáltatásnév vagy főfelhasználó identitásától. Különböző identitások használatával beágyazott információkat jeleníthet meg a megcélzott felhasználónak megfelelően. Az alkalmazásban például megkérheti a felhasználókat, hogy jelentkezzenek be, majd megjeleníthetnek egy jelentést, amely csak akkor tartalmaz értékesítési adatokat, ha a bejelentkezett felhasználó értékesítési alkalmazott.

Ha RLS-t használ, néha kihagyhatja a felhasználó identitását (az EffectiveIdentity paramétert). Ha nem használja az EffectiveIdentity paramétert, a jogosultság hozzáfér a teljes adatbázishoz. Ezzel a módszerrel hozzáférést biztosíthat a teljes szemantikai modell megtekintéséhez engedéllyel rendelkező felhasználóknak, például rendszergazdáknak és vezetőknek. Ezt a módszert azonban nem használhatja minden forgatókönyvben. Az alábbi táblázat felsorolja a különböző RLS-típusokat, és megjeleníti, hogy melyik hitelesítési módszer használható a felhasználó identitásának megadása nélkül.

A táblázat az egyes RLS-típusokra vonatkozó szempontokat és korlátozásokat is megjeleníti.

RLS-típus Létrehozhatok beágyazási jogkivonatot a tényleges felhasználói azonosító megadása nélkül? Szempontok és korlátozások
Felhő sor szintű biztonság (Cloud RLS) ✔ Fő felhasználó
✖ Szolgáltatásnév
RDL (többoldalas jelentések) ✖ Fő felhasználó
✔ Szolgáltatásnév		 Mesterfelhasználóval nem hozhat létre beágyazási jogkivonatot az RDL-hez.
Analysis Services (AS) helyszíni élő kapcsolat ✔ Fő felhasználó
✖ Szolgáltatásnév		 A beágyazási jogkivonatot létrehozó felhasználónak az alábbi engedélyek egyikére is szüksége van:
  • Átjáró rendszergazdai engedélyei
  • Adatforrás megszemélyesítési engedélye (ReadOverrideEffectiveIdentity)
    		•
    Analysis Services (AS) Azure élő kapcsolat ✔ Fő felhasználó
    ✖ Szolgáltatásnév    		 A beágyazási jogkivonatot létrehozó felhasználó identitása nem bírálható felül. Az egyéni adatok felhasználhatók dinamikus RLS vagy biztonságos szűrés megvalósításához.

    Megjegyzés: A szolgáltatásnévnek meg kell adnia az objektumazonosítóját érvényes identitásként (RLS-felhasználónév).
    Egyszeri bejelentkezés ✔ Fő felhasználó
    ✖ Szolgáltatásnév    		 Az explicit (SSO) identitás egy hatékony identitásobjektum identitásblobtulajdonságával adható meg
    Egyszeri bejelentkezés és felhőbeli RLS ✔ Fő felhasználó
    ✖ Szolgáltatásnév    		 Meg kell adnia a következőket:
  • Explicit (SSO) identitás az identitásblob tulajdonságban egy hatékony identitásobjektumban
  • Érvényes (RLS) identitás (felhasználónév)
    		•

    Megjegyzés

    A szolgáltatásneveknek mindig meg kell adniuk a következőt:

    • RLS szemantikai modellel rendelkező elemek identitása
    • Egy hatékony RLS-identitás a környezetfüggő (SSO) identitással meghatározva (SSO szemantikai modell esetén)

    DirectQuery Power BI szemantikai modellekhez

    Olyan Power BI-jelentés beágyazása, amelynek szemantikai modellje közvetlen lekérdezési kapcsolattal rendelkezik egy másik Power BI szemantikai modellel:

    Ebben a forgatókönyvben minden szemantikai modellnek prémium szintű munkaterületen kell lennie. A próbabeágyazási jogkivonatok nem használhatók ilyen típusú jelentések beágyazására.

    Tokenek megújítása a lejárat előtt

    A tokenek lejárnak egy adott idő után. Ezért a Power BI-elemek beágyazása után korlátozott ideig használhatja azt. Ha folyamatos élményt szeretne nyújtani a felhasználóknak, a jogkivonatot a lejárat előtt újítsa meg (vagy frissítse).

    Irányítópultok és csempék

    A Generate token jelentésekhez és szemantikai modellekhez használható. Ha beágyazási jogkivonatot kell létrehozni egy irányítópulthoz vagy csempéhez, használja az 1-es verziójú Dashboards GenerateTokenInGroup vagy Tiles GenerateTokenInGroup API-kat. Ezek az API-k egyszerre csak egy elemhez hoznak létre tokenseket. Több elemhez nem hozhat létre token-t.

    Az alábbi API-k esetében:

    • A felhasználó hozzáférési szintjének meghatározásához használja az accessLevel paramétert.

      • Nézet – Megtekintési engedélyek megadása a felhasználó számára.

      • Szerkesztés – Adjon meg megtekintési és szerkesztési engedélyeket a felhasználónak (csak akkor, ha beágyazási jogkivonatot hoz létre egy jelentéshez).

      • Létrehozás – Adjon engedélyt a felhasználónak egy új jelentés létrehozásához (csak akkor, ha beágyazási jogkivonatot hoz létre egy jelentés létrehozásához). A jelentés létrehozásához meg kell adnia az datasetId paramétert is.

    • Az allowSaveAs logikai használatával a felhasználók új jelentésként menthetik a jelentést. Ez a beállítás alapértelmezés szerint hamis értékre van állítva, és csak akkor érvényes, ha beágyazási jogkivonatot hoz létre egy jelentéshez.

    Szempontok és korlátozások

    • Biztonsági okokból a beágyazási jogkivonat élettartama az API meghívásához GenerateToken használt Microsoft Entra-jogkivonat fennmaradó élettartamára van beállítva. Ezért ha ugyanazt a Microsoft Entra-jogkivonatot használja több beágyazási jogkivonat létrehozásához, a generált beágyazási jogkivonatok élettartama minden hívással rövidebb lesz.

    • Ha a beágyazandó szemantikai modell és elem két különböző munkaterületen található, a szolgáltatásnévnek vagy a főfelhasználónak legalább a két munkaterület tagjának kell lennie.

    • A Data Lake Storage (DLS) használatával történő elemek beágyazásához a Generate token APIV2 verziójára van szükség.

    • A Saját munkaterülethez nem hozhat létre beágyazási token.

    • Az SSO-adatforrás korlátozásai (App-owns-data): Ha az egyszeri bejelentkezést az App-owns-data beágyazással (szolgáltatási név vagy főfelhasználó) használja, az egyetlen támogatott DirectQuery-adatforrás az Azure SQL Database. Ebben a forgatókönyvben más DirectQuery-adatforrástípusok nem támogatják az egyszeri bejelentkezést.

    • IdentityBlob-követelmény: Amikor beágyazási jogkivonatot hoz létre egy jelentéshez SSO-kompatibilis adatforrásokkal, datasourceIdentities SSO-kompatibilis adatforráshoz érvényes identityBlob bejegyzést kell megadnia. Bármely identityBlob kihagyása a jogkivonat létrehozásának meghiúsulását okozza.

    Kapcsolódó tartalom

    • Last updated on