แทนที่โปรไฟล์บริการหลักด้วยบริการหลัก

หากโซลูชันของคุณใช้โปรไฟล์โครงร่างสําคัญของบริการ (SPP) และข้อมูลประจําตัวการกํากับดูแล API หรือข้อจํากัดในการดําเนินงานจํากัดข้อกําหนดของคุณ คู่มือนี้จะช่วยคุณประเมินและใช้การแทนที่ตาม Microsoft Entra บริการหลักโดยเฉพาะ หากโซลูชันตามโปรไฟล์ที่มีอยู่ของคุณตรงกับความต้องการของคุณ คุณสามารถใช้งานต่อได้

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

หมายเหตุ

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

เหตุใดจึงต้องโยกย้ายจากโปรไฟล์

พิจารณาแทนที่โปรไฟล์เมื่อข้อจํากัดต่อไปนี้จํากัดโซลูชันของคุณ:

• โปรไฟล์ไม่สอดคล้องกับแนวทางปฏิบัติที่ดีที่สุด Microsoft Entra ID สําหรับข้อมูลประจําตัวปริมาณงานที่ควบคุมได้ โปรไฟล์ไม่มีการแสดงใน Microsoft Entra ID ซึ่งไม่มีไฟล์บันทึกการลงชื่อเข้าใช้แบบอิสระ ไม่สามารถดําเนินการตามนโยบายการเข้าถึงแบบมีเงื่อนไขของตนเองได้ และไม่สามารถควบคุมได้โดยเครื่องมือที่ใช้สําหรับส่วนเหลือของอสังหาริมทรัพย์สําหรับข้อมูลประจําตัว

ตัวอย่างเช่น คุณไม่สามารถกําหนดค่าโปรไฟล์เป็นข้อมูลประจําตัวของ การเชื่อมต่อ Direct Lake จากแบบจําลองความหมายไปยังเลคเฮ้าส์หรือคลังสินค้า หรือคุณสามารถให้สิทธิ์การเข้าถึงเป็นข้อมูลประจําตัว Microsoft Entra อิสระไปยังบริการปลายทางอื่น ๆ ที่แอปพลิเคชันหรือปริมาณงานจําเป็นต้องเข้าถึง บริการหลักเฉพาะสามารถรับสิทธิ์เหล่านั้นที่บริการสนับสนุนได้

คุณไม่สามารถใช้โปรไฟล์กับ Fabric REST API ได้ โปรไฟล์ได้รับการสนับสนุนโดย REST API โปรไฟล์รู้จักเท่านั้น .NET SDK และอินเทอร์เฟซ XMLA/TOM ที่รองรับ Fabric REST API ไม่สนับสนุนโปรไฟล์ และการสนับสนุนไม่ได้วางแผนไว้ ใช้ข้อมูลประจําตัวที่ได้รับการสนับสนุนสําหรับการเรียกใช้ API เหล่านั้นแทนโปรไฟล์ การสร้างบริการหลักเฉพาะจะจัดการกับข้อกําหนดข้อมูลประจําตัว แต่ API และการดําเนินการแต่ละรายการต้องสนับสนุนข้อมูลประจําตัวนั้นและให้สิทธิ์ที่จําเป็น

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

โปรไฟล์แก้ไขปัญหามาตราส่วน ไม่ใช่ปัญหาข้อมูลประจําตัวอิสระ หนึ่งบริการหลักสามารถสร้างโปรไฟล์ได้สูงสุด 100,000 โปรไฟล์ และแต่ละโปรไฟล์สามารถเข้าถึงหรือสร้างพื้นที่ทํางานได้สูงสุด 1,000 พื้นที่ทํางาน บริการหลักสามารถเป็นของพื้นที่ทํางานส่วนใหญ่ในแบบจําลองนี้ได้มากที่สุด 1,000 รายการ ข้อมูลประจําตัวลูกค้าเฉพาะแทนที่จะใช้ Microsoft Entra ออบเจ็กต์ไดเรกทอรี ตรวจสอบขีดจํากัดที่เกี่ยวข้องกับจํานวนลูกค้าของคุณก่อนที่จะยืนยันการโยกย้าย

หมายเหตุ

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

ข้อจํากัดโปรไฟล์อื่น ๆ ที่ต้องพิจารณา

ข้อจำกัด	ความหมายโดยนัยของการโยกย้าย
ไม่มีการตรวจสอบอิสระหรือข้อมูลประจําตัวนโยบาย	โปรไฟล์ไม่มี Microsoft Entra อิสระในการลงชื่อเข้าใช้ระเบียนหรือเป้าหมายการเข้าถึงตามเงื่อนไขของข้อมูลประจําตัวของปริมาณงาน บริการหลักเฉพาะมอบความสามารถเหล่านั้น โดยขึ้นอยู่กับสิทธิ์ของนโยบายและการให้สิทธิ์การใช้งาน
การเรียงต่อกันโปรไฟล์แบบถาวรต่อผู้ปกครอง	ไม่สามารถโอนโปรไฟล์ไปยังบริการหลักอื่นได้ การแทนที่รายการหลักจําเป็นต้องมีโปรไฟล์ใหม่ การอนุมัติพื้นที่ทํางานใหม่ และการแมปลูกค้าที่อัปเดตแล้ว
ไม่มีพอร์ทัลการดูแลข้อมูลประจําตัว	โปรไฟล์เป็น API เท่านั้น และไม่แสดงในเครื่องมือการดูแลระบบ Microsoft Entra แอปพลิเคชันเฉพาะและบริการหลักมีพื้นผิวการมองเห็นไดเรกทอรีและการจัดการ

รูปแบบข้อมูลประจําตัวที่มีการจัดการและข้อมูลประจําตัวภายนอก

ใช้รูปแบบนี้สําหรับโซลูชันเฉพาะใหม่หรือเมื่อคุณเลือกที่จะแทนที่โปรไฟล์ หากรันไทม์ของคุณตรงตามข้อกําหนดการโฮสต์ข้อมูลประจําตัวที่มีการจัดการ

รูปแบบ

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

