การลงชื่อเข้าใช้ครั้งเดียวตอบคำถามด้านการยืนยันตัวตนว่า Microsoft ได้ยืนยันผู้ใช้นี้ตามนโยบายขององค์กรหรือไม่ แต่ไม่ได้ตอบทุกคำถามด้านการอนุญาตภายใน Odoo
ผู้ใช้ที่ผ่านการยืนยันตัวตนอาจต้องเข้าถึงงานขายแต่ไม่ใช่งานบัญชีโครงการแต่ไม่ใช่เงินเดือน หรือพอร์ทัลลูกค้าแต่ไม่ใช่ส่วนติดต่อภายใน การตัดสินใจเหล่านั้นยังเป็นหน้าที่ของ Odoo Microsoft Entra groups และ application roles สามารถเป็นข้อมูลนำเข้าที่เชื่อถือได้เพื่อให้การตัดสินใจเหล่านี้สอดคล้องกันมากขึ้น
Groups และ app roles มีวัตถุประสงค์ต่างกัน
Microsoft Entra groups อยู่ใน tenant กลุ่มเหล่านี้อาจแทนแผนก หน้าที่งาน โครงการ หรือขอบเขตความปลอดภัย ส่วน application roles อยู่ภายใต้ app registration เฉพาะและอธิบายบทบาทที่มีความหมายต่อแอปนั้น
เอกสาร app-role documentation ของ Microsoft อธิบายว่า app roles สามารถกำหนดให้กับผู้ใช้หรือกลุ่มได้ เมื่อผู้ใช้ที่ได้รับมอบหมายลงชื่อเข้าใช้ Entra สามารถใส่บทบาทที่ได้รับลงใน roles claim ได้ Microsoft ยังระบุด้วยว่า app roles และ groups ไม่ได้ตัดกันแบบเลือกอย่างใดอย่างหนึ่ง
สิ่งนี้ทำให้การออกแบบการเข้าถึง Odoo มีรูปแบบหลักสองแบบ:
- แมป Microsoft Entra security-group Object ID ที่คงที่ไปยังกลุ่ม Odoo ที่เลือกโดยตรง
- กำหนด app roles ที่มุ่งเน้น Odoo ภายในแอปของ Entra มอบหมายให้ผู้ใช้หรือกลุ่มตามบทบาทเหล่านั้น แล้วแมปค่าบทบาทที่ได้ไปยังกลุ่ม Odoo
การแมปโดยตรงเหมาะกับ security groups ที่มีการกำกับดูแล ส่วน app roles สามารถสร้างขอบเขตแอปพลิเคชันที่ชัดเจนกว่า เพราะเจตนาของบทบาทติดไปกับ app registration แทนที่จะพึ่งพาชื่อที่ขึ้นกับ tenant
เริ่มจากโมเดลการเข้าถึงจริงของ Odoo
อย่าเริ่มจากการคัดลอกทุก Microsoft group เข้า Odoo ให้เริ่มจากสิทธิ์ใน Odoo ที่ธุรกิจต้องการจริง
ระบุกลุ่ม Odoo ที่มอบความสามารถสำคัญแต่ละรายการ สำหรับแต่ละรายการให้บันทึก:
- วัตถุประสงค์ทางธุรกิจของการเข้าถึง
- ผู้รับผิดชอบในการอนุมัติ
- Entra group หรือ app role ที่เป็นตัวแทนการอนุมัติ
- การเปลี่ยนแปลงควรไปถึง Odoo เร็วแค่ไหน และจะเกิดอะไรกับเซสชันที่ยังใช้งานอยู่หลังการถอนสิทธิ์
ใช้หลักสิทธิ์น้อยที่สุด กลุ่มแผนกขนาดใหญ่อาจสะดวก แต่ก็อาจให้สิทธิ์ Odoo มากเกินกว่าที่สมาชิกทุกคนต้องใช้ กลุ่มความปลอดภัยหรือ app role ที่เฉพาะ Odoo ขนาดเล็กมักตรวจสอบได้ง่ายกว่า
ให้การผูกอัตลักษณ์เป็นการควบคุมด้านความปลอดภัย
หลายระบบเริ่มจากการจับคู่บัญชีที่มีอยู่ด้วยที่อยู่อีเมล ซึ่งสะดวก โดยเฉพาะเมื่อ Odoo และ Microsoft ใช้อีเมลองค์กรเดียวกัน แต่นั่นไม่ใช่คีย์อัตลักษณ์ที่คงทน
Microsoft เตือนใน ID token claims reference ว่าที่อยู่อีเมล หมายเลขโทรศัพท์ และ user principal names สามารถเปลี่ยนได้และสามารถถูกนำกลับมาใช้ใหม่ได้ Microsoft แนะนำให้ใช้อ้างอิงที่เปลี่ยนไม่ได้ เช่น sub หรือ oid และใช้ tid เมื่อจำเป็นต้องมีบริบทของ tenant เพื่อการระบุตัวตนที่เชื่อถือได้
รูปแบบที่ปลอดภัยกว่าคือ:
- ยอมรับเฉพาะ tenant ที่คาดไว้และ audience ที่ได้รับอนุมัติ
- ใช้อีเมลสำหรับการจับคู่ครั้งแรกแบบควบคุมได้เมื่อเหมาะสม
- ปฏิเสธการจับคู่ที่กำกวม หรือซ้ำกัน
- จัดเก็บ Microsoft identity และตัวระบุ tenant ที่เปลี่ยนไม่ได้หลังการเชื่อมโยง
- ใช้ค่าที่เปลี่ยนไม่ได้นั้นสำหรับการลงชื่อเข้าใช้ครั้งต่อไป
สำหรับการเข้าถึงแบบหลาย tenant บริบทของ tenant เป็นสิ่งจำเป็น บุคคลเดียวกันอาจมี object identifier ต่างกันในแต่ละ tenant และการเข้าถึงจาก tenant หนึ่งไม่ควรรับสิทธิ์ที่เกี่ยวข้องกับอีก tenant หนึ่งโดยอัตโนมัติ
ทำความเข้าใจกรณี group-claim overage
Group claims สะดวกก็จริง แต่ไม่จำกัด Microsoft ระบุขีดจำกัดของ Object ID ของกลุ่มไว้ที่ 200 รายการใน JWT เมื่อสมาชิกภาพของผู้ใช้เกินขีดจำกัด Entra จะไม่ส่งรายการกลุ่มปกติ และจะส่งตัวบ่งชี้ overage ที่ชี้ให้แอปไปสอบถาม Microsoft Graph ดู groups overage guidance.
สิ่งนี้สำคัญหากการเชื่อมต่อโฆษณาการแมปกลุ่มโดยไม่ต้องใช้สิทธิ์ Microsoft Graph API ระดับสูง ผู้ใช้ที่เป็นสมาชิกหลายกลุ่มอาจไม่ได้รับชุด group claim ที่คาดไว้
ก่อนพึ่งพาการแมปกลุ่มโดยตรง ให้ยืนยันว่าจะจัดการ overage อย่างไร ตัวเลือกได้แก่ กลุ่มเฉพาะแอปที่เล็กกว่า app roles การกรอง claims หรือการค้นหาผ่าน Graph โดยให้ความยินยอมแบบสิทธิ์น้อยที่สุด
การซิงโครไนซ์ตอนลงชื่อเข้าใช้ไม่ใช่การ provision แบบเรียลไทม์
โมดูล SSO สามารถเปรียบเทียบ claims ปัจจุบันของ Entra กับการแมป Odoo ที่กำหนดไว้เมื่อผู้ใช้ลงชื่อเข้าใช้ นั่นมีประโยชน์เพราะการเข้าถึงสามารถปรับให้ตรงกันระหว่างเหตุการณ์การยืนยันตัวตนตามปกติ
แต่นั่นไม่เหมือนกับการ provision อย่างต่อเนื่อง หากพนักงานถูกนำออกจาก Entra group ในขณะที่เซสชัน Odoo ยังเปิดอยู่ เซสชันนั้นอาจดำเนินต่อไปจนกว่าจะออกจากระบบ หมดอายุ หรือมีการควบคุมการเพิกถอนอื่น लागू หากพนักงานเก่าไม่กลับมาลงชื่อเข้าใช้อีก กระบวนการซิงโครไนซ์ตอนลงชื่อเข้าใช้ก็ไม่ได้เก็บบัญชี Odoo โดยตัวมันเอง
Microsoft Entra ID Governance มี Lifecycle Workflows สำหรับกระบวนการ joiner, mover และ leaver รวมถึงการปิดใช้งานบัญชีและการลบการมอบหมายสิทธิ์ ดู Lifecycle Workflows guidance. ความสามารถเหล่านี้ต้องใช้ไลเซนส์ Microsoft Entra ID Governance หรือ Microsoft Entra Suite
ระบบอัตโนมัติด้าน lifecycle สามารถปรับปรุงสถานะอัตลักษณ์ต้นทางได้ แต่ก็ยังไม่อัปเดต Odoo เว้นแต่จะมีการเชื่อมต่อที่นำการเปลี่ยนแปลงนั้นมาใช้ กระบวนการ offboarding ควรครอบคลุมการเพิกถอนเซสชัน Odoo และสถานะบัญชีอย่างชัดเจน
สร้างโมเดลการแมปที่ตรวจสอบได้
รักษาจำนวนการแมปให้อยู่ในระดับที่เข้าใจได้ สำหรับแต่ละ group หรือ role ให้ใช้ตัวระบุที่คงที่และคำอธิบายที่อ่านง่าย บันทึกด้วยว่าทำไมการเข้าถึง Odoo ที่เกี่ยวข้องจึงมีอยู่ ใครอนุมัติ และมีการทบทวนล่าสุดเมื่อใด
ทดสอบอย่างน้อยกรณีต่อไปนี้:
- ผู้ใช้เดิมที่มีการแมปที่คาดไว้เพียงรายการเดียว
- ผู้ใช้ที่ไม่มีการแมปที่อนุมัติ หรืออยู่ใน tenant ที่ไม่อนุญาต
- ผู้ใช้ใหม่ที่ได้รับอนุญาตสำหรับการลงชื่อเข้าใช้ครั้งแรก
- ผู้ใช้ที่ถูกนำออกจากกลุ่มที่แมปไว้ หรือมีการเป็นสมาชิกหลายกลุ่ม
- ผู้ใช้ที่ถูกเปลี่ยนชื่อ ซึ่งอัตลักษณ์ถาวรยังไม่เปลี่ยนแปลง
- บัญชี Microsoft ที่ถูกปิดใช้งานพร้อมเซสชัน Odoo ที่มีอยู่
เหตุการณ์การลงชื่อเข้าใช้ควรช่วยให้ผู้ดูแลระบบวินิจฉัยผลลัพธ์ของการอ้างสิทธิ์และการแมปได้ โดยไม่เปิดเผยโทเค็น ข้อมูลประจำตัว หรือความลับ บันทึกควรระบุการเชื่อมต่อและผลลัพธ์ แต่ควรปกปิดค่าที่ละเอียดอ่อน
ผสานการแมปเข้ากับนโยบายการยืนยันตัวตน
การควบคุมการแมปกลุ่มและบทบาทเป็นตัวกำหนดการอนุญาตใน Odoo ส่วน Microsoft Entra Conditional Access ควบคุมว่า Microsoft จะทำการยืนยันตัวตนให้เสร็จสมบูรณ์ภายใต้เงื่อนไขปัจจุบันหรือไม่ ทั้งสองชั้นทำงานเสริมกัน
ตัวอย่างเช่น บทบาทแอปใน Entra สามารถแมปกับกลุ่มการเงินใน Odoo ได้ ขณะที่ Conditional Access กำหนดให้ผู้ใช้ที่ได้รับมอบหมายบทบาทนั้นต้องใช้ความแข็งแกร่งในการยืนยันตัวตนที่ต้านทานฟิชชิง อ่าน Microsoft Entra Conditional Access ช่วยเพิ่มความปลอดภัยให้การลงชื่อเข้าใช้ Odoo อย่างไร สำหรับส่วนของนโยบายการยืนยันตัวตน
สำหรับลูกค้าและพาร์ทเนอร์ อย่านำการแมปพนักงานมาใช้ซ้ำโดยอัตโนมัติ การออกแบบแยกกลุ่มเป้าหมายและเน้นพอร์ทัลอาจปลอดภัยกว่า ดู Microsoft Entra External ID สำหรับลูกค้าและพาร์ทเนอร์ของ Odoo.
แมปสิทธิ์การเข้าถึง Microsoft ที่ได้รับอนุมัติไปยัง Odoo 19
โมดูล Microsoft Entra SSO for Odoo ของเรารองรับการแมป Object ID ของกลุ่มความปลอดภัยใน Entra หรือบทบาทแอปที่กำหนดค่าไว้ไปยังกลุ่มการเข้าถึง Odoo ที่เลือกได้ โดยสามารถซิงโครไนซ์การแมปเหล่านั้นเมื่อมีการลงชื่อเข้าใช้ เชื่อมโยงบัญชีเดิมที่มีการควบคุม และสร้างผู้ใช้พนักงานหรือผู้ใช้พอร์ทัลที่ได้รับอนุมัติตามประเภทการเชื่อมต่อ
โมดูลนี้ไม่ได้แทนที่การกำกับดูแลการเข้าถึง การเพิกถอนเซสชัน หรือกลยุทธ์การรองรับส่วนเกินที่มีการจัดทำเป็นเอกสาร โปรดตรวจสอบขนาดของกลุ่ม ข้อกำหนดการผูกอัตลักษณ์ และโมเดลสิทธิ์ของ Odoo ก่อนเปิดใช้งานการแมป หากพื้นฐานเหล่านั้นชัดเจน โมดูลนี้จะมอบวิธีที่มีคำแนะนำในการเชื่อมโยงทั้งหมดเข้าด้วยกัน