ทำให้การผสานการยืนยันตัวตน SAML สำหรับนักพัฒนาเป็นเรื่องง่าย

Single Sign-On (SSO) คือหัวใจของแอปยุคใหม่ และ SAML ทำให้การยืนยันตัวตนระหว่างระบบไอดีของธุรกิจเป็นไปอย่างปลอดภัยและเป็นมิตร คู่มือฉบับนี้จะช่วยให้นักพัฒนาและนักออกแบบเข้าใจ SAML ได้ง่ายขึ้น ด้วยขั้นตอนที่ชัดเจนและตัวอย่างการใช้งานจริง เพื่อให้คุณนำไปใช้ได้อย่างมีประสิทธิภาพ

SAML authentication และแอป SAML คืออะไร?#

Security Assertion Markup Language (SAML) คือมาตรฐานที่ใช้ XML สำหรับแลกเปลี่ยนข้อมูลการยืนยันตัวตนและการอนุญาตระหว่างสองตัวหลักคือ Identity Provider (IdP) และ Service Provider (SP) โดยมักถูกใช้สำหรับ Single Sign-On (SSO) ในองค์กร ให้ผู้ใช้ลงชื่อเข้าใช้เพียงครั้งเดียว เข้าถึงแอปหลายตัวได้อย่างง่ายดาย

Identity Provider (IdP) คือผู้จัดการและตรวจสอบข้อมูลบัญชีผู้ใช้ เช่นชื่อผู้ใช้และรหัสผ่าน เมื่อผู้ใช้พยายามเข้าถึงบริการที่มีการป้องกัน IdP จะยืนยันตัวตนและส่งผลยืนยันนั้นไปยังบริการเป้าหมาย

• ตัวอย่าง: สมมติว่าคุณทำงานในบริษัทใหญ่ที่ใช้ Microsoft Azure AD ในการจัดการบัญชีพนักงาน เมื่อต้องการล็อกอินเข้า Salesforce, Azure AD จะทำหน้าที่เป็น IdP ตรวจสอบข้อมูลของคุณและแจ้ง Salesforce ว่าคุณได้รับอนุญาตให้ใช้งาน

Service Provider (SP) คือแอปหรือบริการที่ผู้ใช้ต้องการเข้าถึงจริงๆ โดยจะพึ่งพา IdP ในด้านการยืนยันตัวตน

• ตัวอย่าง: ต่อเนื่องจากตัวอย่างด้านบน 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:

1. ผู้ใช้พยายามเข้าถึงแอปพลิเคชัน (SP) เช่น Salesforce
2. แอปจะ redirect ผู้ใช้ไปยัง IdP สำหรับการยืนยันตัวตน
3. ผู้ใช้กรอกข้อมูลล็อกอินในหน้าล็อกอินของ IdP
4. IdP ตรวจสอบข้อมูลล็อกอิน
5. หากล็อกอินสำเร็จ IdP จะส่ง SAML assertion กลับไปหา SP
6. SP จะตรวจสอบ assertion, ตรวจสอบความถูกต้อง และอนุญาตให้ผู้ใช้เข้าใช้งาน

การเป็น SAML Service Provider#

ถ้าเซอร์วิสของคุณเป็น SP จะผสานกับ Identity Provider หลายเจ้า เพื่อให้ผู้ใช้มีความสามารถ SSO องค์กรต่าง ๆ หรือ tenant หลายแห่ง สามารถเข้าถึงแอปของคุณอย่างปลอดภัยและรวดเร็ว

นี่คือลำดับงานของ SSO ที่ริเริ่มจาก SP:

1. ผู้ใช้พยายามลงชื่อเข้าใช้แอปของคุณ
2. แอปของคุณสร้าง SAML request และ redirect ผู้ใช้ไปหน้าล็อกอินของ IdP
3. ผู้ใช้ลงชื่อเข้าใช้ที่ IdP (หากลงชื่อเข้าใช้แล้วก็ข้ามขั้นตอน)
4. IdP ยืนยันตัวตน หลังจากยืนยันแล้วจะรวมรายละเอียดผู้ใช้ลงใน SAML assertion
5. IdP ส่ง assertion กลับไปที่แอปของคุณ
6. บริการของคุณตรวจสอบ assertion หากถูกต้องให้ผู้ใช้ใช้งานแอปคุณได้

ค่าพารามิเตอร์หลักใน SAML SSO#

สำหรับการผสาน SAML SSO ที่สำเร็จ ทั้ง IdP และ SP ต้องแบ่งปันค่าพารามิเตอร์บางอย่าง ต่อไปนี้คือหัวใจสำคัญ:

ค่าพารามิเตอร์จากฝั่ง IdP#

1. IdP Entity ID: ตัวระบุเฉพาะของ IdP ในการสื่อสารผ่าน SAML เปรียบเหมือนป้ายชื่อดิจิทัล
2. SSO URL: จุด login (URL) ที่ SP จะ redirect ผู้ใช้ไปเพื่อยืนยันตัวตน
3. X.509 Certificate: public key สำหรับเซ็นชื่อ SAML assertion เพื่อรับรองความปลอดภัย เป็นเหมือน “ตราประทับ” รับรองความถูกต้อง

เคล็ดลับ: หาก IdP ของคุณมี SAML Metadata URL จะง่ายขึ้นเยอะ เพราะ URL นี้จะมีข้อมูลสำคัญทุกอย่าง (เช่น certificate, SSO URL, และ IdP Entity ID) อยู่ในที่เดียว ลดความผิดพลาดเวลาคัดลอกข้อมูล และไม่ต้องอัปเดต certificate ไฟล์เองบ่อย ๆ

