SAML Decoder: ถอดรหัส SAMLRequest และ SAMLResponse ในเบราว์เซอร์ของคุณ

ถ้าคุณเคยตั้งค่า single sign-on (SSO) คงคุ้นเคยกับสถานการณ์แบบนี้: ผู้ใช้ล็อกอินไม่สำเร็จ หน้าจอขึ้นข้อความ error กำกวม ๆ และเบาะแสที่แท้จริงถูกซ่อนอยู่ในข้อความ Base64 ยาว ๆ ที่ชื่อว่า SAMLRequest หรือ SAMLResponse ข้อความพวกนี้อ่านด้วยตาเปล่าไม่รู้เรื่องเลย และการนำ token ที่เกี่ยวกับความปลอดภัยไปวางในเว็บถอดรหัสแบบสุ่ม ๆ ก็ไม่ค่อยน่าไว้ใจนัก SAML Decoder แก้ทั้งสองปัญหาได้ในที่เดียว เพียงวางข้อความลงไป คุณจะได้ XML ที่อ่านได้ทันที พร้อมเห็นฟิลด์สำคัญที่ระบบปลายทางใช้ตรวจสอบ

SAML หรือ Security Assertion Markup Language ยังคงเป็นโปรโตคอลหลักที่องค์กร มหาวิทยาลัย และแพลตฟอร์ม SaaS นับไม่ถ้วนใช้ทำ identity federation ข้อความ SAML ทุกข้อความจะถูกเข้ารหัสด้วย Base64 และ request ที่ส่งผ่าน redirect มักถูกบีบอัดด้วย DEFLATE ซ้อนอยู่ข้างในอีกชั้น ทำให้มองเนื้อหาข้างในไม่เห็นเลยด้วยตาเปล่า ซึ่งเป็นเหตุผลว่าทำไมทุกทีมที่ดูแลระบบ identity ควรมีเครื่องมือถอดรหัสไว้ติดมือเสมอ

ที่สำคัญที่สุดคือเครื่องมือนี้ทำงานทั้งหมดในเบราว์เซอร์ของคุณ token ของ SAML ซึ่งเป็นข้อความที่เซ็นดิจิทัลเกี่ยวกับผู้ใช้จริง จะไม่ถูกส่งออกไปไหนเลย ไม่มีการอัปโหลด ไม่มี log บนเซิร์ฟเวอร์ ไม่ต้องสมัครบัญชี เพียงวาง ถอดรหัส แล้วตรวจสอบ

ทำไมต้องใช้ SAML Decoder?

• ความเป็นส่วนตัวของ token อย่างสมบูรณ์ assertion ของ SAML เป็นข้อความที่เซ็นดิจิทัลเกี่ยวกับผู้ใช้จริง หลายองค์กรจัดเป็นข้อมูลที่ละเอียดอ่อน เพราะการถอดรหัสเกิดขึ้น 100% ในเบราว์เซอร์ ข้อมูลจึงไม่ถูกส่ง จัดเก็บ หรือบันทึกไว้ที่อื่นเลย
• ถอดรหัสและคลายการบีบอัดในขั้นตอนเดียว แค่ Base64 decode อย่างเดียวมักได้แต่ตัวอักษรมั่ว เพราะ payload ข้างในถูกบีบอัดด้วย DEFLATE เครื่องมือจะตรวจจับและ inflate ให้อัตโนมัติ
• XML ที่จัดรูปแบบสวยงาม ข้อความ SAML ที่ถอดรหัสแล้วมักเป็นบรรทัดเดียวยาวมหึมา เครื่องมือจะจัดย่อหน้าใหม่เป็น XML ที่ไล่อ่านทีละ element ได้ง่าย
• ตรวจสอบฟิลด์อัตโนมัติ ไม่ต้องไล่หาใน XML เอง แพนเนล Message fields จะสรุป Root element, Destination, Issuer, IssueInstant, StatusCode และ AssertionConsumerServiceURL ให้พร้อมใช้งาน
• ไม่ต้องติดตั้ง ไม่ต้องสมัครบัญชี เป็นแค่หน้าเว็บ ไม่ใช่ plugin หรือโปรแกรม เปิดใช้ได้ทุกเครื่อง รวมถึงเครื่องลูกค้าตอนที่ต้อง support ด้วย
• เร็วพอสำหรับการดีบักแบบสด ๆ วงจร วาง ถอดรหัส ตรวจสอบ ใช้เวลาไม่กี่วินาที จึงสลับไปมาได้ขณะทำซ้ำอาการที่ล็อกอินไม่ผ่าน

