พอร์ทัล Odoo ช่วยให้ลูกค้าและพาร์ตเนอร์เข้าถึงเอกสาร ธุรกรรม และบริการที่เกี่ยวข้องได้ ซึ่งก่อให้เกิดคำถามด้านการออกแบบตัวตนขึ้นมา: ผู้ใช้ภายนอกควรใช้ไดเรกทอรีพนักงานและโมเดลการเข้าถึงร่วมกันหรือไม่?
บางครั้งบัญชีผู้เยี่ยมชมธุรกิจใน workforce tenant ก็เหมาะสม แต่ในระดับที่ใหญ่กว่า หรือเมื่อจำเป็นต้องมีการลงชื่อเข้าใช้ของลูกค้าแบบมีแบรนด์และการลงทะเบียนแบบ self-service, Microsoft Entra External ID จะมอบโมเดลการจัดการตัวตนและการเข้าถึงของลูกค้าโดยเฉพาะ
การเชื่อมโมเดลนั้นกับ Odoo สามารถช่วยสร้างขอบเขตที่ชัดเจนขึ้นระหว่างผู้ใช้ภายในและผู้ใช้พอร์ทัล อย่างไรก็ตาม ขอบเขตนี้ยังคงต้องมีการอนุญาต การสร้างบัญชี และกฎการอนุญาตของ Odoo อย่างชัดเจน
workforce tenant และ external tenant ออกแบบมาสำหรับกลุ่มเป้าหมายที่ต่างกัน
Microsoft ระบุว่า workforce tenant คือสภาพแวดล้อมสำหรับพนักงาน แอปพลิเคชันธุรกิจภายใน และทรัพยากรขององค์กร และยังสามารถมีพาร์ตเนอร์ธุรกิจและผู้เยี่ยมชมที่ได้รับเชิญได้ด้วย ส่วน external tenant เป็นการตั้งค่าแยกต่างหากสำหรับแอปที่มอบให้ผู้บริโภคและลูกค้าธุรกิจ Microsoft อธิบายความแตกต่างนี้ไว้ใน tenant configuration guidance.
external tenant มีไดเรกทอรีลูกค้าและการลงทะเบียนแอปของตัวเอง External ID เพิ่มความสามารถในการลงทะเบียนแบบ self-service, การลงชื่อเข้าใช้, การรีเซ็ตรหัสผ่าน, การจัดการบัญชี และการเชื่อมโยงผู้ให้บริการข้อมูลระบุตัวตน External ID overview อธิบายโมเดลเฉพาะนี้
การแยกเช่นนี้ช่วยให้องค์กรหลีกเลี่ยงการมองลูกค้าเป็นพนักงาน เพียงเพราะทั้งสองฝ่ายต้องเข้าถึงบริการ Odoo
เลือกกลุ่มเป้าหมายก่อนกำหนดค่าการลงชื่อเข้าใช้
มีผู้ชม Odoo อย่างน้อย 3 กลุ่มที่ควรพิจารณา:
พนักงานและผู้ใช้ภายใน
ผู้ใช้เหล่านี้โดยปกติควรอยู่ใน workforce tenant ขององค์กร หากได้รับอนุญาตให้เข้าใช้ Odoo พวกเขาโดยทั่วไปจะต้องมีบัญชีผู้ใช้ภายในของ Odoo พร้อมกลุ่มการเข้าถึงที่กำหนดอย่างระมัดระวัง
ผู้ที่มาจากองค์กรพาร์ตเนอร์ที่ได้รับอนุมัติ
บางธุรกิจต้องการให้ผู้ใช้จากรายการที่กำหนดไว้ของ tenant ลูกค้าหรือพาร์ตเนอร์ใน Entra ใช้ได้ การเชื่อมต่อ workforce แบบหลาย tenant พร้อม allow-list ของ tenant ที่ระบุอย่างแม่นยำอาจเหมาะสมเมื่อทุกองค์กรเป็นที่รู้จักและสิทธิ์การเข้าถึงได้รับการอนุมัติตามสัญญา
การตรวจสอบ tenant มีความสำคัญอย่างยิ่ง การจับคู่เฉพาะโดเมนอีเมลไม่เพียงพอ เพราะโดเมนและที่อยู่อีเมลสามารถเปลี่ยนแปลงได้ ให้ตรวจสอบ tenant ของโทเค็นและตัวระบุ subject หรือ object ที่ไม่เปลี่ยนแปลงตามการออกแบบของการเชื่อมต่อ
ลูกค้าและผู้ใช้ภายนอก
สำหรับแอปที่ให้บริการลูกค้า, external ID tenant สามารถมอบไดเรกทอรีและประสบการณ์ลงชื่อเข้าใช้แยกต่างหากได้ บัญชี Odoo ที่สร้างสำหรับกลุ่มนี้โดยปกติควรเป็นผู้ใช้พอร์ทัล ไม่ใช่ผู้ใช้ภายใน
โมเดลเหล่านี้ควรถูกตั้งค่าเป็นการเชื่อมต่อแยกกันเมื่อกฎการอนุญาตและกฎบัญชี Odoo แตกต่างกัน การเชื่อมต่อแบบกว้างเพียงหนึ่งเดียวจะเหตุผลรองรับได้ยากกว่า และตั้งค่าผิดพลาดได้ง่ายกว่า
External ID รองรับเส้นทางการลงชื่อเข้าใช้ของลูกค้า
user flow ของ External ID กำหนดวิธีการยืนยันตัวตนของลูกค้าและข้อมูลที่เก็บระหว่างการสมัครใช้งาน flow หนึ่งจะเชื่อมกับแอปที่ลงทะเบียนไว้เพื่อเปิดใช้งานการสมัครและการลงชื่อเข้าใช้ Microsoft อธิบายเรื่องนี้ไว้ใน adding an application to an External ID user flow.
External ID รองรับบัญชีท้องถิ่นและการเชื่อมโยงกับผู้ให้บริการข้อมูลระบุตัวตน รวมถึง Microsoft Entra ID และผู้ให้บริการ OpenID Connect แบบกำหนดเอง สามารถเก็บแอตทริบิวต์ในตัวและแอตทริบิวต์ที่กำหนดเองระหว่างการสมัครใช้งานได้ ตามที่ Microsoft อธิบายไว้ใน customer attribute guidance.
เก็บเฉพาะข้อมูลที่ Odoo ต้องใช้อย่างแท้จริง และบันทึกวัตถุประสงค์ ระยะเวลาการเก็บรักษา และการจัดการความเป็นส่วนตัวของแอตทริบิวต์ทุกตัว
สิทธิ์เริ่มต้นช่วยรักษาการแยกขอบเขต
Microsoft ระบุว่าผู้ใช้ใน external tenant จะเริ่มต้นด้วยสิทธิ์เริ่มต้นที่จำกัด โดยทั่วไปสามารถเข้าถึงแอปพลิเคชันและจัดการโปรไฟล์ของตนเองได้ แต่จะไม่ได้รับสิทธิ์การดูแลไดเรกทอรีในวงกว้าง ดู default permissions in external tenants.
ขอบเขตของไดเรกทอรีนั้นไม่ได้ตั้งค่าการอนุญาตพอร์ทัลของ Odoo โดยอัตโนมัติ Odoo ยังเป็นผู้ควบคุมว่าผู้ใช้พอร์ทัลจะเห็นระเบียนใดผ่านสิทธิ์การเข้าถึงและ record rules ของตนเอง ทดสอบประสบการณ์พอร์ทัลด้วยระเบียนลูกค้าตัวแทนและมากกว่าหนึ่งบริษัทหรือบัญชี เพื่อให้แน่ใจว่าข้อมูลถูกแยกอย่างถูกต้อง
อย่ายกระดับผู้ใช้ภายนอกที่สร้างใหม่ให้เป็นผู้ใช้ภายในของ Odoo เว้นแต่จะมีกระบวนการทางธุรกิจแยกต่างหากที่ได้รับอนุมัติ
ใช้โฟลว์ OpenID Connect ที่ทันสมัยและผ่านการตรวจสอบ
Microsoft รองรับ OAuth 2.0 authorization code flow ร่วมกับ Proof Key for Code Exchange และ OpenID Connect สำหรับเว็บแอปพลิเคชันฝั่งเซิร์ฟเวอร์ เอกสาร authorization code flow documentation อธิบายชุดความสามารถที่รองรับนี้
OIDC ขยาย OAuth 2.0 สำหรับการยืนยันตัวตน Microsoft เผยแพร่ discovery metadata รายละเอียด endpoint และ public signing keys นอกจากนี้ยังแนะนำให้ตรวจสอบโทเค็นที่ส่งกลับและตรวจ nonce เพื่อลดความเสี่ยงจากการเล่นซ้ำ ดู OpenID Connect on the Microsoft identity platform.
การเชื่อมต่อที่ปลอดภัยควรตรวจสอบ issuer, audience, signature, tenant context และ nonce ที่คาดไว้ PKCE ไม่ได้แทนที่การตรวจสอบโทเค็น, การกำหนดค่า callback ที่ถูกต้อง, TLS หรือการป้องกัน client secret
การลงชื่อเข้าใช้พื้นฐานสามารถขอขอบเขต OIDC มาตรฐาน เช่น openid, profile และ email ได้ Microsoft ระบุว่าขอบเขตเหล่านี้อยู่บน Microsoft Graph และแนะนำให้ขอเฉพาะสิทธิ์ที่แอปต้องใช้ ดู Microsoft identity platform scopes ดังนั้นคำกล่าวอ้างที่แม่นยำคือ "ไม่มี Microsoft Graph API permissions ที่มีสิทธิ์สูงสำหรับการลงชื่อเข้าใช้พื้นฐาน" มากกว่าการกล่าวแบบเหมารวมว่า Graph ไม่เกี่ยวข้อง
ตัดสินใจว่าผู้ใช้ภายนอกจะเข้าถึง Odoo อย่างไร
ก่อนเปิดใช้งานการลงชื่อเข้าใช้ครั้งแรก ให้กำหนดว่า:
- จะเปิดให้ self-registration หรือจำเป็นต้องได้รับการอนุมัติ
- tenant หรือ identity provider ใดบ้างที่ได้รับอนุญาต
- จะสามารถเชื่อมกับบัญชีพอร์ทัล Odoo ที่มีอยู่แล้วได้หรือไม่
- ตัวระบุ Microsoft แบบไม่เปลี่ยนแปลงใดที่จัดเก็บไว้หลังการเชื่อมโยง
- บริษัท Odoo และระเบียนพาร์ทเนอร์ใดที่ผู้ใช้สังกัดอยู่
- กลุ่มพอร์ทัลและกฎระเบียนใดที่มีผลบังคับใช้
- จะเกิดอะไรขึ้นเมื่อมีการถอนการเข้าถึง
- เซสชัน Odoo ที่ยังใช้งานอยู่ถูกเพิกถอนได้อย่างไร
การสร้างบัญชีอัตโนมัติสามารถลดภาระการดูแลระบบได้ แต่ควรเกิดขึ้นก็ต่อเมื่ออัตลักษณ์นั้นผ่านกฎการอนุญาตของการเชื่อมต่อแล้ว การยืนยันตัวตน Microsoft ที่สำเร็จพิสูจน์ได้ว่ามีการควบคุมอัตลักษณ์ที่ยอมรับ แต่เพียงอย่างเดียวยังไม่พิสูจน์ว่าบุคคลนั้นควรเห็นระเบียน Odoo ของลูกค้ารายใดรายหนึ่ง
วางแผนสำหรับการสนับสนุนลูกค้าและการกู้คืน
ผู้ใช้งานภายนอกอาจไม่มีฝ่ายช่วยเหลือภายในองค์กร เผยแพร่ช่องทางการสนับสนุนและระบุผู้ที่ดูแลอัตลักษณ์นั้น ทดสอบสถานการณ์การรีเซ็ตรหัสผ่าน การกู้คืน การนำเทนเนนต์ออก และการเปลี่ยนอีเมล เก็บเหตุการณ์วิเคราะห์ให้มีประโยชน์แต่ปกปิดข้อมูลสำคัญ
หากความต้องการเร่งด่วนของคุณคือการเข้าถึงของพนักงาน โปรดอ่านเหตุใดคุณจึงควรปกป้อง Odoo instance ของคุณด้วย Microsoft SSO. สำหรับสิทธิ์ภายใน โปรดดูการรวมศูนย์การเข้าถึง Odoo ด้วย Entra groups และ app roles.
เชื่อมต่อกลุ่มเป้าหมายภายนอกกับ Odoo 19
ของเราโมดูล Microsoft Entra SSO for Odooรองรับการเชื่อมต่อแยกสำหรับพนักงาน องค์กรที่ได้รับอนุมัติ และกลุ่มเป้าหมายลูกค้า Microsoft Entra External ID การเชื่อมต่อ External ID จะสร้างผู้ใช้พอร์ทัลเป็นค่าเริ่มต้น ขณะที่การเชื่อมต่อ workforce จะสร้างผู้ใช้ภายใน การตั้งค่าแบบมีคำแนะนำจะตรวจสอบข้อมูลการค้นพบและคีย์ลงนาม จากนั้นจะต้องมีการทดสอบแบบโต้ตอบก่อนเปิดใช้งานการลงชื่อเข้าใช้ Microsoft
โมดูลนี้ไม่ได้ตัดสินว่าใครควรถูกอนุญาตให้เข้าใช้ หรือควรเห็นระเบียนลูกค้าใด ข้อเหล่านั้นยังคงเป็นการตัดสินใจทางธุรกิจและการเข้าถึงของ Odoo ตรวจสอบโมดูลนี้หากคุณต้องการสะพานเชื่อมที่ควบคุมได้ระหว่างอัตลักษณ์ลูกค้า Microsoft และ Odoo 19 portal โดยมีการจัดการบัญชีตามกลุ่มเป้าหมายแทนที่จะเป็นเส้นทางการเข้าสู่ระบบแบบเดียวที่ไม่แยกแยะ