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 létrehozási jogkivonat API egyetlen identitást (fő felhasználót vagy szolgáltatásnevet) használ egy jogkivonat létrehozásához egy adott felhasználó számára, attól függően, hogy a felhasználó milyen hitelesítő adatokat használ 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ó. Előnyben részesítik az örökölt 1-es verziójú API-k. Irányítópultok és csempék esetén használja a V1-irányítópultok GenerateTokenInGroup és a Tiles GenerateTokenInGroup parancsot.

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 jogkivonat létrehozása API-kban a GenerateTokenRequest szakasz ismerteti a jogkivonat-engedélyeket.

Hozzáférési szint

  • Az allowEdit paraméter használatával megtekintési vagy szerkesztési engedélyeket adhat a felhasználónak.

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

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    		 A következőket kell megadnia:
  • 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 a következő információkat kell megadniuk:

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

    DirectQuery Power BI szemantikai modellekhez

    Ha olyan Power BI-jelentést szeretne beágyazni, amelynek szemantikai modellje közvetlen lekérdezési kapcsolattal rendelkezik egy másik Power BI szemantikai modellel, tegye a következőket:

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

    A jogkivonatok időkorláttal járnak. Ez azt jelenti, hogy egy Power BI-elem 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 létrehozott beágyazási jogkivonatok élettartama minden hívásnál 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 Saját munkaterülethez nem hozhat létre beágyazási jogkivonatot.

    Kapcsolódó tartalom