• SAML
  • SSO
  • ผู้ให้บริการข้อมูลประจำตัว

ทำให้ง่ายสำหรับนักพัฒนาในการผสานรวมแอป SAML

เรียนรู้ว่า SAML คืออะไร วิธีการใช้ SSO และขั้นตอนที่รวดเร็วในการรวมแอป SAML เป็นผู้ให้บริการข้อมูลประจำตัว (IdP) หรือผู้ให้บริการบริการ (SP)

Ran
Ran
Product & Design

หยุดเสียเวลาเป็นสัปดาห์กับการยืนยันตัวตนผู้ใช้
เปิดตัวแอปที่ปลอดภัยเร็วขึ้นด้วย Logto ผสานการยืนยันตัวตนผู้ใช้ภายในไม่กี่นาทีและมุ่งเน้นที่ผลิตภัณฑ์หลักของคุณ
เริ่มต้นใช้งาน
Product screenshot

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

SAML SSO และแอป SAML คืออะไร?

Security Assertion Markup Language (SAML) เป็นมาตรฐานที่ใช้ XML สำหรับการแลกเปลี่ยนข้อมูลการรับรองและการอนุญาตระหว่างผู้เล่นหลักสองคน: ผู้ให้บริการข้อมูลประจำตัว (IdP) และ ผู้ให้บริการบริการ (SP) เป็นโซลูชั่นสำหรับการลงชื่อเข้าใช้ครั้งเดียว (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" ผู้คนมักจะหมายถึง SP

ด้วยโปรโตคอล SAML คุณสามารถกำหนดบริการของคุณเป็น IdP เพื่อสนับสนุนการรวมแอป (เช่น Azure Ad / Google Workspace); หรือเป็น SP (เช่น Salesforce / Slack) เพื่อสนับสนุน SSO สำหรับผู้ใช้

SAML Assertion เป็นหัวใจของโปรโตคอล SAML เป็น "โน้ต" ดิจิทัลที่สร้างโดย IdP และส่งไปยัง SP ที่บอกว่า "ฉันได้รับรองตัวตนผู้ใช้นี้แล้ว" ต่อไปเราจะครอบคลุมกระบวนการทำงานสำหรับทั้ง IdP และ SP

เมื่อตัวรับรองการทำงานเป็นผู้ให้บริการข้อมูลประจำตัว SAML

เมื่องานบริการของคุณทำหน้าที่เป็น IdP คุณทำให้การรับรองความถูกต้องของ SAML สามารถใช้งานได้ในแอปพลิเคชันหลายตัว สิ่งนี้ทำให้ผู้ใช้สามารถเข้าถึงบริการต่าง ๆ ผ่านตัวตนนปายการเดียว

as_saml_identity_provider_idp.png

นี่คือกระบวนการทำงาน SAML SSO ที่ได้มาตรฐานสำหรับ IdP:

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

เมื่อตัวรับรองการทำงานเป็นผู้ให้บริการบริการ SAML

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

as_saml_service_provider_sp.png

นี่คือกระบวนการทำงานสำหรับ SP-initiated SSO:

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

พารามิเตอร์ที่สำคัญใน SAML SSO

สำหรับการรวม SAML SSO ที่ประสบความสำเร็จ ทั้ง IdPs และ SPs ต้องแบ่งปันพารามิเตอร์เฉพาะ นี่คือรูปแบบพื้นฐาน:

พารามิเตอร์จาก IdP

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

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

พารามิเตอร์จาก SP

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

แผนที่แอตทริบิวต์ SAML และการเข้ารหัส

  1. NameID Format: กำหนดรูปแบบการระบุตัวผู้ใช้ (เช่น ที่อยู่อีเมลหรือชื่อผู้ใช้)
  2. SAML Attributes: เช่นรายละเอียดเพิ่มเติมของผู้ใช้ เช่น บทบาท, อีเมล หรือแผนก ที่ IdP ส่งไปยัง SP
    • ตัวอย่าง: หาก SAML assertion ที่เซ็นด้วย IdP รวม email ([email protected]), role (admin), และ department (engineering) SP สามารถใช้ role เพื่อมอบสิทธิ์ผู้ดูแลระบบหรือ department เพื่อจัดกลุ่มผู้ใช้ในทีมที่ถูกต้อง ดังนั้นเพื่อให้ได้ข้อมูลผู้ใช้ที่สำคัญนี้ ทั้ง IdP และ SP จำเป็นต้องตัดสินใจวิธีการแผนที่แอตทริบิวต์ เช่น IdP อาจระบุ "department" เป็นทีม ขณะที่ SP คาดหวังว่าเป็นกลุ่ม การแผนที่ที่เหมาะสมรับประกันการสื่อสารที่ราบรื่น
  3. Encrypted Assertions (Optional) เพื่อปกป้องข้อมูลการรับรองความถูกต้องที่ละเอียดอ่อน, SAML assertions สามารถเข้ารหัสได้
    • บทบาทของ IdP: เข้ารหัส assertion โดยใช้กุญแจสาธารณะของ SP
    • บทบาทของ SP: ถอดรหัส assertion ด้วยกุญแจส่วนตัวของตัวเองเพื่ออ่านข้อมูลผู้ใช้

ตอนนี้คุณควรมีข้อมูลที่จำเป็นเพื่อจัดตั้งการเชื่อมต่อ SAML เพื่อรวม Salesforce (Service Provider) กับ Azure AD (Identity Provider), ทำตามขั้นตอนเหล่านี้:

  • รับ IdP Entity ID, SSO URL, และใบรับรองจาก Azure AD และกำหนดค่าใน Salesforce
  • ให้ SP Entity ID และ ACS URL ของ Salesforce ไปที่ Azure AD

Logto ทำให้การรวม SAML ง่ายดาย

Logto สามารถทำหน้าที่เป็น IdP หรือ SP เพื่อสนับสนุน SAML SSO สำหรับแอปพลิเคชันของคุณ

การใช้ Logto เป็น SAML IdP

Logto อนุญาตให้แอปพลิเคชันอื่น ๆ พึ่งพามันสำหรับการรับรองตัวตนรวมและสนับสนุน การรับรองตัวตนหลายปัจจัย (MFA) เพื่อความปลอดภัยที่มากขึ้น

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

logto_saml_apps_saml_providers.png

สำหรับคำแนะนำรายละเอียดเข้าไปที่เอกสารอย่างเป็นทางการที่นี่: SAML App

การใช้ Logto เป็น SAML SP

Logto ยังรวมตัวกับ IdP ขององค์กรใด ๆ เข้าผ่านโปรโตคอล SAML หรือ OIDC ไม่ว่าคุณจะกำลังเปิดใช้งาน SP-initiated SSO สำหรับหน้าลงชื่อเข้าใช้รวมของคุณหรือกำหนดค่า IdP-initiated SSO กระบวนการนั้นง่ายมาก

  1. สร้างตัวเชื่อมต่อองค์กร ไปที่ Logto Console > Enterprise SSO และสร้างตัวเชื่อมต่อองค์กรใหม่ เลือก SAML เป็นมาตรฐานโปรโตคอล
  2. กำหนดค่าพารามิเตอร์ SAML ให้ URL ข้อมูลเมตาหรือไฟล์ข้อมูลเมตา XML จาก IdP ของคุณ หากไม่มีข้อมูลเมตาให้เลือกการกำหนดค่าด้วยตนเองโดยป้อน IdP Entity ID, SSO URL, และอัปโหลดใบรับรองลายเซ็น
  3. แชร์ URL ACS และ SP Entity ID ให้ Logto’s ACS URL และ SP Entity ID แก่ IdP ของคุณเพื่อตั้งค่าสิ้นสุดการรวม
  4. การแผนที่แอตทริบิวต์ (ไม่บังคับ) กำหนดการแมปข้อมูลผู้ใช้ เช่น อีเมลหรือชื่อ เพื่อให้แน่ใจว่าได้ส่งข้อมูลที่ถูกต้องระหว่าง IdP และ Logto
  5. เพิ่มโดเมนอีเมลองค์กร ในแท็บ “SSO Experience” สำหรับตัวเชื่อมต่อองค์กร ให้เพิ่มหนึ่งหรือหลายโดเมนอีเมล สิ่งนี้ทำให้แน่ใจว่ามีเพียงผู้ใช้ที่มีโดเมนที่ระบุเท่านั้นที่สามารถรับรองผ่าน SSO
  6. เปิดใช้งาน IdP-initiated SSO (ไม่บังคับ) เปิดใช้งาน IdP-initiated SSO เฉพาะเมื่อจำเป็นโดยลูกค้าองค์กรของคุณ ฟีเจอร์นี้ให้ผู้ใช้ลงชื่อเข้าใช้งานโดยตรงจากแดชบอร์ด IdP

logto-enterprise-saml-sso.png

สำหรับคำแนะนำโดยละเอียด เข้าไปที่เอกสารทางการได้ที่นี่: เอกสาร Enterprise SSO.

สรุปความคิด

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