วิธีการนี้เป็นเส้นทางการโยกย้ายที่แนะนําที่ Azure โฮสติ้งและข้อกําหนดความเชื่อถือที่เหมาะสมกับโซลูชัน ซึ่งจะลบข้อมูลประจําตัวของแอปพลิเคชันของลูกค้าที่จัดเก็บไว้และกระบวนการหมุนโดยไม่เปลี่ยนแปลงตําแหน่งที่มีการบังคับใช้พื้นที่ทํางานและการรับรองความถูกต้องทรัพยากร

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

รูปที่ 1 แอปพลิเคชันหนึ่งที่มีการจัดการข้อมูลประจําตัวจะรับรองความถูกต้องในฐานะการบริการลูกค้าเฉพาะหลัก

วิธีการทำงาน

1. ข้อมูลประจําตัวที่มีการจัดการแอปพลิเคชัน กําหนดข้อมูลประจําตัวที่จัดการโดยผู้ใช้เป็นแอปพลิเคชัน ISV ที่ทํางานบน Azure คํานวณที่สนับสนุน เช่น App Service, Container Apps, ปริมาณงาน AKS ที่กําหนดค่าอย่างเหมาะสม หรือเครื่องเสมือน ใช้ข้อมูลประจําตัวที่มีการจัดการหนึ่งรายการสําหรับแอปพลิเคชัน ไม่ใช่หนึ่งรายการต่อลูกค้า ไม่มีพื้นที่ทํางานของลูกค้าหรือสิทธิ์บริการเป้าหมายของตนเอง บทบาทที่นี่เป็นเพียงการให้การยืนยันเท่านั้น

2. ต่อลูกค้า ผู้ใช้ หรือกลุ่มบริการหลัก สําหรับลูกค้าที่มีอยู่หรือขอบเขตการอนุญาตสร้าง Microsoft Entra การลงทะเบียนแอปพลิเคชันและบริการหลักในผู้เช่าไดเรกทอรีของ ISV ลูกค้าเชิงตรรกะไม่จําเป็นต้องหมายถึงผู้เช่า Microsoft Entra แยกต่างหาก และไม่จําเป็นต้องมีข้อมูลประจําตัวต่อผู้ใช้ปลายทาง เว้นแต่ว่าจะมีการเรียกใช้การออกแบบการเข้าถึงที่มีอยู่

3. ข้อมูลประจําตัวภายนอก กําหนดค่าข้อมูลประจําตัวภายนอกในการลงทะเบียนแอปพลิเคชันของลูกค้าแต่ละรายเพื่อเชื่อถือข้อมูลประจําตัวที่มีการจัดการของแอปพลิเคชัน จากนั้นรันไทม์สามารถใช้โทเค็นข้อมูลประจําตัวที่มีการจัดการเป็นการยืนยันเพื่อรับโทเค็นการเข้าถึงสําหรับแอปพลิเคชันลูกค้านั้นโดยไม่ต้องมีข้อมูลลับของไคลเอ็นต์หรือใบรับรอง

4. การแลกเปลี่ยนโทเค็นรันไทม์ เมื่อผู้ใช้ A หรืองานเฉพาะของลูกค้าเรียกใช้แอปพลิเคชัน ให้แก้ไขลูกค้า A ผ่านการแมปฝั่งเซิร์ฟเวอร์ที่เชื่อถือได้ รับโทเค็นข้อมูลประจําตัวที่มีการจัดการกับผู้ชม api://AzureADTokenExchange; แลกเปลี่ยนสําหรับโทเค็นการเข้าถึงเป็น SP-A จากนั้นเรียกใช้ API เป้าหมายโดยใช้โทเค็นของ SP-A เพื่อจัดการพื้นที่ทํางาน ดําเนินการด้านทรัพยากร หรือร้องขอโทเค็นเฉพาะแอปพลิเคชันตามความจําเป็น

   สําหรับการแลกเปลี่ยนในขั้นตอนก่อนหน้า .NET Azure Identity ClientAssertionCredential ยอมรับโทเค็นข้อมูลประจําตัวที่มีการจัดการเป็นการยืนยันไคลเอ็นต์ นี่คือชนิดข้อมูลประจําตัวของ Azure ไม่ใช่คลาส MSAL โทเค็นการเข้าถึงต้องกําหนดเป้าหมายผู้ชมของ API ทรัพยากร ไม่ใช่ผู้ชมที่มีโทเค็นการแลกเปลี่ยน

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

เหตุใดจึงแนะนําให้ใช้เส้นทางนี้

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

• งานหมุนน้อยลง Azure จัดการข้อมูลประจําตัวที่มีการจัดการและปัญหาโทเค็น short-lived คุณไม่จําเป็นต้องมีข้อมูลลับหรือกระบวนการต่ออายุใบรับรองแยกต่างหากสําหรับแอปพลิเคชันของลูกค้าทั้งหมดที่ใช้ความน่าเชื่อถือนี้

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

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

ทางเลือก: การรับรองความถูกต้องของบริการหลักโดยตรง

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

การรับรองความถูกต้องโดยตรงยังคงรักษาการมองเห็นไดเรกทอรี ไฟล์บันทึกการลงชื่อเข้าใช้ต่อหลัก และการเข้าถึง API ที่สนับสนุน ไม่จําเป็นต้องมีการโฮสต์ข้อมูลประจําตัวที่มีการจัดการหรือการจัดการความน่าเชื่อถือ แต่จะไม่กําจัดข้อมูลประจําตัวของลูกค้าที่จัดเก็บไว้

แนวคิดหลัก

แยกความแตกต่างข้อมูลประจําตัวที่สร้างความน่าเชื่อถือจากโทเค็นที่ใช้ในขณะทํางาน

ข้อมูลประจําตัวของภายนอก

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

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

หมายเหตุ

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

เขตข้อมูลที่เชื่อถือได้	ค่าในระบบคลาวด์ส่วนกลาง
ผู้ออก	https://login.microsoftonline.com/{directory-tenant-id}/v2.0
หัวเรื่อง	ID โครงร่างสําคัญ (ออบเจ็กต์) ของข้อมูลประจําตัวที่จัดการโดยผู้ใช้ อย่าใช้ ID ไคลเอ็นต์
ผู้ชม	api://AzureADTokenExchange

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

