แชร์ผ่าน

สร้างโทเค็นแบบฝังตัว

  • บทความ

นําไปใช้กับ: ผู้ใช้ข้อมูลที่เป็นเจ้าของข้อมูล แอปเป็นเจ้าของข้อมูล

สร้างโทเค็น คือ REST API ที่ช่วยให้คุณสร้างโทเค็นสําหรับการฝังรายงาน Power BI หรือแบบจําลองความหมายในเว็บแอปหรือพอร์ทัล ซึ่งสามารถสร้างโทเค็นสําหรับรายการเดียวหรือหลายรายงานหรือแบบจําลองความหมายได้ โทเค็นถูกใช้เพื่ออนุญาตคําขอของคุณกับบริการของ Power BI

API สร้างโทเค็นใช้ข้อมูลประจําตัวเดียว (ผู้ใช้หลักหรือหลักบริการ) เพื่อสร้างโทเค็นสําหรับผู้ใช้แต่ละราย ขึ้นอยู่กับข้อมูลประจําตัวของผู้ใช้ในแอป (ข้อมูลประจําตัวที่มีประสิทธิภาพ)

หลังจากรับรองความถูกต้องสําเร็จแล้ว จะได้รับสิทธิ์เข้าถึงข้อมูลที่เกี่ยวข้อง

หมายเหตุ

สร้างโทเค็น คือ API เวอร์ชัน 2 ที่ใหม่กว่าที่ใช้งานได้สําหรับทั้งรายงานและแบบจําลองความหมาย และรายการเดียวหรือหลายรายการ ซึ่งเป็นที่ต้องการมากกว่า API เวอร์ชันดั้งเดิม 1 สําหรับแดชบอร์ดและไทล์ใช้แดชบอร์ด V1 GenerateTokenInGroup และไทล์ GenerateTokenInGroup

การรักษาความปลอดภัยข้อมูลของคุณ

หากคุณกําลังจัดการข้อมูลจากลูกค้าหลายราย มีสองวิธีหลักในการรักษาความปลอดภัยข้อมูลของคุณ: การแยกตามพื้นที่ทํางานและการแยกตามการรักษาความปลอดภัยระดับแถว คุณสามารถค้นหาการเปรียบเทียบโดยละเอียดระหว่างข้อมูลเหล่านั้นใน โปรไฟล์บริการหลักและความปลอดภัยระดับแถวได้

เราขอแนะนําให้ใช้การแยกตามพื้นที่ทํางานกับโปรไฟล์ แต่ถ้าคุณต้องการใช้วิธีการ RLS ให้ตรวจสอบ ส่วน RLS ที่ส่วนท้ายของบทความนี้

การอนุญาตโทเค็นและความปลอดภัย

ใน API สร้างโทเค็น ส่วน GenerateTokenRequest จะอธิบายการอนุญาตของโทเค็น

ระดับการเข้าถึง

  • ใช้พารามิเตอร์ allowEdit เพื่อให้ผู้ใช้ดูหรือแก้ไขสิทธิ์

  • เพิ่ม ID พื้นที่ทํางานไปยังโทเค็นแบบฝังเพื่ออนุญาตให้ผู้ใช้สามารถสร้างรายงานใหม่ ( SaveAs หรือ CreateNew) ในพื้นที่ทํางานนั้นได้

การรักษาความปลอดภัยระดับแถว

ด้วยการ รักษาความปลอดภัยระดับแถว (RLS) ข้อมูลประจําตัวที่คุณใช้อาจแตกต่างจากข้อมูลประจําตัวของบริการหลักหรือผู้ใช้หลักที่คุณกําลังใช้เพื่อสร้างโทเค็น คุณสามารถแสดงข้อมูลแบบฝังตัวตามผู้ใช้ที่คุณกําลังกําหนดเป้าหมายได้โดยใช้ข้อมูลประจําตัวที่แตกต่างกัน ตัวอย่างเช่น ในแอปพลิเคชันของคุณ คุณสามารถขอให้ผู้ใช้ลงชื่อเข้าใช้ จากนั้นแสดงรายงานที่มีเฉพาะข้อมูลการขายถ้าผู้ใช้ที่ลงชื่อเข้าใช้เป็นพนักงานขาย