ฟีเจอร์หลัก

รายละเอียดที่ควรรู้เพิ่มเติม:

• เครื่องมือรองรับทั้ง SAMLRequest ซึ่งเป็น AuthnRequest ที่ service provider ส่งไปยัง identity provider และ SAMLResponse ซึ่งเป็น assertion ที่ส่งกลับมาทางกลับ
• ถ้าไบต์ที่ Base64 decode แล้วไม่ใช่ XML ที่อ่านได้ เครื่องมือจะ inflate ด้วย raw DEFLATE ก่อนแสดงผล ซึ่งตรงกับวิธีที่ HTTP-Redirect binding บรรจุข้อความไว้
• ค่า Destination และ AssertionConsumerServiceURL แสดงแบบตรงตัว ช่วยให้เทียบกับ URL ที่ตั้งค่าไว้ได้ทีละตัวอักษร ความไม่ตรงกันตรงนี้เป็นสาเหตุอันดับต้น ๆ ที่ทำให้ SSO ล้มเหลว

วิธีใช้งาน SAML Decoder

1. จับข้อความมาก่อน เปิด developer tools ในเบราว์เซอร์ แล้วคัดลอกพารามิเตอร์ SAMLRequest จาก query string ของ redirect ที่ไปยัง identity provider หรือฟิลด์ SAMLResponse จาก POST body ที่ IdP ส่งกลับมา
2. วางลงในเครื่องมือ รองรับค่า Base64 ดิบ มีหรือไม่มีช่องว่างล้อมรอบก็ได้
3. ถอดรหัสและคลายการบีบอัด เครื่องมือจะ decode Base64 และ inflate payload ที่ถูกบีบอัดด้วย DEFLATE ให้อัตโนมัติเมื่อจำเป็น
4. อ่านแพนเนล Decoded XML ผลลัพธ์ที่จัดรูปแบบแล้วจะแสดงโครงสร้างของข้อความทั้งหมด ตั้งแต่ element รากลงไปจนถึงเนื้อหาของ assertion
5. เช็กแพนเนล Message fields เทียบ Root element, Destination, Issuer, IssueInstant, StatusCode และ AssertionConsumerServiceURL กับค่าที่การตั้งค่าของคุณควรจะเป็น

ทำความเข้าใจข้อความ SAML

การแลกเปลี่ยนข้อมูลแบบ SAML เกี่ยวข้องกับสองฝ่าย คือ identity provider (IdP) ที่ทำหน้าที่ยืนยันตัวตนผู้ใช้ และ service provider (SP) ที่อาศัยผลการยืนยันตัวตนนั้นไปใช้งาน ข้อความหลักมีสองแบบ ข้อความ AuthnRequest วิ่งจาก SP ไปหา IdP เพื่อขอให้ยืนยันตัวตนผู้ใช้ ส่วนข้อความ Response วิ่งจาก IdP กลับมาที่ SP พร้อม assertion ที่เซ็นดิจิทัลและผลลัพธ์ของการแลกเปลี่ยน เครื่องมือนี้ถอดรหัสได้ทั้งสองแบบ จึงมองเห็นภาพการไหลของข้อมูลได้ครบทั้งรอบ ไม่ต้องเดาจากหน้า error เพียงลำพัง

เรื่องการเข้ารหัสคือกำแพงแรกที่ทุกคนเจอ ข้อความ XML เป็นข้อความที่ยาวมาก จึงต้องบีบอัดและเข้ารหัสให้เดินทางผ่าน URL และฟอร์ม HTML ได้อย่างปลอดภัย ใน HTTP-Redirect binding ข้อความจะถูกบีบอัดด้วย DEFLATE ก่อน แล้วจึงเข้ารหัส Base64 และ URL-encode อีกที ส่วน HTTP-POST binding ใช้แค่ Base64 โดยไม่บีบอัด ถ้า decode Base64 แบบธรรมดาโดยไม่ inflate คุณจะได้แต่ขยะไบนารี ซึ่งเป็นจุดที่ทำให้เกือบทุกคนงงตั้งแต่ครั้งแรก