ข้อมูลประจําตัวที่มีการจัดการและการลงทะเบียนแอปพลิเคชันที่เชื่อถือได้ต้องอยู่ในผู้เช่า Microsoft Entra เดียวกัน ผู้ชมทรัพยากรเป็นตัวเลือกที่แยกต่างหากจากผู้ชมการยืนยัน สําหรับ Azure Identity ขอบเขตการแลกเปลี่ยนโทเค็นคลาวด์ส่วนกลางคือ api://AzureADTokenExchange/.defaultโดยปกติขอบเขต API เป้าหมายคือตัวระบุทรัพยากรที่ตามด้วย/.default

โฟลว์การแลกเปลี่ยนโทเค็น: ข้อมูลประจําตัวไคลเอ็นต์ที่มีการยืนยันภายนอก

โฟลว์นี้เกี่ยวข้องกับผู้เข้าร่วมสามรายและหกขั้นตอน SP-A คือแอปพลิเคชันของลูกค้า แอปพลิเคชันและบริการหลัก โทเค็นการยืนยันข้อมูลประจําตัวที่มีการจัดการและโทเค็นการเข้าถึงทรัพยากร SP-A ตอบสนองวัตถุประสงค์ที่แตกต่างกัน

รูปที่ 2 การแลกเปลี่ยนโทเค็นข้อมูลประจําตัวของไคลเอ็นต์ที่ได้รับการสนับสนุนโดยการยืนยันข้อมูลประจําตัวที่มีการจัดการ

1. ร้องขอโทเค็นข้อมูลประจําตัวที่มีการจัดการ แอปบน Azure ร้องขอโทเค็นข้อมูลประจําตัวที่มีการจัดการด้วยผู้ชมapi://AzureADTokenExchange

2. ส่งกลับโทเค็นการยืนยัน Microsoft Entra ID จะออกโทเค็นข้อมูลประจําตัวที่มีการจัดการ ซึ่งแอปได้รับผ่าน Azure กลไกข้อมูลประจําตัวที่ได้รับการจัดการของสภาพแวดล้อม

3. ส่งคําขอโทเค็นลูกค้า ส่งคําขอไปยังจุดสิ้นสุดของผู้/oauth2/v2.0/tokenเช่าไดเรกทอรีด้วย grant_type=client_credentials, client_id=<SP-A-client-id>client_assertion=<MI-token>, และscope=<target-resource>/.default นอกจากนี้ คําขอ OAuth ที่ client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearerสมบูรณ์ยังให้; ไลบรารีข้อมูลประจําตัวจะจัดการกับพารามิเตอร์นี้

4. ตรวจสอบความถูกต้องของการยืนยัน Microsoft Entra ID ตรวจสอบโทเค็นข้อมูลประจําตัวที่มีการจัดการกับข้อมูลประจําตัวภายนอกบนการลงทะเบียนแอปพลิเคชันของ SP-A

5. ส่งกลับโทเค็นการเข้าถึงลูกค้า Microsoft Entra ID ส่งกลับโทเค็นการเข้าถึงสําหรับ SP-A ที่มีทรัพยากรเป้าหมายเป็นผู้ชม

6. เรียกใช้ REST API เป้าหมาย แอปส่งโทเค็นการเข้าถึงของ SP-A ไปยัง API เป้าหมาย จะไม่ใช้โทเค็นการยืนยันเป็นโทเค็นผู้แบเรอร์ทรัพยากร และไม่เลือกโปรไฟล์

การเปรียบเทียบสถาปัตยกรรม

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

แอสเพ็กต์	โปรไฟล์บริการหลัก	บริการหลักเฉพาะ
ข้อมูลประจําตัวต่อลูกค้า	โปรไฟล์ตรรกะ ไม่ใช่วัตถุ Microsoft Entra	การลงทะเบียนแอปพลิเคชันและบริการหลักที่แสดงถึงขอบเขตการรับรองความถูกต้องของลูกค้า
ขอบเขตที่บังคับใช้	สิทธิ์ของพื้นที่ทํางานและทรัพยากร	สิทธิ์ของพื้นที่ทํางานและทรัพยากร
การเข้าถึงข้อมูลประจําตัวราก	บริการหลักสามารถทําหน้าที่เป็นโปรไฟล์ใดก็ได้	รันไทม์สามารถเข้าถึงข้อมูลประจําตัวทั้งหมดที่มีข้อมูลประจําตัวหรือการยืนยันที่เชื่อถือได้ MI สามารถรับรองความถูกต้องเป็นแอปใด ๆ ที่เชื่อถือได้
การหมุนเวียนข้อมูลลับ	จําเป็นเมื่อพาเรนต์ใช้ข้อมูลลับหรือใบรับรอง	ไม่จําเป็นต้องมีข้อมูลประจําตัวที่มีการจัดการ จําเป็นสําหรับใบรับรองที่จัดเก็บหรือความลับของไคลเอ็นต์ในเส้นทางโดยตรง
มาตราส่วนเพดาน	โปรไฟล์สูงสุด 100,000 โปรไฟล์ต่อ SP หลัก แต่ละโปรไฟล์ได้สูงสุด 1,000 พื้นที่ทํางาน การเป็นสมาชิกของ SP หลักจะถูกจํากัดไว้ที่ 1,000 พื้นที่ทํางาน	การลงทะเบียนแอปพลิเคชันและบริการหลักต่อลูกค้า จะขึ้นอยู่กับโควต้าอ็อบเจ็กต์ไดเรกทอรีและขีดจํากัดทรัพยากรของแต่ละบริการเป้าหมาย
บันทึกการตรวจสอบบัญชี	ID โปรไฟล์อาจปรากฏในบันทึกทรัพยากร แต่โปรไฟล์ไม่มี Microsoft Entra ระเบียนการลงชื่อเข้าใช้แบบอิสระ	Microsoft Entra ระเบียนการลงชื่อเข้าใช้ต่อบริการหลัก สัมพันธ์กับบันทึกแอปพลิเคชันและทรัพยากรการตรวจสอบ
การเข้าถึงแบบมีเงื่อนไข	ไม่มีนโยบายข้อมูลประจําตัวของปริมาณงานสําหรับแต่ละโปรไฟล์	พร้อมใช้งานสําหรับบริการหลักที่มีสิทธิ์ด้วย Microsoft Entra Workload ID Premium นโยบายต้องกําหนดเป้าหมายแต่ละองค์ประกอบหลักโดยตรง
การมองเห็นพอร์ทัล	ไม่แสดงใน Microsoft Entra ID	การลงทะเบียนแอปพลิเคชันใน App registrations บริการหลักในแอปพลิเคชันขององค์กร
Fabric REST API support	ไม่ได้รับการสนับสนุน ไม่ได้วางแผนการสนับสนุน	ได้รับการสนับสนุนโดยที่ API และการดําเนินการเฉพาะยอมรับโครงร่างสําคัญของบริการ ด้วยสิทธิ์ที่จําเป็น
การถ่ายโอนข้อมูลประจําตัวและการเรียงต่อกันของพาเรนต์	ไม่สามารถโอนย้ายโปรไฟล์ระหว่างบริการหลักได้	ความน่าเชื่อถือของภายนอกสามารถกําหนดค่าใหม่ได้ คุณสามารถแทนที่ข้อมูลประจําตัวโดยตรงได้โดยไม่ต้องสร้างนามธรรมของโปรไฟล์ใหม่

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

