Single Sign-On (SSO) SAML ทำให้การยืนยันตัวตนระหว่างระบบไอดีของธุรกิจเป็นไปอย่างปลอดภัยและเป็นมิตร คู่มือฉบับนี้จะช่วยให้นักพัฒนาและนักออกแบบเข้าใจ SAML ได้ง่ายขึ้น ด้วยขั้นตอนที่ชัดเจนและตัวอย่างการใช้งานจริง เพื่อให้คุณนำไปใช้ได้อย่างมีประสิทธิภาพ
SAML authentication และแอป SAML คืออะไร? # Security Assertion Markup Language (SAML) Identity Provider (IdP) และ Service Provider (SP) โดยมักถูกใช้สำหรับ Single Sign-On (SSO) ในองค์กร ให้ผู้ใช้ลงชื่อเข้าใช้เพียงครั้งเดียว เข้าถึงแอปหลายตัวได้อย่างง่ายดาย
Identity Provider (IdP)
ตัวอย่าง: สมมติว่าคุณทำงานในบริษัทใหญ่ที่ใช้ Microsoft Azure AD ในการจัดการบัญชีพนักงาน เมื่อต้องการล็อกอินเข้า Salesforce, Azure AD จะทำหน้าที่เป็น IdP ตรวจสอบข้อมูลของคุณและแจ้ง Salesforce ว่าคุณได้รับอนุญาตให้ใช้งาน
Service Provider (SP)
ตัวอย่าง: ต่อเนื่องจากตัวอย่างด้านบน Salesforce ก็คือ SP ที่อาศัย Microsoft Azure AD (เป็น IdP) เพื่อยืนยันตัวตนให้ เมื่อ Azure AD รับรองตัวตนให้ Salesforce ก็ให้คุณเข้าใช้ได้
เวลาได้ยินคำว่า “SAML app ” มักจะหมายถึงตัว SP
ด้วยโปรโตคอลของ SAML คุณสามารถเซอร์วิสของคุณให้เป็น IdP เพื่อรับรองการเชื่อมต่อกับแอปอื่น (อย่าง Azure AD / Google Workspace) หรือเซ็ตเป็น SP (เช่น Salesforce / Slack) เพื่อรองรับ SSO ให้กับผู้ใช้
SAML Assertion คือหัวใจของโปรโตคอล SAML เป็น “โน้ต” ดิจิทัลที่ถูกสร้างขึ้นโดย IdP และส่งไปหา SP ระบุว่า “ฉันได้ยืนยันตัวตนผู้ใช้นี้แล้ว” ต่อไปจะอธิบายขั้นตอนการทำงานทั้งฝั่ง IdP และ SP
การเป็น SAML Identity Provider # เมื่อตัวเซอร์วิสของคุณทำหน้าที่เป็น IdP จะช่วยให้ยืนยันตัวตนแบบ SAML กับหลายแอปได้ ทำให้ผู้ใช้เข้าถึงบริการหลายอย่างได้ด้วยบัญชีเดียว
นี่คือลำดับการทำงาน SAML SSO ปกติของ IdP:
ผู้ใช้พยายามเข้าถึงแอปพลิเคชัน (SP) เช่น Salesforce
แอปจะ redirect ผู้ใช้ไปยัง IdP สำหรับการยืนยันตัวตน
ผู้ใช้กรอกข้อมูลล็อกอินในหน้าล็อกอินของ IdP
IdP ตรวจสอบข้อมูลล็อกอิน
หากล็อกอินสำเร็จ IdP จะส่ง SAML assertion กลับไปหา SP
SP จะตรวจสอบ assertion, ตรวจสอบความถูกต้อง และอนุญาตให้ผู้ใช้เข้าใช้งาน
การเป็น SAML Service Provider # ถ้าเซอร์วิสของคุณเป็น SP จะผสานกับ Identity Provider หลายเจ้า เพื่อให้ผู้ใช้มีความสามารถ SSO องค์กรต่าง ๆ หรือ tenant หลายแห่ง สามารถเข้าถึงแอปของคุณอย่างปลอดภัยและรวดเร็ว
นี่คือลำดับงานของ SSO ที่ริเริ่มจาก SP:
ผู้ใช้พยายามลงชื่อเข้าใช้แอปของคุณ
แอปของคุณสร้าง SAML request และ redirect ผู้ใช้ไปหน้าล็อกอินของ IdP
ผู้ใช้ลงชื่อเข้าใช้ที่ IdP (หากลงชื่อเข้าใช้แล้วก็ข้ามขั้นตอน)
IdP ยืนยันตัวตน หลังจากยืนยันแล้วจะรวมรายละเอียดผู้ใช้ลงใน SAML assertion
IdP ส่ง assertion กลับไปที่แอปของคุณ
บริการของคุณตรวจสอบ assertion หากถูกต้องให้ผู้ใช้ใช้งานแอปคุณได้
ค่าพารามิเตอร์หลักใน SAML SSO#
สำหรับการผสาน SAML SSO ที่สำเร็จ ทั้ง IdP และ SP ต้องแบ่งปันค่าพารามิเตอร์บางอย่าง ต่อไปนี้คือหัวใจสำคัญ:
ค่าพารามิเตอร์จากฝั่ง IdP#
IdP Entity ID: ตัวระบุเฉพาะของ IdP ในการสื่อสารผ่าน SAML เปรียบเหมือนป้ายชื่อดิจิทัลSSO URL: จุด login (URL) ที่ SP จะ redirect ผู้ใช้ไปเพื่อยืนยันตัวตนX.509 Certificate: public key สำหรับเซ็นชื่อ SAML assertion เพื่อรับรองความปลอดภัย เป็นเหมือน “ตราประทับ” รับรองความถูกต้อง
เคล็ดลับ: หาก IdP ของคุณมี SAML Metadata URL จะง่ายขึ้นเยอะ เพราะ URL นี้จะมีข้อมูลสำคัญทุกอย่าง (เช่น certificate, SSO URL, และ IdP Entity ID) อยู่ในที่เดียว ลดความผิดพลาดเวลาคัดลอกข้อมูล และไม่ต้องอัปเดต certificate ไฟล์เองบ่อย ๆ
ค่าพารามิเตอร์จากฝั่ง SP#
SP Entity ID: ตัวระบุเฉพาะของ SP คล้ายกับ IdP Entity IDAssertion Consumer Service (ACS) URL: endpoint ของ SP ที่ SP รอรับ SAML assertion จาก IdPRelayState (ไม่บังคับ): ใช้สำหรับส่งข้อมูลขณะทำงานกับ SAML เช่น URL ที่ผู้ใช้ตั้งใจจะเข้าตั้งแต่ต้น
การจับคู่ attributes ใน SAML และการเข้ารหัส#
NameID Format: รูปแบบตัวระบุผู้ใช้ (เช่น email address หรือ username)SAML Attributes: ข้อมูลผู้ใช้เพิ่มเติม เช่น บทบาท อีเมล หรือแผนก ซึ่ง IdP ส่งให้กับ SP
ตัวอย่าง: สมมติ SAML assertion ที่ IdP เซ็นประกอบด้วย email ([email protected] role (admin), และ department (engineering) โดย SP สามารถใช้ role กำหนดสิทธิ admin หรือ department จัดกลุ่มผู้ใช้ในทีมให้เหมาะสม การจะได้ข้อมูลสำคัญนี้ IdP และ SP ต้องตกลงวิธี map attribute เช่น IdP อาจตั้ง “department” เป็น team แต่ SP ต้องการในชื่อ group การ mapping ที่ถูกต้องจะช่วยให้ระบบสื่อสารกันลื่นไหล
Encrypted Assertions (ไม่บังคับ): ปกป้องข้อมูลยืนยันตัวตนที่สำคัญ SAML assertion สามารถถูกเข้ารหัสได้
IdP: เข้ารหัส assertion ด้วย public key ของ SPSP: ถอดรหัส assertion ด้วย private key ตัวเองเพื่ออ่านข้อมูลผู้ใช้
ตอนนี้คุณควรพร้อมแล้วสำหรับการตั้งค่าเชื่อมต่อ SAML หากจะเชื่อมต่อ Salesforce (Service Provider) กับ Azure AD (Identity Provider) ให้ทำตามนี้:
ดึง IdP Entity ID, SSO URL และ certificate จาก Azure AD แล้วกำหนดลงใน Salesforce
ให้ Salesforce’s SP Entity ID และ ACS URL กับ Azure AD ด้วย
Logto ทำให้ SAML integration เป็นเรื่องง่าย # Logto สามารถเป็น IdP หรือ SP ก็ได้เพื่อรองรับ SAML SSO ให้กับแอปของคุณ
ใช้ Logto เป็น SAML IdP # Logto ให้แอปอื่นอาศัยยืนยันตัวตนแบบ federated ได้ พร้อมรองรับ multi-factor authentication (MFA)
สร้าง Logto App
ไปที่ Logto Console > Applications กำหนดค่า SAML Parameters
ตั้งค่าแอปด้วย Assertion Consumer Service URL และ SP Entity ID ของ Service Provider (SP)แจ้ง metadata URL
Logto จะให้ IdP Metadata URL ที่ SP ใช้ดึงข้อมูลสำคัญเช่น SSO URL และ certificate อัตโนมัติกำหนดค่าขั้นสูง (ไม่บังคับ)
สร้าง certificate ใหม่ หลายใบได้ (พร้อม fingerprint ระบุวันหมดอายุ) แต่เปิดใช้งานทีละใบเท่านั้น
ปรับรูปแบบ Name ID ให้ตรงกับธุรกิจของคุณ
เปิดใช้ การเข้ารหัส assertion SAML โดยใช้ x509 certificate จาก Service Provider ของคุณเพื่อเข้ารหัส assertion
จัดการ Map Attribute (ไม่บังคับ)
ตั้งค่าได้ง่าย ๆ ว่าจะให้ Logto แชร์ข้อมูล attribute ของผู้ใช้กับ Service Provider (SP) อย่างไร
ดูคำแนะนำฉบับเต็มได้ที่: SAML App
ใช้ Logto เป็น SAML SP # Logto ผสานกับ enterprise IdP ใดก็ได้ ผ่าน SAML หรือ OIDC ไม่ว่าคุณจะตั้งค่า SSO จาก SP หรือ IdP กระบวนการก็ทำง่าย
สร้าง enterprise connector
ไปที่ Logto Console > Enterprise SSO กำหนด SAML parameters
ให้ metadata URL หรือ metadata XML file จาก IdP ของคุณ ถ้าไม่มี metadata เปลี่ยนไปทำ manual ใส่ IdP Entity ID, SSO URL และอัปโหลด Signing certificate ด้วยตัวเองแชร์ ACS URL และ SP Entity ID
แจ้ง ACS URL และ SP Entity ID ของ Logto ให้ IdP ของคุณ เพื่อจบการเชื่อมต่อจัดการ map attribute (ไม่บังคับ)
ตั้งค่าการจับคู่ข้อมูลผู้ใช้ เช่น email หรือชื่อ ให้ถูกต้องระหว่าง IdP และ Logtoเพิ่มโดเมนอีเมลขององค์กร
ในแท็บ “SSO Experience” สำหรับ enterprise connector, เพิ่มโดเมน email หนึ่งหรือมากกว่านั้น เพื่อให้เฉพาะผู้ใช้ที่มีโดเมนตรงนี้เท่านั้นที่ authenticate ผ่าน SSO ได้เปิดใช้ IdP-initiated SSO (ไม่บังคับ)
เปิดใช้ IdP-initiated SSO หากลูกค้าองค์กรของคุณต้องการ ให้ผู้ใช้ล็อกอินที่แอปของคุณผ่าน IdP dashboard ได้โดยตรง
ดูคำแนะนำฉบับเต็มที่นี่: Enterprise SSO documentation
สรุปส่งท้าย#
SAML เป็นมาตรฐานที่ปลอดภัยสำหรับ SSO ช่วยให้การยืนยันตัวตนเป็นเรื่องง่าย ไม่ว่าคุณตั้งค่าเป็น IdP หรือ SP Logto cloud open-source
