การลงชื่อเพียงครั้งเดียว (SSO) ช่วยให้ผู้ใช้ลงชื่อเข้าใช้แอปพลิเคชันระบบคลาวด์ในองค์กรหลายแอปพลิเคชันได้โดยใช้ข้อมูลเข้าสู่ระบบชุดเดียว Workspace (และ Google Cloud Platform) รองรับ SSO จากผู้ให้บริการข้อมูลประจำตัว (IdP) บุคคลที่สาม
Workspace รองรับโปรโตคอล SSO ทั้งแบบ SAML และ OIDC SSO ของ SAML รองรับ IdP ใดก็ได้ ปัจจุบัน OIDC รองรับเฉพาะ Microsoft Entra ID เท่านั้น
หากต้องการใช้ SSO คุณต้องกำหนดค่าโปรไฟล์ SSO แล้วมอบหมายให้กับกลุ่มผู้ใช้หรือหน่วยขององค์กร ซึ่งจะช่วยให้รองรับ IdP หลายรายการและทดสอบการกำหนดค่า SSO ได้ ระบบนี้แนะนำสำหรับ SSO นอกจากนี้ เรายังมีโปรไฟล์ SSO เดิมสำหรับองค์กร (สำหรับ SAML เท่านั้น)
อุปกรณ์ Chrome ก็ใช้งาน SSO ได้เช่นกัน โปรดดูรายละเอียดที่หัวข้อกำหนดค่าการลงชื่อเพียงครั้งเดียวด้วย SAML สำหรับอุปกรณ์ Chrome
การยืนยันเพิ่มเติมหลังใช้ SSOเมื่อตั้งค่า SSO แล้ว ผู้ใช้ที่ลงชื่อเข้าใช้ IdP บุคคลที่สามจะเข้าถึงแอป Google ได้โดยไม่ต้องมีการยืนยันเพิ่มเติม โดยมีข้อยกเว้นดังนี้
- แม้ว่าผู้ใช้จะลงชื่อเข้าใช้ IdP อยู่แล้ว บางครั้ง Google จะขอให้ยืนยันตัวตนเนื่องจากเป็นมาตรการรักษาความปลอดภัยเพิ่มเติม โปรดดูข้อมูลเพิ่มเติม (และรายละเอียดวิธีปิดใช้การยืนยันนี้ในกรณีจำเป็น) ที่หัวข้อทำความเข้าใจกับการลงชื่อเข้าใช้อย่างปลอดภัยด้วย SAML
- คุณจะตั้งค่าการยืนยันแบบ 2 ขั้นตอนเพิ่มเติมสำหรับผู้ใช้ที่เข้าถึงบริการของ Google ได้ โดยปกติแล้วระบบจะข้ามการยืนยันแบบ 2 ขั้นตอนเมื่อเปิดใช้งาน SSO โปรดดูข้อมูลเพิ่มเติมที่หัวข้อเปิดการยืนยันตัวตนด้วย SSO
รูปที่ 1 แสดงขั้นตอนที่ผู้ใช้ลงชื่อเข้าใช้แอปพลิเคชัน Google เช่น Gmail ผ่านบริการ SSO ที่ใช้ SAML ซึ่งดำเนินการโดยพาร์ทเนอร์ ส่วนรายการที่เรียงลำดับเลขใต้ภาพนั้นจะอธิบายรายละเอียดของแต่ละขั้นตอน
สำคัญ: ก่อนกระบวนการนี้จะเริ่มขึ้น พาร์ทเนอร์จะต้องให้ URL สำหรับบริการ SSO ของตนแก่ Google รวมทั้งคีย์สาธารณะที่ Google ควรใช้เพื่อยืนยันการตอบสนอง SAML
รูปที่ 1: แสดงขั้นตอนการลงชื่อเข้าใช้ Google โดยใช้บริการ SSO แบบ SAML
ภาพนี้แสดงขั้นตอนดังนี้
- ผู้ใช้พยายามเข้าถึงแอปพลิเคชัน Google ที่โฮสต์ เช่น Gmail, Google ปฏิทิน หรือบริการอื่นๆ ของ Google
- Google สร้างคำขอการตรวจสอบสิทธิ์ SAML ซึ่งได้รับการเข้ารหัสและฝังลงใน URL สำหรับบริการ SSO ของพาร์ทเนอร์ พารามิเตอร์ RelayState ที่ประกอบด้วย URL ที่เข้ารหัสของแอปพลิเคชัน Google ที่ผู้ใช้พยายามเข้าถึงจะฝังลงใน URL ของ SSO ด้วยเช่นกัน พารามิเตอร์ RelayState นี้เป็นตัวระบุแบบทึบที่ส่งกลับไปโดยไม่มีการแก้ไขหรือตรวจสอบ
- Google ส่งการเปลี่ยนเส้นทางไปยังเบราว์เซอร์ของผู้ใช้ URL การเปลี่ยนเส้นทางนี้จะรวมคำขอการตรวจสอบสิทธิ์ SAML ที่เข้ารหัสไว้ซึ่งควรส่งไปให้บริการ SSO ของพาร์ทเนอร์
- เบราว์เซอร์จะเปลี่ยนเส้นทางไปยัง URL ของ SSO
- พาร์ทเนอร์ถอดรหัสคำขอ SAML และแยกข้อมูล URL สำหรับทั้ง ACS (Assertion Consumer Service) ของ Google และ URL ปลายทาง (พารามิเตอร์ RelayState) ของผู้ใช้
- จากนั้นพาร์ทเนอร์จะตรวจสอบสิทธิ์ของผู้ใช้ โดยสามารถดำเนินการโดยขอข้อมูลเข้าสู่ระบบที่ถูกต้องหรือตรวจสอบคุกกี้เซสชันที่ยังใช้งานได้
- พาร์ทเนอร์สร้างการตอบสนอง SAML ที่มีชื่อผู้ใช้ของผู้ใช้ที่ตรวจสอบสิทธิ์แล้ว ตามข้อกำหนดของ SAML v2.0 คำตอบนี้จะได้รับการลงนามแบบดิจิทัลด้วยคีย์สาธารณะและคีย์ DSA/RSA ส่วนตัวของพาร์ทเนอร์
- พาร์ทเนอร์เข้ารหัสการตอบสนอง SAML และพารามิเตอร์ RelayState แล้วส่งข้อมูลกลับไปที่เบราว์เซอร์ของผู้ใช้ พาร์ทเนอร์มีกลไกที่ให้เบราว์เซอร์ส่งต่อข้อมูลไปยัง ACS ของ Google ได้ เช่น พาร์ทเนอร์อาจฝังการตอบสนอง SAML และ URL ปลายทางในแบบฟอร์มและมีปุ่มที่ให้ผู้ใช้คลิกเพื่อส่งแบบฟอร์มมายัง Google นอกจากนี้ พาร์ทเนอร์ยังอาจรวม JacaScript ในหน้าที่ส่งแบบฟอร์มมายัง Google อีกด้วย
- เบราว์เซอร์จะส่งคำตอบกลับไปยัง ACS URL ACS ของ Google ยืนยันการตอบสนอง SAML โดยใช้คีย์สาธารณะของพาร์ทเนอร์ หากคำตอบได้รับการยืนยันเรียบร้อยแล้ว ACS จะเปลี่ยนเส้นทางผู้ใช้ไปยัง URL ปลายทาง
- ผู้ใช้ลงชื่อเข้าใช้แอป Google
การซิงค์บัญชีผู้ใช้ระหว่าง IdP กับ Google
องค์กรส่วนใหญ่ที่ใช้ SSO จะซิงค์ไดเรกทอรีผู้ใช้จาก IdP กับ Google ด้วยเพื่อให้การจัดการวงจรของผู้ใช้ง่ายขึ้น เมื่อมีการซิงค์ ระบบจะเพิ่มหรือลบผู้ใช้ใหม่ (หรือที่ลบไปแล้ว) ทางด้าน IdP เป็นผู้ใช้ Workspace โดยอัตโนมัติ Directory Sync ของ Google รองรับ Active Directory และ Entra ID IdP ส่วนใหญ่รองรับการซิงค์กับ Google โปรดดูวิธีการตั้งค่าในเอกสารประกอบของ IdP
SSO และ LDAP ที่ปลอดภัย
LDAP ที่ปลอดภัยต้องใช้รหัสผ่าน Google และใช้กับ SSO ไม่ได้