ทางเลือกอื่นๆ ในการทำ Single Sign On สำหรับ G Suite

สำหรับองค์กรที่มีการใช้งาน application มากกว่า 1 ระบบ หากผู้ใช้จำเป็นต้องจดจำ username และ password สำหรับแต่ละระบบ อาจจะเป็นภาระในฝั่งผู้ใช้งาน หากผู้ใช้ต้องจำ username และ password จำนวนมากจนไม่สามารถจดจำได้ มักจะมีพฤติกรรมในการบันทึก username และ password ลงกระดาษ หรือไฟล์ที่ไม่มีการเข้ารหัส ทำให้มีความเสี่ยงด้านความปลอดภัยของระบบ

ภาพจาก: smartertechnologies

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

แนวคิดของ Single Sing On จึงเกิดขึ้นมาเพื่อแก้ไขปัญหาเหล่านี้ โดยอำนวยความสะดวก ให้ผู้ใช้งาน สามารถใช้ Identity เพียงชุดเดียว ก็สามารถเข้าถึงระบบต่างๆ ในองค์กรได้ ตามแต่จะจัดสรรไว้ เมื่อไม่ต้องจำ password เยอะ ผู้ใช้จะสามารถสร้าง password ที่แข็งแรงขึ้นมา และจดจำไปใช้งานได้ โดยไม่ต้องจดใส่กระดาษหรือไฟล์เอกสาร ส่งผลให้บัญชีผู้ใช้นั้นปลอดภัยมากยิ่งขึ้นไปด้วย ส่วนในมุมของผู้ดูแลระบบ การสร้าง ลบ หรือ reset password ที่จุดเดียว ก็จะมีผลกับระบบทั้งหมดด้วยเช่นกัน เป็นการลดภาระทั้งในมุมของผู้ใช้งาน และผู้ดูแลระบบในคราวเดียว

ภาพจาก: kissflow

สำหรับองค์กรที่ใช้งาน G Suite อยู่นั้น มีแนวทางที่ใกล้เคียงกับ Single Sign On นั่นก็คือ Single Password โดยเราจะออกแบบให้ระบบต่างๆ ในองค์กร ให้ใช้งาน username และ password เดียวกันทั้งระบบ โดยส่วนประกอบสำคัญก็จะมี AD , G Suite และ G Suite Password Sync

หากต้องการทำระบบ Single Password เราจำเป็นต้องวางแนวทางของ application ที่ใช้งานทั้งหมดในองค์กร ให้มีวิธีการยืนยันตัวตนผู้ใช้งาน ออกเป็น 2 ประเภทคือ

  1. application ที่ยืนยันตัวตนด้วย LDAP ซึ่งมักจะเป็น application ที่เขียนและใช้งานภายในองค์กร
  2. application ที่ยืนยันตัวตนด้วย OAuth หรือ SAML
โดยแอพพลิเคชั่นประเภทแรก จะยืนยันตัวตนผู้ใช้งานด้วย AD เช่น ระบบ WiFi ภายในองค์กร หรือ application ที่พัฒนาขึ้นมาภายใน ซึ่ง application กลุ่มนี้ก็จะใช้ username/password ชุดเดียวกับ AD

สำหรับ application กลุ่มที่ 2 เช่น web app ที่พัฒนาขึ้นมาใหม่ หรือ SaaS ตัวอื่นๆ ก็ให้มายืนยันตัวตนด้วย G Suite ดังนั้น application กลุ่มนี้ก็จะใช้ username/password ชุดเดียวกับ G Suite

ส่วนประกอบสำคัญตัวสุดท้าย คือ G Suite Password Sync ที่จะคอย update password จาก AD ไปยัง G Suite ให้ตรงกันเสมอ เป็นสะพานเชื่อมระหว่าง Identity platform ทั้ง 2 ตัว และทำให้ application จากทั้ง 2 กลุ่ม ใช้ username/password ชุดเดียวกันได้


หากเราวางกรอบในการพัฒนาหรือการจัดหา application ไว้ โดยพยายามให้ application ทั้งหมด สามารถใช้งานยืนยันตัวตนจาก Identity platform ที่เรามีอยู่ได้ (application จะต้องยืนยันตัวตนผู้ใช้งานด้วย AD หรือด้วย G Suite ได้) ก็จะช่วยให้การจัดการ Identity ขององค์กร เรียบง่ายและบริหารจัดการได้สะดวกมากยิ่งขึ้น

หากองค์กรของคุณ ใช้งาน G Suite อยู่ และต้องการทำ Single password จาก AD สามารถติดต่อได้ที่ tangerine ครับ

ความคิดเห็น

โพสต์ยอดนิยมจากบล็อกนี้

การเรียกใช้งาน Google Apps Script

ป้องกันอีเมลสวมรอย (Email spoofing) ด้วย SPF, DKIM และ DMARC

การเขียน Google Apps Script เพื่อใช้งาน Custom Function