Megosztás a következőn keresztül:

Beágyazási jogkivonat létrehozása

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: Az alkalmazás az adatok tulajdonosa, a felhasználóé az adat

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

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.

Feljegyzé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 .

Jogkivonat 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 jogkivonat a teljes adatbázishoz hozzáfér. 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
Cloud Row Level Security (Cloud RLS) ✔ Fő felhasználó
✖ Szolgáltatásnév
RDL (többoldalas jelentések) ✖ Fő felhasználó
✔ Szolgáltatásnév		 Az RDL-hez nem hozhat létre beágyazási jogkivonatot fő felhasználóval.
Analysis Services (AS) helyszíni élő kapcsolaton ✔ 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 (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)
    		•

    Feljegyzé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:

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

    A jogkivonatok időkorláttal járnak. 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 szeretne létrehozni egy irányítópulthoz vagy csempéhez, használja az 1-es verzióJú Irányítópultok GenerateTokenInGroup vagy Tiles GenerateTokenInGroup API-kat. Ezek az API-k egyszerre csak egy elemhez hoznak létre jogkivonatokat. Több elemhez nem hozhat létre jogkivonatot.

    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 jogkivonatot.

    Kapcsolódó tartalom