หากคุณกําลังใช้ RLS บางครั้งคุณสามารถออกจากข้อมูลประจําตัวของผู้ใช้ ( พารามิเตอร์ EffectiveIdentity ) ได้ เมื่อคุณไม่ได้ใช้ พารามิเตอร์ EffectiveIdentity โทเค็นจะสามารถเข้าถึงฐานข้อมูลทั้งหมดได้ วิธีนี้สามารถใช้เพื่อให้สิทธิ์การเข้าถึงแก่ผู้ใช้ เช่น ผู้ดูแลระบบและผู้จัดการ ที่มีสิทธิ์ในการดูแบบจําลองความหมายทั้งหมด อย่างไรก็ตาม คุณไม่สามารถใช้วิธีนี้ได้ในทุกสถานการณ์ ตารางด้านล่างแสดงรายการประเภท RLS ต่าง ๆ และแสดงวิธีการรับรองความถูกต้องที่สามารถใช้ได้โดยไม่ต้องระบุข้อมูลประจําตัวของผู้ใช้

ตารางยังแสดงข้อควรพิจารณาและข้อจํากัดที่เกี่ยวข้องกับ RLS แต่ละประเภท

ประเภท RLS ฉันสามารถสร้างโทเค็นแบบฝังโดยไม่ระบุ ID ผู้ใช้ที่ใช้ได้หรือไม่ ข้อควรพิจารณาและข้อจำกัด
การรักษาความปลอดภัยระดับแถวระบบคลาวด์ (Cloud RLS) ✔ ผู้ใช้หลัก
✖ บริการหลัก
RDL (รายงานที่มีการแบ่งหน้า) ✖ ผู้ใช้หลัก
✔ บริการหลัก		 คุณไม่สามารถใช้ผู้ใช้หลักเพื่อสร้างโทเค็นฝังตัวสําหรับ RDL
Analysis Services (AS) การเชื่อมต่อแบบสดภายในองค์กร ✔ ผู้ใช้หลัก
✖ บริการหลัก		 ผู้ใช้ที่สร้างโทเค็นแบบฝังยังต้องการการอนุญาตอย่างใดอย่างหนึ่งต่อไปนี้:
  • สิทธิ์ผู้ดูแลระบบเกตเวย์
  • แหล่งข้อมูลเลียนแบบสิทธิ์ (ReadOverrideEffectiveIdentity)
    		•
    Analysis Services (AS) การเชื่อมต่อ Azure live ✔ ผู้ใช้หลัก
    ✖ บริการหลัก    		 ไม่สามารถแทนที่ข้อมูลประจําตัวของผู้ใช้ที่สร้างโทเค็นแบบฝังได้ ข้อมูลแบบกําหนดเองสามารถใช้เพื่อใช้ RLS แบบไดนามิกหรือการกรองที่ปลอดภัย

    หมายเหตุ: บริการหลักต้องระบุ ID ออบเจ็กต์เป็นข้อมูลประจําตัวที่มีประสิทธิภาพ (ชื่อผู้ใช้ RLS)
    ลงชื่อเข้าระบบครั้งเดียว (SSO) ✔ ผู้ใช้หลัก
    ✖ บริการหลัก    		 ข้อมูลประจําตัวที่ชัดเจน (SSO) สามารถระบุได้โดยใช้คุณสมบัติ blob ของข้อมูลประจําตัวในอ็อบเจ็กต์เอกลักษณ์ที่มีประสิทธิภาพ
    SSO และ Cloud RLS ✔ ผู้ใช้หลัก
    ✖ บริการหลัก    		 คุณต้องระบุรายการต่อไปนี้:
  • ข้อมูลประจําตัวที่ชัดเจน (SSO) ในคุณสมบัติ blob ของข้อมูลประจําตัวในอ็อบเจ็กต์เอกลักษณ์ที่มีประสิทธิภาพ
  • ข้อมูลประจําตัว (RLS) ที่มีประสิทธิภาพ (ชื่อผู้ใช้)
    		•

    หมายเหตุ

    บริการหลักต้องให้ข้อมูลต่อไปนี้เสมอ:

    • ข้อมูลประจําตัวสําหรับรายการใด ๆ ที่มีแบบจําลองความหมาย RLS
    • สําหรับแบบจําลองความหมาย SSO ข้อมูลประจําตัว RLS ที่มีประสิทธิภาพพร้อมข้อมูลประจําตัวตามบริบท (SSO) ที่กําหนดไว้

    DirectQuery สําหรับแบบจําลองความหมายของ Power BI

    หากต้องการฝังรายงาน Power BI ที่มีแบบจําลองความหมายด้วยการเชื่อมต่อ Direct Query ไปยังแบบจําลองความหมายอื่นของ Power BI ให้ทําดังต่อไปนี้:

    • ในพอร์ทัล Power BI ให้ ตั้งค่าตําแหน่งข้อมูล XMLA เป็น อ่านเท่านั้น หรือ อ่านเขียน ตามที่อธิบายไว้ใน เปิดใช้งานการอ่าน-เขียนสําหรับความจุแบบพรีเมียม คุณจําเป็นต้องทําสิ่งนี้เพียงครั้งเดียวต่อความจุเท่านั้น
    • สร้าง โทเค็นแบบฝังตัวแบบหลายทรัพยากร
      • ระบุรหัสชุดข้อมูลทั้งหมดในคําขอ
      • XmlaPermissionsตั้งค่า เป็น อ่านอย่างเดียว สําหรับแต่ละแบบจําลองความหมายในคําขอ
      • สําหรับแหล่งข้อมูลที่เปิดใช้งานการลงชื่อเข้าระบบครั้งเดียว (SSO) แต่ละรายการ ให้ระบุ blob ของข้อมูลประจําตัวสําหรับแหล่งข้อมูลในDatasourceIdentity

    ต่ออายุโทเค็นก่อนที่จะหมดอายุ

    โทเค็นมาพร้อมกับการจํากัดเวลา ซึ่งหมายความว่าหลังจากฝังรายการ Power BI คุณมีระยะเวลาที่จํากัดในการโต้ตอบกับรายการดังกล่าว หากต้องการให้ผู้ใช้ของคุณมีประสบการณ์ต่อเนื่อง ต่ออายุ (หรือรีเฟรช) โทเค็นก่อนที่โทเค็นจะหมดอายุ

    แดชบอร์ดและไทล์

    โทเค็นสร้างใช้สําหรับรายงานและแบบจําลองความหมาย หากต้องการสร้างโทเค็นฝังตัวสําหรับแดชบอร์ดหรือไทล์ ให้ใช้ API ของแดชบอร์ด GenerateTokenInGroup เวอร์ชัน 1 หรือ Tiles GenerateTokenInGroup API เหล่านี้สร้างโทเค็นสําหรับรายการเดียวเท่านั้นในแต่ละครั้ง คุณไม่สามารถสร้างโทเค็นสําหรับหลายรายการได้

    สําหรับ API เหล่านี้:

    • ใช้พารามิเตอร์ accessLevel เพื่อกําหนดระดับการเข้าถึงของผู้ใช้

      • มุมมอง - ให้การอนุญาตแก่ผู้ใช้ในการดู

      • แก้ไข - ให้การอนุญาตแก่ผู้ใช้ในการดูและแก้ไข (ใช้เฉพาะเมื่อสร้างโทเค็นแบบฝังสําหรับรายงาน)

      • สร้าง - ให้การอนุญาตผู้ใช้ในการสร้างรายงานใหม่ (ใช้เฉพาะเมื่อสร้างโทเค็นแบบฝังสําหรับการสร้างรายงาน) สําหรับการสร้างรายงาน คุณต้องใส่พารามิเตอร์ datasetId ด้วย

    • ใช้บูลีน allowSaveAs เพื่อให้ผู้ใช้บันทึกรายงานเป็นรายงานใหม่ การตั้งค่านี้ถูกตั้งค่า เป็น false ตามค่าเริ่มต้น และใช้เฉพาะเมื่อสร้างโทเค็นแบบฝังสําหรับรายงานเท่านั้น

    ข้อควรพิจารณาและข้อจำกัด

    • สําหรับเหตุผลด้านความปลอดภัย อายุการใช้งานของโทเค็นแบบฝังจะถูกตั้งค่าเป็นอายุการใช้งานที่เหลือของโทเค็น Microsoft Entra ที่ใช้ในการเรียกใช้ GenerateToken API ดังนั้น ถ้าคุณใช้โทเค็น Microsoft Entra เดียวกันเพื่อสร้างโทเค็นแบบฝังหลายโทเค็น อายุการใช้งานของโทเค็นแบบฝังตัวที่สร้างขึ้นจะสั้นลงในแต่ละการเรียกใช้

    • ถ้าแบบจําลองความหมายและรายการที่จะฝังอยู่ในพื้นที่ทํางานที่แตกต่างกันสองแห่ง โครงร่างสําคัญของบริการหรือผู้ใช้หลักต้องเป็นสมาชิกของพื้นที่ทํางานทั้งสองเป็นอย่างน้อย

    • คุณไม่สามารถสร้างโทเค็นฝังตัวสําหรับ พื้นที่ทํางานของฉัน

    เนื้อหาที่เกี่ยวข้อง