ฟิลด์ที่ตัดสินว่าข้อความจะถูกยอมรับหรือไม่ก็สำคัญไม่แพ้กัน Destination ระบุ URL ที่ข้อความถูกส่งถึง ฝั่งรับจะปฏิเสธข้อความที่ระบุปลายทางอื่นทันที ถ้าค่านี้ล้าสมัยหรือผิด การล็อกอินจะล้มเหลวทันที Issuer ระบุตัวตนของผู้ส่ง (entity ID) ซึ่งต้องตรงกับ metadata ที่ฝั่งรับลงทะเบียนไว้ ไม่อย่างนั้นการตรวจสอบความน่าเชื่อถือจะล้มเหลว StatusCode บอกผลลัพธ์ของการแลกเปลี่ยน เช่น ค่า urn:oasis:names:tc:SAML:2.0:status:Success แปลว่าทุกอย่างเรียบร้อย ส่วนโค้ดอย่าง Requester หรือ Responder จะชี้ว่าความล้มเหลวเกิดขึ้นฝ่ายใด IssueInstant เก็บเวลาที่ออกข้อความ ถ้านาฬิกาของสองฝ่ายเหลื่อมกันมากเกินไป (clock skew) ข้อความที่ถูกต้องทุกอย่างก็ถูกปฏิเสธได้ และ AssertionConsumerServiceURL บอก IdP ว่าจะส่ง response ไปที่ไหน ถ้าไม่ตรงกับ metadata ของ SP ก็จะเกิด error ก่อนที่จะตรวจสิ่งอื่นใด

ตัวอย่างการใช้งานจริง

ดีบัก SSO ที่ลูปกลับหน้าล็อกอิน

ถ้าผู้ใช้ล็อกอินสำเร็จแล้วถูกเด้งกลับมาที่หน้าล็อกอินทันที มักแปลว่า SP ไม่ยอมรับ response ที่ได้รับมา ให้จับ SAMLResponse จาก POST body มาถอดรหัส แล้วเทียบ Destination และ AssertionConsumerServiceURL กับการตั้งค่า SP ของคุณ ส่วนถ้าใน URL ตอนเกิดลูปมี AuthnRequest ใหม่ปรากฏขึ้นแทน แปลว่า SP อาจไม่เคยได้รับ response ที่ถูกต้องเลย ให้ถอดรหัส request และตรวจว่า Issuer ตรงกับที่ IdP คาดหวังหรือไม่

ตรวจสอบ Issuer จาก IdP

เวลาที่คุณเปลี่ยน identity provider หรือเพิ่ม IdP ตัวที่สอง entity ID ใน element Issuer ต้องตรงกับ metadata ที่ SP ลงทะเบียนไว้ ให้ถอดรหัส response จริงจากระบบแล้วเทียบค่า Issuer กับค่าที่ตั้งค่าไว้โดยตรง วิธีนี้จับกรณีค่าจาก environment ทดสอบหลุดเข้า production ได้เร็วกว่าการไล่อัปโหลด certificate ใหม่ซ้ำ ๆ หลายเท่า

เช็ก ACS URL ที่ไม่ตรงกัน

หลังจากย้ายเว็บไซต์ระหว่าง environment เช่น จาก staging ไป production หรือเปลี่ยนจาก http เป็น https ค่า AssertionConsumerServiceURL ใน response มักยังชี้ไปที่ที่อยู่เดิม ทำให้เกิด error ที่ดูเหมือนไม่เกี่ยวกับ SSO เลย ให้ถอดรหัส response แล้วเทียบค่านี้กับ callback URL ที่ลงทะเบียนไว้ บ่อยครั้งวิธีแก้คือแก้ metadata เพียงบรรทัดเดียว

อ่าน StatusCode เมื่อล็อกอินไม่ผ่าน

เมื่อ IdP ปฏิเสธการยืนยันตัวตนของผู้ใช้ StatusCode จะบอกเหตุผลได้ทันที ไม่ต้องจ้องหน้า error page ว่าง ๆ โค้ดย่อยอย่าง RequestDenied หรือ InvalidNameIDPolicy มักชี้ไปที่สิทธิ์ของผู้ใช้หรือรูปแบบ identifier มากกว่าการตั้งค่า protocol ถอดรหัสข้อความก่อนเสมอเพื่อดูว่าความล้มเหลวเกิดขึ้นที่ขั้นตอนไหน แล้วคุณจะรู้ว่าควรโทรหาทีม identity หรือแก้ metadata ของตัวเอง

แนวปฏิบัติที่ดี