เส้นทางการย้ายข้อมูล

เส้นทางต่อไปนี้จะแทนที่โปรไฟล์ด้วยโครงร่างสําคัญของการบริการลูกค้าเฉพาะ ทําให้การย้ายข้อมูลและการตัดสินใจย้อนกลับแยกกันสําหรับลูกค้าแต่ละราย

จากโปรไฟล์ไปจนถึงข้อมูลประจําตัวที่มีการจัดการและข้อมูลประจําตัวภายนอก

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

ระยะที่ 0: สร้างข้อมูลประจําตัวที่จัดการโดยแอปพลิเคชัน

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

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

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

ระยะที่ 1: สินค้าคงคลัง

ทํารายการโปรไฟล์ที่มีอยู่ทั้งหมดผ่าน API การจัดการโปรไฟล์:

GET {profile-api-base}/v1.0/myorg/profiles

สําหรับแต่ละโปรไฟล์ บันทึก:

• รหัสโปรไฟล์และชื่อที่แสดง โครงร่างสําคัญของบริการหลัก และการแมปลูกค้า

• พื้นที่ทํางานที่เกี่ยวข้องและการกําหนดบทบาท

• แบบจําลองความหมายที่เกี่ยวข้องหรือชุดข้อมูล รายงาน และทรัพยากรอื่นๆ

• การเชื่อมต่อ ข้อมูลประจําตัวของแหล่งข้อมูล การขึ้นต่อกันของความเป็นเจ้าของ งานพื้นหลัง และการดําเนินการ API ที่ขึ้นอยู่กับโปรไฟล์

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

บันทึกจํานวนลูกค้าทั้งหมดและเปรียบเทียบแอปพลิเคชันที่จําเป็นและออบเจ็กต์บริการหลักกับ Microsoft Entra โควตาออบเจ็กต์ไดเรกทอรีของคุณก่อนดําเนินการต่อ ตรวจสอบขีดจํากัดการเป็นสมาชิกพื้นที่ทํางาน 1,000 รายการและขีดจํากัดเฉพาะทรัพยากรด้วยเช่นกัน ถ้าจํานวนประชากรเกินโควตาของไดเรกทอรีเดียว ให้วางแผนการเพิ่มโควตาที่รองรับหรือจัดการการออกแบบหลายไดเรกทอรีโดยตั้งใจ ไม่สามารถแก้ไขได้โดยอัตโนมัติตามรูปแบบนี้

หมายเหตุ

สวรรคของจุดสิ้นสุด:{profile-api-base} แสดงถึง URL พื้นฐาน REST API ชนิดทราบโปรไฟล์ที่มีอยู่ที่โซลูชันของคุณใช้อยู่แล้ว เก็บ URL นั้นไว้ในการกําหนดค่าการปรับใช้ของคุณ ตัวอย่างเหล่านี้รักษาเส้นทางการดําเนินการ แทนที่ตัวยึดทุกตัวก่อนที่จะดําเนินการ คําว่า profile-aware อธิบายการสนับสนุน API ไม่ใช่สถานะเลิกใช้

ระยะที่ 2: เตรียมใช้ข้อมูลประจําตัวใหม่

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

1. สร้างการลงทะเบียนแอปพลิเคชันและบริการหลัก บันทึก ID ไคลเอ็นต์ของแอปพลิเคชัน ID ออบเจ็กต์ของแอปพลิเคชัน และ ID ออบเจ็กต์ของบริการหลักแยกต่างหาก

2. กําหนดค่าข้อมูลประจําตัวภายนอกบนการลงทะเบียนแอปพลิเคชันของลูกค้าที่เชื่อถือ MI ของแอปพลิเคชันที่สร้างขึ้นในระยะที่ 0

3. ให้สิทธิ์การเข้าถึงบริการหลักใหม่ไปยังพื้นที่ทํางานของลูกค้าและทรัพยากรเดียวกัน ใช้สมาชิกที่การดําเนินการที่สินค้าคงคลังต้องการหรือบทบาทที่สนับสนุนน้อยที่สุด ให้สิทธิ์ผู้ดูแลระบบเมื่อจําเป็นเท่านั้น

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

ระยะที่ 3: อัปเดตรหัสแอปพลิเคชัน

• แทนที่การกําหนดค่าส่วนหัวการเลือกโปรไฟล์และโปรไฟล์ SDK ด้วยการแลกเปลี่ยนโทเค็นที่สํารองข้อมูลข้อมูลประจําตัวที่มีการจัดการสําหรับแอปพลิเคชันลูกค้าที่เลือก

• อัปเดตการแมปข้อมูลลูกค้าไปยังข้อมูลประจําตัวในฐานข้อมูลแอปพลิเคชันของคุณ

