เมื่อพูดถึงโมเดลอัตลักษณ์ ผลิตภัณฑ์ B2B อยู่ในระดับของตัวเอง พวกเขาต้องจัดการกับความซับซ้อนของการใช้หลายที่อยู่อาศัยในขณะที่ตอบสนองความต้องการของลูกค้าองค์กรในการจัดการอัตลักษณ์และการเข้าถึงแบบรวมศูนย์สำหรับพนักงานในบริการและแอปพลิเคชันมากมาย Logto ก็พบกับความต้องการเหล่านี้จากลูกค้าเช่นกัน ในบทความนี้ เราจะใช้วิธีการมุ่งเน้นผลิตภัณฑ์เพื่อทำความเข้าใจ SP-initiated SSO และวิธีที่มันตอบสนองความต้องการของลูกค้าของคุณ
แนวคิด#
เริ่มต้นด้วยการแนะนำส่วนประกอบสำคัญที่คุณต้องเข้าใจ:
- ผู้ให้บริการ (SP): แอปพลิเคชันหรือบริการของคุณ ซึ่งอาจเป็นแอปหนึ่งหรือหลายแอปที่ใช้ระบบอัตลักษณะเดียวกัน
- ผู้ให้บริการอัตลักษณะในองค์กร (IdP): ผู้ให้บริการอัตลักษณะที่ลูกค้าองค์กรของคุณพึ่งพาในการจัดการอัตลักษณะพนักงานและสิทธิ์การใช้แอปพลิเคชัน ซึ่งอาจใช้ผู้ให้บริการต่าง ๆ เช่น Okta, Azure AD, Google Workspace หรือ IdP ที่สร้างขึ้นเอง
- องค์กรของผู้ให้บริการ (SP Org): แอป B2B มักจะรองรับหลายที่อยู่อาศัยสำหรับองค์กรลูกค้าต่าง ๆ
- องค์กรของผู้ให้บริการอัตลักษณะ (IdP Org): IdP ก็รองรับหลายที่อยู่อาศัยสำหรับองค์กรลูกค้าต่าง ๆ โดยอุดมคติแล้วองค์กรหนึ่งควรจะสามารถเชื่อมต่อ IdP Org กับ SP Org ได้ ทำซ้ำอัตลักษณ์พนักงาน แต่ในความเป็นจริงอาจซับซ้อนมากขึ้น
- บัญชีผู้ใช้งานองค์กร: โดยมักจะระบุโดยการใช้โดเมนอีเมลของบริษัทในการล็อกอิน บัญชีอีเมลองค์กรนี้ในที่สุดจะเป็นของบริษัท
จากนั้นดำดิ่งสู่ SSO และโปรโตคอลหลักสองตัว:
- Single sign-on (SSO): SSO อนุญาตให้ผู้ใช้เข้าถึงบริการหรือแอปพลิเคชันหลายตัวด้วยชุดข้อมูลรับรองเดียว มันช่วยให้ง่ายต่อการจัดการการเข้าถึงและเพิ่มความปลอดภัย
- โปรโตคอล SAML และ OIDC: SSO พึ่งพาโปรโตคอลเหล่านี้ในการยืนยันตัวตนและการอนุญาต ซึ่งแต่ละโปรโตคอลมีข้อดีและข้อเสียของตัวเอง
มีสองกลไกหลักในการกระตุ้น SSO ที่ควรพิจารณา:
- IdP-initiated SSO: ใน IdP-initiated SSO ผู้ให้บริการอัตลักษณะ (IdP) เป็นผู้ควบคุมกระบวนการ single sign-on โดยส่วนใหญ่ ผู้ใช้เริ่มการยืนยันตัวตนจากหน้าอินเทอร์เฟซของ IdP
- SP-initiated SSO: ใน SP-initiated SSO ผู้ให้บริการ (SP) จะเป็นผู้ริเริ่มและจัดการกระบวนการ single sign-on มักจะได้รับความนิยมในกรณี B2B
ตอนนี้ เรามาสำรวจ SP-initiated SSO ในรายละเอียดกัน
ระดับพื้นผิว: ประสบการณ์ของผู้ใช้#
ต่างจากผลิตภัณฑ์ B2C ที่สามารถเสนอปุ่มลงชื่อเข้าใช้ของ IdP สังคมที่กำหนดได้สองสามปุ่ม ผลิตภัณฑ์ B2B ไม่สามารถบอกได้ว่าแต่ละลูกค้าใช้ Enterprise IdP ใด ดังนั้น ผู้ใช้จึงต้องประกาศอัตลักษณ์ของตนก่อน หลังจากยืนยันว่าเป็นสมาชิกขององค์กรที่เปิดใช้งาน SSO แล้วพวกเขาจะถูกเปลี่ยนเส้นทางไปยัง Enterprise IdP ของตนสำหรับการลงชื่อเข้าใช้
เพื่อให้บรรลุผลนี้ คุณต้อง ในหน้าลงชื่อเข้าใช้ กำหนดว่าผู้ใช้ต้องลงชื่อเข้าใช้ผ่าน SSO หรือไม่และควรเปลี่ยนเส้นทางไปยัง IdP ใด วิธีการทั่วไปประกอบด้วย:
- การทำแผนที่โดเมนอีเมล: เชื่อมโยงโดเมนอีเมลกับ IdP connector เฉพาะ ซึ่งมีผลต่อผู้ใช้ที่มีที่อยู่อีเมลภายใต้โดเมนนั้น ตรวจสอบการยืนยันเจ้าของโดเมนเพื่อป้องกันการตั้งค่าผิดพลาด
- การทำแผนที่ชื่อองค์กร: เชื่อมโยงชื่อองค์กรกับ IdP connector โดยพึ่งพาผู้ใช้ในการจดจำชื่อองค์กรของตน
- การทำแผนที่อีเมลส่วนตัวของผู้ใช้: ทำให้คุณสามารถกำหนดโดยตรงว่าบัญชีผู้ใช้ถูกเปิดใช้งานสำหรับ SSO โดยไม่พึ่งพาโดเมนอีเมลหรือชื่อองค์กร วิธีนี้สามารถทำได้โดยเชิญผู้ใช้ด้วยตนเอง การปรับแต่งกฎของ SSO ที่ต้องการ หรือการซิงค์บัญชีของพวกเขาอัตโนมัติผ่านการซิงค์ไดเรกทอรี
ในการออกแบบหน้าแรกการลงชื่อเข้าใช้ โดยทั่วไปมีสองรูปแบบ ซึ่งสามารถเลือกใช้ตามธุรกิจของผลิตภัณฑ์ของคุณ:
- ผลิตภัณฑ์ B2B: แนะนำให้แสดงปุ่ม SSO โดยตรงเพื่อให้ชัดเจนสำหรับสมาชิกองค์กรของคุณที่ต้องใช้ SSO
- ผลิตภัณฑ์ที่เข้ากันได้กับ B2C และ B2B: เนื่องจากผู้ใช้ส่วนใหญ่จะไม่ใช้ SSO ให้ประเมินโดเมนอีเมลเพื่อกำหนดว่าต้องการ SSO หรือไม่ คุณสามารถชะลอการแสดงการตรวจสอบข้อมูลรับรอง โดยซ่อนมันในตอนแรกและเปิดเผยเมื่อยืนยันอัตลักษณ์ของผู้ใช้
ความซับซ้อนใต้พื้นผิว: โมเดลอัตลักษณ์ผู้ใช้#
อย่างไรก็ตาม การรวม SSO เข้ากับระบบอัตลักษณ์ของคุณเกี่ยวข้องกับความซับซ้อนมากกว่าการเพิ่มปุ่ม SSO เพียงปุ่มเดียวในหน้าลงชื่อเข้าใช้ คุณต้องพิจารณาปัจจัยเพิ่มเติมอีกมาก
ความสัมพันธ์ขององค์ประกอบหลักนั้นมักไม่เป็นหนึ่งต่อหนึ่ง คุณต้องพิจารณาการใช้งานหลากหลายแบบหนึ่งต่อหลายและแม้กระทั่งหลายต่อหลาย เพื่อสำรวจความแตกต่างเหล่านี้อย่างค่อยเป็นค่อยไป:
- หนึ่ง IdP Org กับหลายโดเมนอีเมล: หากคุณพึ่งพาโดเมนอีเมลในการระบุตัวตนผู้ใช้ คุณต้องรองรับการเชื่อมโดเมนหลายโดเมน
- หนึ่งโดเมนอีเมลสอดคล้องกับ IdP Org หลายตัว: หากโดเมนอาจเป็นของหลาย IdP Org ผู้ใช้ต้องเลือก IdP ที่ต้องการสำหรับ single sign-on
- หนึ่ง IdP Org เชื่อมโยงกับ SP Org หลายตัว: พิจารณาการให้ความสามารถในการเชื่อมต่อ IdP หนึ่งตัวกับ SP Org หลายตัวอย่างรวดเร็ว
- บัญชีผู้ใช้หนึ่งตัวในหลาย IdP Org และ SP Org: SP Org ต่าง ๆ อาจต้องยืนยันผ่าน IdP ต่าง ๆ
การเปิดหรือปิดใช้ SSO ในองค์กรอาจเปลี่ยนวิธีการยืนยันตัวตนของผู้ใช้ จำเป็นต้องมีการเปลี่ยนผ่านที่ปลอดภัยและราบรื่น
- การตัดสินใจสำหรับการเปิดใช้งาน SSO: จำเป็นต้องมีการตัดสินใจว่า SSO มีผลต่อ SP Org ผู้เช่าเฉพาะบางตัวหรือ SP Org ผู้เช่าทั้งหมด อดีตเสนอยืดหยุ่นในขณะที่หลังสอดคล้องกับแนวโน้มของการควบคุมอัตลักษณะและการเข้าถึงทั่วทั้งองค์กร
- พิจารณาระยะเวลาการเปลี่ยนผ่าน: ในฐานะ SP คุณต้องรองรับความไม่แน่นอนของบริการ IdP บุคคลที่สาม ผู้ดูแลระบบองค์กรต้องเข้าถึงแอปของคุณเสมอด้วย SSO หรือข้อมูลรับรองเป็นทางเลือก และสมาชิกองค์กรอาจจำเป็นต้องใช้ในระหว่างการเปลี่ยนผ่าน
นี่เป็นเพียงบางจุดที่สามารถแก้ไขได้ในสถานการณ์ต่าง ๆ ยังมีความสามารถและรายละเอียดอื่น ๆ อีกมากที่สามารถสำรวจได้
บทสรุป#
เราหวังว่าการวิเคราะห์ SP-initiated SSO นี้จะเสนอมุมมองใหม่ ๆ เกี่ยวกับโซลูชันอัตลักษณ์องค์กร ข่าวดีคือ Logto กำลังพัฒนาโซลูชันอย่างตั้งใจที่เสน่อตัวเลือกการตั้งค่าที่ง่ายและประสบการณ์การยืนยันตัวตน SSO สำเร็จรูป โปรดติดตามการเปิดตัวครั้งถัดไปของเรา ที่เราจะสำรวจโซลูชัน SP-initiated SSO ที่เฉพาะเจาะจงมากขึ้น
