ทุกการเข้าสู่ระบบที่แยกกันคือรหัสผ่านอีกชุดที่ต้องรีเซ็ต และบัญชีอีกบัญชีที่ต้องปิดเมื่อมีคนลาออก Single Sign-On (SSO) แบบ SAML เชื่อมระบบจัดการการเรียนรู้ (LMS) ของคุณกับผู้ให้บริการยืนยันตัวตน (identity provider) เพื่อให้ผู้คนเข้าสู่ระบบอบรมด้วยบัญชีที่ทำงานของตน และสิทธิ์เข้าถึงเป็นไปตามไดเรกทอรีของคุณ ต่อไปนี้คือวิธีการทำงานของ SAML ขั้นตอนการตั้งค่ากับ Microsoft Entra ID, Okta หรือ Google Workspace และสิ่งที่ควรตรวจสอบก่อนเปิดใช้งานจริง
SAML Single Sign-On ทำงานอย่างไร
SAML (Security Assertion Markup Language) 2.0 คือมาตรฐานเปิดสำหรับส่งข้อมูลการเข้าสู่ระบบระหว่างสองระบบที่ไว้วางใจกัน LMS ไม่เห็นรหัสผ่านของผู้ใช้เลย: แต่จะส่งผู้ใช้ไปยัง identity provider ของคุณ ซึ่งตรวจสอบว่าเป็นใคร รวมถึงการยืนยันตัวตนหลายปัจจัยที่คุณกำหนด แล้วส่งผู้ใช้กลับมาพร้อมข้อความยืนยันที่ลงนามแล้ว
| คำศัพท์ | ความหมาย |
|---|---|
| ผู้ให้บริการยืนยันตัวตน (Identity provider, IdP) | ระบบที่ยืนยันตัวตนของบุคลากรของคุณ เช่น Entra ID, Okta หรือ Google Workspace |
| ผู้ให้บริการแอปพลิเคชัน (Service provider, SP) | แอปพลิเคชันที่ผู้คนเข้าสู่ระบบ ในที่นี้คือ LMS ของคุณ |
| Assertion | ข้อความ XML ที่ลงนามแล้วจาก IdP: ระบุว่าผู้ใช้เป็นใคร เข้าสู่ระบบเมื่อใด และแอตทริบิวต์ต่างๆ เช่น อีเมลและชื่อ |
| Entity ID | ชื่อเฉพาะของแต่ละฝ่าย มักมีรูปแบบคล้าย URL แต่เป็นเพียงตัวระบุ ต้องตรงกันทุกตัวอักษร |
| ACS URL | Assertion Consumer Service URL: ที่อยู่ของ LMS ที่รับการตอบกลับจาก IdP |
| ใบรับรองสำหรับลงนาม (Signing certificate) | IdP ลงนามด้วยคีย์ส่วนตัว ส่วน LMS ตรวจสอบด้วยใบรับรองสาธารณะของ IdP และปฏิเสธ assertion ที่ปลอมหรือถูกแก้ไข |
| Metadata | ไฟล์ XML ที่รวม entity ID, endpoint และใบรับรองไว้ พร้อมนำเข้า |
Assertion มีอายุสั้นและระบุผู้รับ (entity ID ของ SP) โดย SP จะปฏิเสธสิ่งที่หมดอายุแล้วหรือมีไว้สำหรับแอปพลิเคชันอื่น
ทำไม SSO จึงคุ้มค่าสำหรับ LMS
- ไม่มีรหัสผ่านเพิ่ม. ผู้ใช้ใช้บัญชีที่ใช้อยู่ทุกวัน และนโยบาย MFA กับนโยบายการเข้าถึงของคุณก็ครอบคลุมการอบรมด้วย
- ผู้เข้าใหม่เข้าถึงได้เร็ว. กำหนดแอปพลิเคชัน LMS ให้กลุ่ม แล้วพนักงานใหม่ในกลุ่มนั้นเข้าสู่ระบบได้ตั้งแต่วันแรก
- ผู้ที่ลาออกเสียสิทธิ์ที่ต้นทาง. ปิดการใช้งานบัญชีของใครในไดเรกทอรีของคุณ คนนั้นก็เริ่มเซสชัน LMS ใหม่ไม่ได้ SAML ควบคุมการเข้าสู่ระบบ ไม่ใช่ตัวบัญชี ดังนั้นควรเก็บถาวรบัญชี LMS เป็นส่วนหนึ่งของขั้นตอนเมื่อพนักงานลาออก (offboarding) ด้วย
การสร้างบัญชีแบบ just-in-time
ด้วยการสร้างบัญชีแบบ just-in-time (JIT) LMS จะสร้างบัญชีเมื่อมีคนเข้าสู่ระบบครั้งแรก จากแอตทริบิวต์ใน assertion จึงไม่ต้องนำเข้ารายชื่อผู้ใช้ ควรวางเงื่อนไขป้องกันไว้ดังนี้
- จำกัดเฉพาะโดเมนอีเมลของคุณเอง เพื่อไม่ให้แอปพลิเคชันที่ตั้งค่าผิดหรือบัญชีผู้เยี่ยมชมสร้างผู้ใช้ที่ไม่เกี่ยวข้อง
- ให้บัญชีใหม่มีบทบาทต่ำสุด และมอบสิทธิ์ผู้ดูแลระบบอย่างตั้งใจ
- จับคู่ผู้ใช้ด้วยตัวระบุที่คงที่ หาก IdP ของคุณส่งได้ เพราะที่อยู่อีเมลเปลี่ยนได้
การเข้าสู่ระบบแบบ SP-initiated กับ IdP-initiated
- SP-initiated: ผู้ใช้เปิด LMS ซึ่งส่งคำขอยืนยันตัวตนไปยัง IdP และ IdP ส่งการตอบกลับด้วย POST ไปยัง ACS URL ใช้ได้จากบุ๊กมาร์กและลิงก์ในอีเมล และโดยทั่วไปถือว่าเป็นขั้นตอนที่ปลอดภัยกว่า เพราะการตอบกลับเป็นคำตอบของคำขอที่ LMS สร้างขึ้น
- IdP-initiated: ผู้ใช้คลิกไทล์ของแอปพลิเคชันใน Microsoft My Apps แดชบอร์ด Okta ของตน หรือเมนูแอปของ Google แล้ว IdP ส่งการตอบกลับที่ไม่มีใครร้องขอไปยัง ACS URL
คุณเปิดให้ใช้ได้ทั้งสองแบบ แต่ต้องทดสอบทั้งสองแบบ
การตั้งค่า SAML SSO ทีละขั้น
ลำดับขั้นตอนคล้ายกันในทุกที่
- วางแผนขอบเขต: ใครใช้ SSO กลุ่มใดได้รับแอปพลิเคชัน โดเมนอีเมลใดได้รับอนุญาต และแอตทริบิวต์ใดระบุตัวตนของแต่ละคน
- สร้างการเชื่อมต่อใน LMS และจด entity ID กับ ACS URL ไว้
- สร้างแอปพลิเคชัน SAML ที่ IdP ของคุณ ด้วยค่าเหล่านั้น เลือกรูปแบบ NameID และเพิ่มแอตทริบิวต์อีเมล ชื่อ และนามสกุล
- กำหนดผู้ใช้หรือกลุ่ม ผู้ที่ไม่ได้รับมอบหมายมักถูกปฏิเสธ
- ให้รายละเอียดของ IdP แก่ LMS: URL ของ metadata ไฟล์ metadata หรือ entity ID ของ IdP, URL สำหรับเข้าสู่ระบบ และใบรับรองสำหรับลงนาม
- แมปแอตทริบิวต์ กับชื่อที่ IdP ของคุณส่งมาจริง
- ทดสอบ แล้วจึงเปิดใช้งาน และแจ้งผู้ใช้ว่ากำลังเปลี่ยนอะไร
หมายเหตุเฉพาะผู้ให้บริการ
เอกสารของผู้ให้บริการแต่ละรายมีหน้าจอที่แน่นอน สิ่งที่ควรรู้มีดังนี้
- Microsoft Entra ID: ใช้ enterprise application แบบ non-gallery ไม่ใช่ app registration ซึ่งไม่มีให้เลือก SAML ชื่อ claim เป็น URI ยาว จึงควรคัดลอกให้ตรงทุกตัวอักษร object ID เหมาะเป็นตัวระบุที่คงที่ สำหรับผู้ใช้ที่ไม่มีกล่องจดหมาย claim อีเมลอาจว่างเปล่า ใช้ user principal name แทนได้หากเป็นที่อยู่อีเมลจริง
- Okta: สร้าง SAML 2.0 app integration คุณตั้งชื่อ attribute statement เอง จึงต้องตรงกับการแมปของ LMS ทุกตัวอักษร รวมถึงตัวพิมพ์ใหญ่เล็ก user ID ภายในของ Okta เป็นตัวระบุที่คงที่
- Google Workspace: เพิ่มแอป SAML แบบกำหนดเอง แล้วดาวน์โหลดไฟล์ metadata ของแอป แอปเริ่มต้นในสถานะปิด จึงต้องเปิดให้หน่วยองค์กร (organisational unit) หรือกลุ่มที่ถูกต้อง การตั้งค่าโดยทั่วไประบุผู้ใช้ด้วยอีเมลหลัก ดังนั้นควรวางแผนรับมือกับที่อยู่ที่ถูกเปลี่ยนชื่อและถูกนำกลับมาใช้ซ้ำ
เช็กลิสต์การทดสอบ
ก่อนเปิดใช้งานจริง ให้ตรวจสอบสิ่งเหล่านี้ในหน้าต่างเบราว์เซอร์ส่วนตัว
- ผู้ใช้เดิมเข้าสู่ระบบโดยเริ่มจาก LMS และเข้าอีกครั้งจากไทล์ของแอป
- ผู้ใช้ใหม่ในโดเมนของคุณได้รับบัญชีพร้อมบทบาทที่ถูกต้อง
- ผู้ที่ไม่ได้รับมอบหมายให้ใช้แอปพลิเคชันถูกปฏิเสธ
- ผู้ที่อยู่นอกโดเมนที่อนุญาตของคุณถูกปฏิเสธ
- อีเมล ชื่อ และนามสกุลมาถึงถูกต้อง
- ผู้ดูแลระบบยังเข้าได้ผ่านเส้นทางกู้คืน
ข้อผิดพลาดที่พบบ่อย
นาฬิกาไม่ตรงกัน (Clock skew)
หากนาฬิกาของ IdP และ LMS ต่างกันเกินกว่าที่ LMS ยอมรับได้ assertion ที่ถูกต้องจะถูกปฏิเสธว่ายังไม่ถึงเวลาใช้งานหรือหมดอายุแล้ว ปัญหานี้ส่วนใหญ่กระทบเซิร์ฟเวอร์ยืนยันตัวตนที่โฮสต์เอง จึงควรซิงโครไนซ์นาฬิกาของเซิร์ฟเวอร์เหล่านั้น
การหมุนเวียนใบรับรอง (Certificate rollover)
ใบรับรองสำหรับลงนามของ IdP มีวันหมดอายุ และหาก LMS ไม่เชื่อถือใบรับรองใหม่ การเข้าสู่ระบบทุกครั้งจะล้มเหลวพร้อมกัน ให้จดวันหมดอายุลงปฏิทินไว้ หาก LMS ของคุณเชื่อถือใบรับรองได้สองใบ ให้เพิ่มใบใหม่ที่ LMS ก่อน แล้วจึงเปิดใช้งานที่ IdP มิฉะนั้นให้สลับทั้งสองฝั่งพร้อมกันในช่วงที่เงียบ แล้วทดสอบทันที
การแมปแอตทริบิวต์ (Attribute mapping)
ชื่อแอตทริบิวต์มักถูกจับคู่แบบตรงตัวทุกตัวอักษร: LMS ที่คาดหวัง email จะไม่ยอมรับ Email ตรวจสอบตัวระบุด้วย NameID แบบ transient เปลี่ยนทุกเซสชัน และที่อยู่อีเมลก็เปลี่ยนได้ ส่วน NameID แบบ persistent หรือแอตทริบิวต์ ID ที่ไม่เปลี่ยนแปลงนั้นคงที่ หากจับคู่ผู้ใช้ด้วยอีเมล ให้เก็บถาวรบัญชีของผู้ที่ลาออกก่อนที่ที่อยู่อีเมลของเขาจะถูกนำไปกำหนดให้คนอื่น
โดเมนอีเมลไม่ตรงกัน
ไดเรกทอรีมักมีผู้ที่ชื่อสำหรับเข้าสู่ระบบไม่ใช่ที่อยู่อีเมลของตน ผู้รับเหมาที่อยู่ในโดเมนอื่น และพนักงานของธุรกิจที่เข้าซื้อกิจการซึ่งยังใช้โดเมนเก่า หาก LMS จำกัดบัญชีไว้เฉพาะบางโดเมน คนเหล่านี้จะถูกปฏิเสธ จึงควรระบุโดเมนทั้งหมดก่อนเปิดใช้งานจริง
Acadenix ทำอย่างไร
SAML SSO มีในแพ็กเกจ Gold พร้อมคู่มือทีละขั้นสำหรับ Entra ID, Okta และ Google Workspace
- ทดสอบ แล้วเปิดใช้งาน. คุณบันทึกรายละเอียดของ IdP เป็นฉบับร่าง รัน Test configuration (ทดสอบการตั้งค่า) โดยเข้าสู่ระบบที่ผู้ให้บริการของคุณ แล้วจึงเปิดใช้งาน หากไม่มี claim อีเมล ระบบจะรายงานพร้อมชื่อ claim ที่ผู้ให้บริการของคุณส่งมาจริง
- การเปลี่ยนแปลงแบบเป็นขั้น. ใบรับรองหรือ tenant ใหม่จะเข้ามาเป็นการอัปเดตการตั้งค่า และการตั้งค่าปัจจุบันยังทำงานต่อไปจนกว่าคุณจะเปิดใช้งาน
- JIT ภายในโดเมนของคุณ. ผู้ที่ไม่มีบัญชีจะได้บัญชีผู้เรียนเมื่อเข้าสู่ระบบครั้งแรก เฉพาะเมื่ออีเมลอยู่ในโดเมนลงทะเบียนขององค์กรคุณ และคุณปิดฟีเจอร์นี้ได้ เมื่อผู้ที่มีบัญชี Acadenix อยู่แล้วเข้าสู่ระบบผ่าน IdP ของคุณเป็นครั้งแรก Acadenix จะส่งรหัสแบบใช้ครั้งเดียวทางอีเมลเพื่อยืนยันการเชื่อมโยง ซึ่งเกิดขึ้นครั้งเดียวต่อคน
- เข้าได้ทั้งสองทาง. ผู้ใช้เริ่มจากหน้าเข้าสู่ระบบของคุณ ซึ่งพาไปยัง IdP ของคุณโดยตรงหรือแสดงเป็นปุ่ม หรือเริ่มจากไทล์ใน My Apps, Okta หรือ Google
- หนึ่งการเชื่อมต่อ หนึ่งองค์กร. การเชื่อมต่อ SAML ไม่ส่งต่อลงไปยังองค์กรที่อยู่ใต้เจ้าของ ซึ่งสำคัญสำหรับกลุ่มที่มีหลายไซต์งาน
- เส้นทางกู้คืน. หาก IdP ของคุณล่ม ผู้ดูแลระบบยังเข้าสู่ระบบด้วยรหัสแบบใช้ครั้งเดียวที่ส่งทางอีเมลได้ และปิดเส้นทางนี้ไม่ได้
นอกจาก SAML แล้ว ผู้ใช้ยังเข้าสู่ระบบด้วยรหัสทางอีเมลหรือบัญชี Google, Microsoft หรือ LinkedIn ได้ ดูเพิ่มเติมที่หน้าความปลอดภัยของเรา
ประเด็นสำคัญ
- แลกเปลี่ยน entity ID, ACS URL และ metadata แล้วแมปตัวระบุที่คงที่และอีเมลที่ยืนยันแล้ว
- จำกัดบัญชี just-in-time ไว้เฉพาะโดเมนของคุณเองและบทบาทต่ำสุด
- ทดสอบทั้งสองรูปแบบการเข้าสู่ระบบ กรณีที่ถูกปฏิเสธ และเส้นทางกู้คืนก่อนเปิดใช้งานจริง
- จดวันหมดอายุของใบรับรองลงปฏิทิน และเก็บถาวรบัญชี LMS ของผู้ที่ลาออก
อยากเชื่อมต่อ Acadenix กับผู้ให้บริการยืนยันตัวตนของคุณ? เปรียบเทียบแพ็กเกจได้ที่หน้าราคาของเรา หรือพูดคุยกับเราเกี่ยวกับการตั้งค่าของคุณ