ก่อน	หลัง
customerId -> profileId ด้วยข้อมูลประจําตัว SP ที่แชร์หนึ่งรายการและส่วนหัวโปรไฟล์	customerId -> spClientId ด้วยการรับรองความถูกต้อง SP ต่อลูกค้าผ่านการแลกเปลี่ยนโทเค็นข้อมูลประจําตัวที่มีการจัดการ นอกจากนี้ยังเก็บ ID ผู้เช่าไดเรกทอรี การกําหนดค่าการรับรองความถูกต้อง และ ID ทรัพยากรที่ได้รับอนุญาต

รหัสลูกค้าเป็นตัวระบุเชิงตรรกะของลูกค้า ISV ไม่จําเป็นต้อง Microsoft Entra รหัสผู้เช่า ตรวจสอบความเป็นสมาชิกของลูกค้าของผู้ใช้ที่ได้รับการรับรองความถูกต้องก่อนที่จะเลือกข้อมูลประจําตัว การแคชโทเค็นคีย์โดยผู้เช่าไดเรกทอรี ID ไคลเอ็นต์ และทรัพยากรหรือขอบเขต

• อัปเดตการสร้างโทเค็นเฉพาะแอปพลิเคชันเพื่อใช้โทเค็นการเข้าถึงการบริการลูกค้าหลัก หากโซลูชันของคุณฝังรายงานหรือเนื้อหาอื่น ๆ ให้อัปเดตการสร้างโทเค็นนั้นด้วยเช่นกัน การฝังเป็นปริมาณงานที่มีอยู่เพื่อโยกย้าย ไม่ใช่ข้อกําหนดเบื้องต้นสําหรับคู่มือนี้

• อัปเดตการจัดการพื้นที่ทํางาน การเชื่อมต่อดาวน์สตรีม การเตรียมใช้งาน งานที่กําหนดเวลา และจุดเข้าใช้งานอื่น ๆ ทั้งหมดโดยใช้การกําหนดค่าโปรไฟล์เก่า

ระยะที่ 4: ตรวจสอบความถูกต้อง

สําหรับลูกค้าแต่ละราย ตรวจสอบ:

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

• การรับโทเค็นข้อมูลประจําตัวที่ได้รับการจัดการและการแลกเปลี่ยนโทเค็นภายนอกประสบความสําเร็จสําหรับแอปพลิเคชันลูกค้าที่ต้องการ

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

• การลงชื่อเข้าใช้บริการหลักใหม่จะปรากฏใน Microsoft Entra ID และสามารถสัมพันธ์กับบันทึกการตรวจสอบแอปพลิเคชันและทรัพยากร

• การเข้าถึงข้ามลูกค้าถูกปฏิเสธ: ผู้เรียกไม่สามารถเลือกข้อมูลประจําตัวของแอปพลิเคชันหรือรหัสทรัพยากรของลูกค้าอื่นได้

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

เปลี่ยนเส้นทางแอปพลิเคชันของลูกค้าเฉพาะหลังจากผ่านเกณฑ์การยอมรับแล้วเท่านั้น ตรวจสอบความล้มเหลว ประสิทธิภาพการทํางาน และสิทธิ์ก่อนที่จะขยายการเผยแพร่

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

ระยะที่ 5: โปรไฟล์การยกเลิกการใช้งาน

• หลังจากช่วงเวลาย้อนกลับ ให้ลบพื้นที่ทํางานหลักและโปรไฟล์เดิมที่เก่าออกไปหลังจากยืนยันว่าโครงร่างสําคัญของการบริการลูกค้าเฉพาะมีสิทธิ์เข้าถึงที่จําเป็น

ลบโปรไฟล์ที่โยกย้ายแต่ละรายการผ่าน API การจัดการโปรไฟล์:

DELETE {profile-api-base}/v1.0/myorg/profiles/{profileId}

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

หมายเหตุ

การโยกย้ายทางเลือกโดยไม่มี MI หรือสหพันธ์: ไม่แนะนําให้ใช้ข้อมูลประจําตัวที่มีการจัดการและข้อมูลประจําตัวภายนอก หากคุณไม่ต้องการใช้ โปรดละเว้นระยะที่ 0 ในขั้นตอนที่ 2 กําหนดค่าใบรับรองหรือข้อมูลประจําตัวอื่นที่ได้รับการสนับสนุนบนแอปพลิเคชันลูกค้าแต่ละรายแทนข้อมูลประจําตัวภายนอก ในระยะที่ 3 และ 4 รับและตรวจสอบโทเค็นการเข้าถึงโดยตรงในฐานะแอปพลิเคชันนั้น เก็บสินค้าคงคลังเดียวกัน การให้ทรัพยากร การอนุญาตของลูกค้า การเผยแพร่ และขั้นตอนการยกเลิก และดําเนินการเก็บข้อมูลข้อมูลประจําตัวที่ปลอดภัยและการหมุน

คู่มือการใช้งาน

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

ข้อกำหนดเบื้องต้น

• การสมัครใช้งาน Azure และสิทธิ์ในการสร้างและกําหนดข้อมูลประจําตัวที่มีการจัดการสําหรับเส้นทางที่แนะนํา

• สิทธิ์ใน Microsoft Entra ID ในการสร้างการลงทะเบียนแอปพลิเคชันและบริการหลัก และอัปเดตข้อมูลประจําตัวของแอปพลิเคชัน Azure สิทธิ์ทรัพยากรและสิทธิ์ไดเรกทอรีแยกกัน

• แอปพลิเคชันที่โฮสต์บน Azure รองรับการคํานวณ เช่น App Service, Container Apps, ปริมาณงาน AKS ที่กําหนดค่าอย่างเหมาะสม หรือเครื่องเสมือน แหล่งการยืนยันที่สํารองข้อมูลไว้ MI ในรูปแบบนี้ขึ้นอยู่กับการกําหนดค่าการโฮสต์ Azure นั้น

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

• Azure CLI ติดตั้งและลงชื่อเข้าใช้ผู้เช่าไดเรกทอรีที่ถูกต้อง ยืนยันบริบทการสมัครใช้งานก่อนที่จะสร้างทรัพยากร Azure

การตั้งค่าผู้เช่าของนักพัฒนา

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

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