ค่าพารามิเตอร์จากฝั่ง SP#

1. SP Entity ID: ตัวระบุเฉพาะของ SP คล้ายกับ IdP Entity ID
2. Assertion Consumer Service (ACS) URL: endpoint ของ SP ที่ SP รอรับ SAML assertion จาก IdP
3. RelayState (ไม่บังคับ): ใช้สำหรับส่งข้อมูลขณะทำงานกับ SAML เช่น URL ที่ผู้ใช้ตั้งใจจะเข้าตั้งแต่ต้น

การจับคู่ attributes ใน SAML และการเข้ารหัส#

1. NameID Format: รูปแบบตัวระบุผู้ใช้ (เช่น email address หรือ username)
2. 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 ที่ถูกต้องจะช่วยให้ระบบสื่อสารกันลื่นไหล
3. Encrypted Assertions (ไม่บังคับ): ปกป้องข้อมูลยืนยันตัวตนที่สำคัญ SAML assertion สามารถถูกเข้ารหัสได้
   • IdP: เข้ารหัส assertion ด้วย public key ของ SP
   • SP: ถอดรหัส 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) เพื่อความปลอดภัยมากขึ้น

1. สร้าง Logto App ไปที่ Logto Console > Applications และสร้าง SAML app ใหม่
2. กำหนดค่า SAML Parameters ตั้งค่าแอปด้วย Assertion Consumer Service URL และ SP Entity ID ของ Service Provider (SP)
3. แจ้ง metadata URL Logto จะให้ IdP Metadata URL ที่ SP ใช้ดึงข้อมูลสำคัญเช่น SSO URL และ certificate อัตโนมัติ
4. กำหนดค่าขั้นสูง (ไม่บังคับ)
   • สร้าง certificate ใหม่ หลายใบได้ (พร้อม fingerprint ระบุวันหมดอายุ) แต่เปิดใช้งานทีละใบเท่านั้น
   • ปรับรูปแบบ Name ID ให้ตรงกับธุรกิจของคุณ
   • เปิดใช้ การเข้ารหัส assertion SAML โดยใช้ x509 certificate จาก Service Provider ของคุณเพื่อเข้ารหัส assertion
5. จัดการ Map Attribute (ไม่บังคับ) ตั้งค่าได้ง่าย ๆ ว่าจะให้ Logto แชร์ข้อมูล attribute ของผู้ใช้กับ Service Provider (SP) อย่างไร

ดูคำแนะนำฉบับเต็มได้ที่: SAML App

ใช้ Logto เป็น SAML SP#

Logto ผสานกับ enterprise IdP ใดก็ได้ ผ่าน SAML หรือ OIDC ไม่ว่าคุณจะตั้งค่า SSO จาก SP หรือ IdP กระบวนการก็ทำง่าย

1. สร้าง enterprise connector ไปที่ Logto Console > Enterprise SSO และสร้าง Enterprise Connector เลือก SAML เป็น protocol
2. กำหนด SAML parameters ให้ metadata URL หรือ metadata XML file จาก IdP ของคุณ ถ้าไม่มี metadata เปลี่ยนไปทำ manual ใส่ IdP Entity ID, SSO URL และอัปโหลด Signing certificate ด้วยตัวเอง
3. แชร์ ACS URL และ SP Entity ID แจ้ง ACS URL และ SP Entity ID ของ Logto ให้ IdP ของคุณ เพื่อจบการเชื่อมต่อ
4. จัดการ map attribute (ไม่บังคับ) ตั้งค่าการจับคู่ข้อมูลผู้ใช้ เช่น email หรือชื่อ ให้ถูกต้องระหว่าง IdP และ Logto
5. เพิ่มโดเมนอีเมลขององค์กร ในแท็บ “SSO Experience” สำหรับ enterprise connector, เพิ่มโดเมน email หนึ่งหรือมากกว่านั้น เพื่อให้เฉพาะผู้ใช้ที่มีโดเมนตรงนี้เท่านั้นที่ authenticate ผ่าน SSO ได้
6. เปิดใช้ IdP-initiated SSO (ไม่บังคับ) เปิดใช้ IdP-initiated SSO หากลูกค้าองค์กรของคุณต้องการ ให้ผู้ใช้ล็อกอินที่แอปของคุณผ่าน IdP dashboard ได้โดยตรง

ดูคำแนะนำฉบับเต็มที่นี่: Enterprise SSO documentation

สรุปส่งท้าย#

SAML เป็นมาตรฐานที่ปลอดภัยสำหรับ SSO ช่วยให้การยืนยันตัวตนเป็นเรื่องง่าย ไม่ว่าคุณตั้งค่าเป็น IdP หรือ SP Logto ก็ทำให้กระบวนการนี้ง่ายขึ้น ด้วยอินเทอร์เฟซที่ใช้งานง่าย รองรับทั้ง cloud และ open-source จึงตัดความซับซ้อนของ SAML ออกไป แค่ตั้งค่าพารามิเตอร์ไม่กี่ตัว คุณก็สามารถเชื่อมต่อระบบกับ SAML IdP หรือ SP ใดก็ได้ แล้วเน้นพัฒนาประสบการณ์ดี ๆ ให้ผู้ใช้ของคุณได้เลย