• ถือว่า token ทุกตัวเป็นข้อมูลละเอียดอ่อน แม้เครื่องมือจะประมวลผลฝั่งไคลเอนต์ response ของ SAML ก็อาจมีชื่อ อีเมล และกลุ่มผู้ใช้ ปิดแท็บเมื่อใช้เสร็จ และเลี่ยงการจับภาพหน้าจอ assertion
• ตรวจ Destination และ Issuer เป็นอันดับแรก สองฟิลด์นี้เป็นสาเหตุของการตั้งค่าผิดพลาดในระบบ SSO ส่วนใหญ่
• เทียบ IssueInstant กับนาฬิกาของเซิร์ฟเวอร์ นาฬิกาที่เหลื่อมกันมากเกินไปทำให้ข้อความที่ถูกต้องถูกปฏิเสธได้
• ถอดรหัสทั้งสองทิศทาง ดู AuthnRequest เมื่อการล็อกอินไม่ถึง IdP และดู Response เมื่อไม่สำเร็จในขั้นตอนสุดท้าย
• เช็ก StatusCode ก่อนโทษการตั้งค่า โค้ดย่อยอาจบอกว่าบัญชีถูกล็อกหรือผู้ใช้ถูกปิดใช้งาน ไม่ใช่ปัญหา protocol
• อย่าส่ง token ดิบใน ticket หรือแชท แชร์เฉพาะค่าฟิลด์ที่ถอดรหัสแล้ว ไม่ใช่ token ทั้งก้อน

ครั้งต่อไปที่ single sign-on ทำตัวไม่ซื่อ อย่าเสียเวลาเดา เปิด SAML Decoder วางข้อความลงไป แล้วอ่านดูว่ามีอะไรถูกแลกเปลี่ยนกันแน่ อย่างปลอดภัยภายในเบราว์เซอร์ของคุณเองทั้งหมด

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• JWT Decoder — ตรวจสอบ header และ claims ของ JWT แบบเดียวกันทั้งหมดฝั่งไคลเอนต์
• Base64 Encoder — เข้ารหัสหรือถอดรหัสข้อความ Base64 ได้ทันที
• XML Formatter — จัดรูปแบบและตรวจสอบความถูกต้องของเอกสาร XML

ขอให้สนุกกับการดีบักครับ และขอให้ StatusCode ของคุณเป็น Success ตลอดไป!

คำถามที่พบบ่อย

ถ: SAML decoder ใช้ทำอะไร? ตอบ: ใช้แปลงข้อความ SAMLRequest หรือ SAMLResponse ที่เข้ารหัส Base64 (และมักถูกบีบอัดด้วย DEFLATE) ซึ่งวิ่งระหว่าง service provider กับ identity provider ให้กลายเป็น XML ที่จัดรูปแบบอ่านง่าย เพื่อตรวจสอบฟิลด์อย่าง Destination, Issuer และ StatusCode ขณะดีบัก single sign-on

ถ: วาง SAML response ลงในเครื่องมือนี้ปลอดภัยไหม? ตอบ: ปลอดภัยครับ เพราะ SAML Decoder ทำงานทั้งหมดในเบราว์เซอร์ของคุณ token จะไม่ถูกอัปโหลด เก็บ หรือบันทึกไว้ที่ใด แต่ควรถือว่า token เป็นข้อมูลละเอียดอ่อนและไม่แชร์มันหลังจากได้ค่าที่ต้องการแล้ว

ถ: ทำไม SAMLRequest ของฉันถอดรหัส Base64 แล้วเป็นตัวอักษรมั่ว? ตอบ: เพราะข้อความที่ส่งผ่าน HTTP-Redirect binding ถูกบีบอัดด้วย DEFLATE ก่อนเข้ารหัส Base64 ถ้า decode Base64 อย่างเดียวจะได้ขยะไบนารี SAML Decoder จะ inflate payload ที่ถูกบีบอัดให้อัตโนมัติและแสดง XML ข้างในให้คุณเห็น

ถ: SAMLRequest กับ SAMLResponse ต่างกันอย่างไร? ตอบ: SAMLRequest คือ AuthnRequest ที่ service provider สร้างขึ้นเพื่อขอให้ identity provider ยืนยันตัวตนผู้ใช้ ส่วน SAMLResponse คือสิ่งที่ identity provider ส่งกลับมา พร้อม assertion ที่เซ็นดิจิทัลและ StatusCode ของการแลกเปลี่ยนครั้งนั้น