การตั้งค่า API สาธารณะต่อไปนี้ใช้ป้ายชื่อที่เป็นกลางของผลิตภัณฑ์ อินเทอร์เฟซการดูแลระบบอาจรวมถึงชื่อของบริการ

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

ตรวจสอบค่าจริงแทนที่จะใช้ค่าเริ่มต้น ผู้เช่าใหม่และที่มีอยู่อาจแตกต่างกันได้ และผู้ดูแลระบบสามารถเปลี่ยนการตั้งค่าได้ เก็บการตั้งค่าโปรไฟล์ไว้จนกว่าจะมีการโยกย้ายลูกค้าและงานที่ขึ้นต่อกันทั้งหมด อย่าเปิดใช้งานการตั้งค่าการฝังสําหรับปริมาณงานที่ไม่ใช่แบบฝังตัว

ขั้นตอนที่ 1: สร้างและกําหนดข้อมูลประจําตัวที่จัดการโดยผู้ใช้

ข้อมูลประจําตัวที่มีการจัดการนี้แสดงถึงแอปพลิเคชัน ISV ไม่ใช่ลูกค้าแต่ละราย ใช้กลุ่มทรัพยากรที่มีอยู่:

az identity create \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --location "<azure-region>"

บันทึก ID ไคลเอ็นต์ ID หลัก (ออบเจ็กต์) ID ผู้เช่าไดเรกทอรี และ Azure ID ทรัพยากร กําหนดให้กับทรัพยากรการคํานวณ สําหรับแอปพลิเคชันบริการแอปที่มีอยู่:

az webapp identity assign \
  --resource-group "<resource-group>" \
  --name "<web-app-name>" \
  --identities "<managed-identity-resource-id>"

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

ขั้นตอนที่ 2: สร้างบริการหลักสําหรับลูกค้าแต่ละราย

สําหรับลูกค้าแต่ละราย ผู้ใช้ หรือขอบเขตกลุ่มที่โปรไฟล์ที่มีอยู่แสดง สร้างการลงทะเบียนแอปพลิเคชันและโครงร่างสําคัญของบริการ ตัวอย่างนี้สร้างแอปพลิเคชันผู้เช่าเดียวในไดเรกทอรีของ ISV:

APP_CLIENT_ID=$(az ad app create \
  --display-name "customer-a-application" \
  --sign-in-audience AzureADMyOrg \
  --query appId --output tsv)

az ad sp create --id "$APP_CLIENT_ID"

APP_OBJECT_ID=$(az ad app show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

SP_OBJECT_ID=$(az ad sp show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

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

หมายเหตุ

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

ขั้นตอนที่ 3: กําหนดค่าข้อมูลประจําตัวภายนอก

เรียกใช้ ID ข้อมูลประจําตัวหลักที่มีการจัดการและ ID ผู้เช่าของไดเรกทอรี ใช้ผู้เช่าของข้อมูลประจําตัวแทนสมมติว่าการสมัครใช้งานปัจจุบันที่แตกต่างกันมีผู้เช่าเดียวกัน:

MI_PRINCIPAL_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query principalId --output tsv)

DIRECTORY_TENANT_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query tenantId --output tsv)

เพิ่มข้อมูลประจําตัวภายนอกลงในการลงทะเบียนแอปพลิเคชันของลูกค้าแต่ละราย คําสั่ง global-cloud ต่อไปนี้ใช้ ID ออบเจ็กต์ของแอปพลิเคชันจากขั้นตอนที่ 2 และค่า MI ที่เพิ่งเรียกใช้:

az ad app federated-credential create \
  --id "$APP_OBJECT_ID" \
  --parameters "{
    \"name\": \"trust-application-mi\",
    \"issuer\": \"https://login.microsoftonline.com/$DIRECTORY_TENANT_ID/v2.0\",
    \"subject\": \"$MI_PRINCIPAL_ID\",
    \"audiences\": [\"api://AzureADTokenExchange\"],
    \"description\": \"Trust the ISV application managed identity\"
  }"

อีกวิธีหนึ่งคือ บันทึก JSON เดียวกันด้วยค่าที่แทนที่ในไฟล์ภายในเครื่อง credential.json และส่งผ่าน--parameters credential.json ทําซ้ําความน่าเชื่อถือในแอปพลิเคชันลูกค้าแต่ละราย อนุญาตให้มีการเผยแพร่การกําหนดค่าก่อนการตรวจสอบการแลกเปลี่ยนโทเค็น

ขั้นตอนที่ 4: ให้สิทธิ์การเข้าถึงพื้นที่ทํางานหลักแต่ละบริการ

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

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

PROFILE_API_BASE="<existing-profile-aware-api-base-url>"
PROFILE_RESOURCE="<existing-api-resource-identifier>"
WORKSPACE_ID="<customer-workspace-id>"

TOKEN=$(az account get-access-token \
  --resource "$PROFILE_RESOURCE" \
  --query accessToken --output tsv)

curl --fail-with-body --request POST \
  "$PROFILE_API_BASE/v1.0/myorg/groups/$WORKSPACE_ID/users" \
  --header "Authorization: Bearer $TOKEN" \
  --header "Content-Type: application/json" \
  --data "{
    \"identifier\": \"$SP_OBJECT_ID\",
    \"groupUserAccessRight\": \"Member\",
    \"principalType\": \"App\"
  }"

ใช้จุดสิ้นสุดและรูปร่างคําขอที่มีการบันทึกข้อมูลสําหรับบริการที่เป็นเจ้าของพื้นที่ทํางานที่มีอยู่ การดําเนินการที่แสดงจะนําไปใช้กับ API พื้นที่ทํางานแบบทราบโปรไฟล์ API อื่น ๆ อาจใช้ Schema การกําหนดบทบาทที่แตกต่างกัน อย่าแทนที่ ID ไคลเอ็นต์ที่การดําเนินการต้องการ ID ออบเจ็กต์ของบริการหลัก หลีกเลี่ยงการบันทึกโทเค็นแบบแบเรอร์และอนุญาตให้เผยแพร่สิทธิ์

ขั้นตอนที่ 5: รับรองความถูกต้องและเรียกใช้ API ในขณะทํางาน

1. แก้ไข ID ไคลเอ็นต์ของแอปพลิเคชันของลูกค้าที่ได้รับการรับรองความถูกต้องและทรัพยากรที่ได้รับอนุญาตจากการกําหนดค่าฝั่งเซิร์ฟเวอร์ที่เชื่อถือได้

2. รับโทเค็นการยืนยันโดยใช้ข้อมูลประจําตัวที่จัดการโดยผู้ใช้ที่กําหนดไว้และ api://AzureADTokenExchange/.default ขอบเขตในระบบคลาวด์ส่วนกลางที่เลือก

3. ใช้โทเค็น MI เป็นการยืนยันไคลเอ็นต์สําหรับแอปพลิเคชันลูกค้า ร้องขอโทเค็นการเข้าถึงด้วยขอบเขตแอปพลิเคชันของ API ทรัพยากร ไม่ใช่ผู้ชมการยืนยัน

4. เรียกใช้ API เป้าหมายโดยใช้โทเค็นการเข้าถึงแอปพลิเคชันของลูกค้านั้นและไม่มีการกําหนดค่าการเลือกโปรไฟล์ จัดการพื้นที่ทํางาน ร้องขอโทเค็นเฉพาะของแอปพลิเคชัน ที่จําเป็น และดําเนินการสร้างสินค้าคงคลังอื่น ๆ ผ่านข้อมูลประจําตัวของลูกค้า

สําหรับ.NET ให้ใช้ Azure Identity ClientAssertionCredential ด้วยโทเค็นข้อมูลประจําตัวที่มีการจัดการ เป็นการเรียกกลับการยืนยัน โฟลว์หกขั้นตอนและตัวอย่างการกําหนดค่าอย่างเป็นทางการแสดงการแลกเปลี่ยนโดยไม่ต้องมีตัวอย่างรหัสแอปพลิเคชันเฉพาะการฝังตัว

ทําให้การเตรียมความพร้อมและการไม่เข้าร่วมทํางานเป็นอัตโนมัติ

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

การดําเนินการทางเลือก: รับรองความถูกต้องของบริการหลักโดยตรง

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

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

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

ความปลอดภัย ข้อจํากัด และข้อควรพิจารณา

ใช้ตัวควบคุมต่อไปนี้กับเส้นทางการรับรองความถูกต้องที่คุณเลือก และวางแผนสําหรับขีดจํากัดการดําเนินงาน

คําแนะนําด้านความปลอดภัย

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

• ถือว่าแอปพลิเคชัน MI เป็นข้อมูลประจําตัวที่มีสิทธิ์พิเศษสูง ซึ่งสามารถรับรองความถูกต้องในฐานะแอปพลิเคชันลูกค้าทั้งหมดที่เชื่อถือได้ จํากัดสิทธิ์การปรับใช้การคํานวณ การกําหนดข้อมูลประจําตัวที่มีการจัดการ เจ้าของแอปพลิเคชัน และการจัดการข้อมูลประจําตัว ข้อมูลประจําตัวรันไทม์ของพาร์ติชันถ้าจําเป็นเพื่อลดความเสี่ยง

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

• การตั้งค่าผู้เช่าของขอบเขตด้วยกลุ่มความปลอดภัย รวมโครงร่างสําคัญของบริการลูกค้าที่เกี่ยวข้องทั้งหมดในกลุ่มที่ได้รับอนุญาตแทนที่จะเปิดใช้งานการเข้าถึงบริการหลักสําหรับทั้งองค์กร

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

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

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

ข้อจํากัดและข้อกําหนดในการดําเนินงาน

ข้อควรพิจารณา	สิ่งที่ต้องวางแผนสําหรับ
เพดานสเกลเมื่อเทียบกับโปรไฟล์	โปรไฟล์อนุญาตให้มี 100,000 ต่อบริการหลัก โดยมีพื้นที่ทํางานสูงสุด 1,000 รายการต่อโปรไฟล์ การลงทะเบียนแอปพลิเคชันเฉพาะและบริการหลักใช้ออบเจ็กต์ไดเรกทอรี ตรวจสอบโควตาไดเรกทอรี ขีดจํากัดพื้นที่ทํางานของบริการหลัก และการเตรียมปริมาณงานก่อนที่จะยืนยัน
ขีดจํากัดข้อมูลประจําตัวของภายนอก	การลงทะเบียนแอปพลิเคชันสนับสนุนข้อมูลประจําตัวภายนอกมากที่สุด 20 รายการ โดยทั่วไปสถาปัตยกรรมนี้จะต้องมีข้อมูลประจําตัวที่มีการจัดการรันไทม์ที่เชื่อถือได้บนแอปพลิเคชันลูกค้าแต่ละราย ซึ่งไม่ใช่หนึ่งต่อลูกค้าในแอปพลิเคชันที่ใช้ร่วมกัน
ข้อกําหนดของผู้เช่าเดียวกัน	ข้อมูลประจําตัวที่มีการจัดการและการลงทะเบียนแอปพลิเคชันที่น่าเชื่อถือแต่ละรายการต้องเป็นสมาชิกของผู้เช่า Microsoft Entra เดียวกัน นอกจากนี้ การเข้าถึงแหล่งข้อมูลในผู้เช่าอื่นต้องการการกําหนดค่าแอปพลิเคชันที่ได้รับการสนับสนุน ความยินยอม และสิทธิ์ของทรัพยากร
ไม่มีการแลกเปลี่ยนโทเค็นข้ามคลาวด์	อย่าแลกเปลี่ยนโทเค็นระหว่างระบบคลาวด์ Azure ที่แตกต่างกัน เช่น ระบบคลาวด์ส่วนกลางและส่วนราชการสหรัฐ ใช้จุดสิ้นสุดผู้ชมและหน่วยงานที่ถูกต้องภายในระบบคลาวด์เป้าหมาย
ข้อกําหนดการคํานวณ Azure	โฟลว์การยืนยันข้อมูลประจําตัวที่ได้รับการจัดการต้องการกลไกข้อมูลประจําตัวที่มีการจัดการของ Azure โฮสต์สภาพแวดล้อมที่ได้รับการสนับสนุน ถ้าแอปทํางานที่อื่นหรือคุณไม่ต้องการใช้รูปแบบนี้ ให้ใช้ตัวเลือกการรับรองความถูกต้องโดยตรงหรือการออกแบบการติดต่อกับภายนอกที่ได้รับการสนับสนุนอื่น
การเข้าถึงแบบมีเงื่อนไข	Microsoft Entra Workload ID Premium จําเป็นในการสร้างหรือปรับเปลี่ยนนโยบายการเข้าถึงตามเงื่อนไขของข้อมูลประจําตัวของปริมาณงาน นโยบายครอบคลุมโครงร่างสําคัญของบริการผู้เช่ารายเดียวที่องค์กรเป็นเจ้าของ และต้องกําหนดเป้าหมายโดยตรง พวกเขาไม่ครอบคลุมข้อมูลประจําตัวที่มีการจัดการหรือมีผลเฉพาะผ่านการเป็นสมาชิกกลุ่มเท่านั้น
การตั้งค่าผู้เช่าของนักพัฒนา	การบริการลูกค้าหลักทั้งหมดที่ใช้การตั้งค่าแบบกําหนดขอบเขตกลุ่มต้องอยู่ในกลุ่มความปลอดภัยที่ได้รับอนุญาต ตรวจทานการตั้งค่าทั้งสี่ในข้อกําหนดเบื้องต้นในการนําไปใช้งาน อย่าใช้ค่าเริ่มต้น
อัตโนมัติ	การจัดการข้อมูลประจําตัวลูกค้าหลายร้อยหรือหลายพันรายการด้วยตนเองนั้นทําไม่ได้ ทําให้การเตรียมใช้งาน โดยอัตโนมัติ ให้การเปลี่ยนแปลง ตรวจสอบ หมุน หรือเชื่อถือการอัปเดต และนอกระบบ จัดการการควบคุมด้วยการลองใหม่ที่ผูกไว้และการออกจากงาน
ประสบการณ์ที่ได้รับมอบสิทธิ์เท่านั้นยังคงอยู่นอกขอบเขต	การแทนที่โปรไฟล์ไม่ได้เปิดใช้งานการรับรองความถูกต้องเฉพาะแอปซึ่งปริมาณงานต้องการโทเค็นผู้ใช้ที่ได้รับมอบหมาย ในตัวอย่างการฝังแดชบอร์ด Real-Time รองรับเฉพาะประเภทรายการและการรับรองความถูกต้องผู้ใช้ที่ได้รับมอบหมายเท่านั้น โทเค็นเฉพาะแอปและแอปเป็นเจ้าของข้อมูลไม่ได้รับการสนับสนุน การฝังรายงานที่มีอยู่ใช้กลไกเฉพาะของบริการที่เกี่ยวข้อง

ดูขีดจํากัดบริการ Microsoft Entra และการสนับสนุนข้อมูลประจําตัว API ของบริการเป้าหมายก่อนเสร็จสิ้นความจุและสิทธิ์

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

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

ใช้ผู้ชม api://AzureADTokenExchangeการแลกเปลี่ยนโทเค็นคลาวด์ทั่วโลก ผู้ชม api://AzureADTokenExchangeUSGovส่วนราชการสหรัฐ หรือผู้ชม api://AzureADTokenExchangeChinaประเทศจีน ตามความเหมาะสม ตรงกับจุดสิ้นสุดของผู้มีสิทธิ์กับระบบคลาวด์ ตัวอย่างในบทความนี้ใช้ระบบคลาวด์ส่วนกลาง

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

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

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

ใช้การอ้างอิงเหล่านี้สําหรับสิทธิ์เฉพาะ API ข้อจํากัดข้อมูลประจําตัวปัจจุบัน และการกําหนดค่าปริมาณงานที่มีอยู่

โปรไฟล์ บริการหลัก และปริมาณงานที่มีอยู่

• การใช้งานหลายรายการด้วยโครงร่างสําคัญของบริการเฉพาะ
• โปรไฟล์บริการหลัก: โซลูชันการเช่าเป็นทางเลือก
• โปรไฟล์บริการหลักสําหรับแอปพลิเคชันการใช้งานหลายรายการ
• กําหนดค่าแอปพลิเคชันเนื้อหาที่มีอยู่เพื่อใช้โครงร่างสําคัญของบริการ
• การตั้งค่าผู้เช่าของนักพัฒนา
• ภาพรวมการฝังการวิเคราะห์ที่มีอยู่
• ตัวอย่างการฝังแดชบอร์ด Real-Time ผู้ใช้ที่ได้รับมอบสิทธิ์

การติดต่อกับภายนอกของข้อมูลประจําตัวของปริมาณงานและข้อมูลประจําตัวที่มีการจัดการ

• ภาพรวมการติดต่อกับภายนอกของข้อมูลประจําตัวของปริมาณงาน
• ข้อควรพิจารณาและข้อจํากัดที่สําคัญสําหรับข้อมูลประจําตัวภายนอก
• กําหนดค่าแอปพลิเคชันเพื่อเชื่อถือข้อมูลประจําตัวที่มีการจัดการ
• ข้อมูลประจําตัวที่มีการจัดการสําหรับทรัพยากร Azure
• ตัวอย่างการกําหนดค่าของสหพันธ์

SDKS, API และขีดจํากัดบริการ

• Azure Identity ClientAssertionCredential for .NET
• การอ้างอิงการสร้างโทเค็นเฉพาะแอปพลิเคชันสําหรับปริมาณงานการฝังที่มีอยู่
• ขีดจํากัดและข้อจํากัดของบริการ Microsoft Entra
• ข้อมูลประจําตัวแอปพลิเคชันที่ได้รับการสนับสนุนสําหรับ Fabric REST API
• ข้อมูลประจําตัวการเชื่อมต่อและการรักษาความปลอดภัยของ Direct Lake
• การเข้าถึงแบบมีเงื่อนไขสําหรับข้อมูลประจําตัวปริมาณงาน
• การดําเนินการกําหนดบทบาทพื้นที่ทํางาน
• API การจัดการโปรไฟล์