เมตาเดต้า SAML

^{[ CS 1 ]}มาตรฐานเมตาเดตา SAMLเป็นส่วนหนึ่งของกลุ่มมาตรฐาน XML ที่เรียกว่าSecurity Assertion Markup Language(SAML) ซึ่งเผยแพร่โดยOASISในปี 2548 เอกสารเมตาเดตา SAML อธิบายถึงการใช้งาน SAML เช่นผู้ให้บริการข้อมูลประจำตัว SAMLหรือผู้ให้บริการบริการ SAMLการใช้งานเหล่านี้จะใช้เมตาเดตาร่วมกันเพื่อสร้างพื้นฐานของความไว้วางใจและความสามารถในการทำงานร่วมกัน

เพื่อให้การทำงานร่วมกันเป็นไปอย่างปลอดภัย คู่ค้าจะต้องแบ่งปันข้อมูลเมตาในรูปแบบและวิธีการใดก็ได้เท่าที่จะเป็นไปได้ อย่างน้อยที่สุดจะต้องมีการแบ่งปันข้อมูลเมตาต่อไปนี้:

• รหัสเอนทิตี
• จุดสิ้นสุดของโปรโตคอล (การผูกและการระบุตำแหน่ง)

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

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

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

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

เพื่อให้กระบวนการแบ่งปันเมตาเดตาเป็นไปโดยอัตโนมัติอย่างสมบูรณ์ จำเป็นต้องมีรูปแบบไฟล์มาตรฐาน ด้วยเหตุนี้ ข้อกำหนดเมตาเดตา SAML V2.0 ^{[ OS 1 ]}จึงกำหนดรูปแบบมาตรฐานสำหรับเมตาเดตา SAML ซึ่งทำให้การกำหนดค่าซอฟต์แวร์ SAML ง่ายขึ้น และทำให้สามารถสร้างกระบวนการแบ่งปันเมตาเดตาที่ปลอดภัยและเป็นอัตโนมัติได้

เมื่อเทคโนโลยี SAML พัฒนาขึ้น ความสำคัญของเมตาเดตา SAML ก็เพิ่มขึ้นอย่างต่อเนื่อง ปัจจุบัน การใช้งานที่รองรับการลงชื่อเข้าใช้ครั้งเดียว ผ่านเว็บเบราว์เซอร์ SAML จำเป็นต้องมีไฟล์เมตาเดตา SAML ที่ถูกต้องตามสคีมาสำหรับพาร์ทเนอร์ SAML แต่ละราย (ดูข้อมูลเพิ่มเติมเกี่ยวกับการลงชื่อเข้าใช้ครั้งเดียวผ่านเว็บเบราว์เซอร์ SAML ได้ในข้อกำหนด SAML V2.0 Profiles ^{[ OS 2 ] )}

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

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

สมมติว่าเมตาเดตาของ SP มีคีย์เข้ารหัสสาธารณะอยู่ และโดยปกติแล้ว คีย์ถอดรหัสส่วนตัวที่เกี่ยวข้องจะถูกกำหนดค่าไว้ในซอฟต์แวร์ของ SP หากคีย์ถอดรหัสส่วนตัวถูกบุกรุก (หรือจำเป็นต้องเปลี่ยนใหม่) คีย์เข้ารหัสสาธารณะในเมตาเดตาของ SP ก็จะไม่น่าเชื่อถืออีกต่อไปและต้องถูกเปลี่ยนใหม่เช่นกัน

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

ในฝั่งผู้ให้บริการ (SP) ก็เช่นเดียวกัน การกำหนดค่าเมตาเดตาของ IdP แบบคงที่ลงในซอฟต์แวร์ของ SP หมายความว่าเจ้าของ SP ยอมรับความรับผิดชอบในการดูแลรักษาเมตาเดตาของ IdP โดยปริยายเมื่อมีการเปลี่ยนแปลงใดๆ เกิดขึ้น เนื่องจาก IdP (หรือ SP) มักมีพันธมิตรจำนวนมาก การกำหนดค่าเมตาเดตาแบบคงที่จึงไม่สามารถรองรับการขยายตัวได้ และยิ่งไปกว่านั้น การจัดการการเปลี่ยนแปลงที่เกี่ยวข้องกับเมตาเดตาแบบคงที่นั้นทำได้ยากมาก

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

เพื่อหลีกเลี่ยงภาระทางเทคนิคที่มากเกินไป กระบวนการแบ่งปันเมตาเดตาจะต้องเป็นแบบอัตโนมัติ แนวทางหนึ่งคือการขอความช่วยเหลือจากบุคคลที่สามที่น่าเชื่อถือ ซึ่งมีหน้าที่ในการรวบรวม คัดกรอง และเผยแพร่เมตาเดตาผ่านเครือข่าย เมตาเดตาที่ได้รับการคัดกรองแล้วจะมีรูปแบบที่สม่ำเสมอ มีแนวโน้มที่จะปราศจากช่องโหว่ (ไม่ว่าจะโดยเจตนาหรือไม่ก็ตาม) และจึงปลอดภัยต่อการใช้งาน

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

ต่อไปนี้เราจะย้อนรอยขั้นตอนต่างๆ ที่นำไปสู่การเผยแพร่ข้อกำหนดเมตาเดตา SAML V2.0 ในเดือนมีนาคม 2548 จุดเปลี่ยนสำคัญเกิดขึ้นในวันที่ 14 พฤศจิกายน 2546 เรื่องราวของเราเริ่มต้นจากตรงนั้น

เพื่อตอบโต้Microsoft Passportกลุ่มพันธมิตร Libertyได้คิดค้นIdentity Federation Frameworkซึ่งเป็นเทคโนโลยีการรวมระบบที่พัฒนาขึ้นในช่วงสามปีระหว่างปี 2002 ถึง 2004 ( ประวัติของ SAML ที่กล่าวถึงก่อนหน้านี้ เป็นบริบทสำหรับ ID-FF) เมื่อวันที่ 14 พฤศจิกายน 2003 Liberty ได้ส่ง ID-FF 1.2 ไปยัง OASISโดยเอกสารที่ส่งมามีชื่อว่าLiberty Metadata Description and Discovery Specification Version 1.0 ^{[ LibertyMeta 1 ]}ซึ่งรวมถึงเป้าหมายการออกแบบดังต่อไปนี้:

1. " whoisสำหรับ SAML federations" (อ้างอิงจาก องค์ประกอบ OrganizationและContactPersonในเมตาเดต้า)
2. การค้นหาข้อมูลเมตาแบบไดนามิก (พร้อมการแก้ไขผ่าน DNS และ Well-Known Location)
3. การรักษาความปลอดภัยระดับเอกสารโดยใช้ลายเซ็น XML

ปรากฏว่าเป้าหมายทั้งหมดเหล่านั้นได้รับการรักษาไว้ในมาตรฐานเมตาเดตา OASIS SAML V2.0 ซึ่งจะกล่าวถึงในภายหลังในบทความนี้

เอกสารสคีมาที่รวมอยู่ในไฟล์เก็บถาวร Liberty ID-FF 1.2 รุ่นเก่า ระบุว่าเป็น Liberty Metadata เวอร์ชัน 1.1 ในขณะที่ Liberty Metadata เวอร์ชัน 1.0 ถูกส่งไปยัง OASIS ความขัดแย้งที่เห็นได้ชัดนี้ได้รับการอธิบายโดยผู้เขียนสคีมา (Peter Davis, การสื่อสารส่วนตัว) ระหว่างเดือนพฤศจิกายน 2546 (เมื่อเวอร์ชัน 1.0 ถูกส่งไปยัง OASIS) และเดือนธันวาคม 2547 (เมื่อ Liberty พัฒนาเวอร์ชัน 1.1 เสร็จสมบูรณ์) การพัฒนาข้อกำหนดเมตาเดต้าของ Liberty ดำเนินไปพร้อมกับกระบวนการทำงานของ OASIS ดูแผนภูมิด้านล่างเพื่อดูภาพประกอบ ลูกศรในแผนภูมิแสดงถึงความสัมพันธ์ระหว่างกัน ในขณะที่เส้นประแสดงถึงความเท่าเทียมกัน

เอกสารอ้างอิงที่เกี่ยวข้องกับกระบวนการทำงาน Liberty อยู่ในตอนท้ายของบทความนี้ แผนผังเมตาเดตาต้นฉบับที่ส่งให้กับ OASIS แสดงไว้อย่างครบถ้วนในส่วนที่ 7 ของข้อกำหนด Liberty Metadata เวอร์ชัน 1.0 ^{[ LibertyMeta 1 ]}ในทำนองเดียวกัน ข้อกำหนดสำหรับ Liberty Metadata เวอร์ชัน 1.1 ^{[ LibertyMeta 2 ]}ก็มีรายการแผนผังเวอร์ชัน 1.1 รวมอยู่ด้วย ทั้งแผนผังเวอร์ชัน 1.0และแผนผังเวอร์ชัน 1.1มีลิงก์อยู่ที่นี่โดยได้รับความอนุเคราะห์จากWayback Machine ของ Internet Archive

ตลอดระยะเวลาสิบสามเดือนถัดมา ตั้งแต่เดือนพฤศจิกายน พ.ศ. 2546 ถึงเดือนธันวาคม พ.ศ. 2547 คณะกรรมการด้านเทคนิคบริการความปลอดภัยของ OASIS (SAML) (SSTC) ได้ปรับปรุงข้อกำหนดเมตาเดตาของ Liberty จนกลายมาเป็นที่รู้จักในชื่อ SAML Metadata ในช่วงเวลานั้น SSTC ได้ขยายข้อกำหนดเมตาเดตาให้ครอบคลุมถึงการรองรับโปรโตคอลหลายตัว (รวมถึงโปรโตคอลที่ไม่ใช่ SAML) แต่ที่สำคัญกว่านั้นคือ โครงสร้างเมตาเดตาของ Liberty ได้รับการปรับปรุงเพิ่มเติมด้วยจุดขยายจำนวนมาก ในทางประวัติศาสตร์ ความสามารถในการขยายของ SAML Metadata ได้ส่งผลกระทบที่สำคัญ ดังที่เราจะได้เห็นต่อไป

ภายในเดือนมีนาคม พ.ศ. 2547 ส่วนใหญ่ของผลงานจากโครงการ Liberty ได้ถูกรวมเข้ากับกระบวนการทำงาน OASIS แล้ว^{[ SAMLMeta 1 ]}นับจากนั้นเป็นต้นมา กระบวนการทำงานของโครงการ Liberty และ OASIS ก็ดำเนินไปพร้อมๆ กัน (แต่ไม่ได้แยกจากกันโดยสิ้นเชิง เนื่องจากมีบุคคลกลุ่มเดียวกันทำงานในข้อกำหนดทั้งสอง) ระหว่างเดือนมีนาคมถึงกรกฎาคม พ.ศ. 2547 ข้อกำหนดเมตาเดตา SAML ที่เพิ่งเริ่มต้นได้มีการเปลี่ยนแปลงครั้งสำคัญ

ในเดือนกรกฎาคม พ.ศ. 2547 SSTC ได้ออกประกาศขอความคิดเห็นจากสาธารณะเกี่ยวกับร่างข้อกำหนด SAML V2.0 ชุดสมบูรณ์ ซึ่งรวมถึงร่างข้อกำหนดเมตาเดตา SAML V2.0 ฉบับใหม่ด้วย^{[ SAMLMeta 2 ]}

เมื่อมองย้อนกลับไป ดูเหมือนว่าข้อกำหนดเมตาเดตา SAML V2.0 ส่วนใหญ่ได้รับการพัฒนาขึ้นระหว่างเดือนมีนาคมถึงกรกฎาคม พ.ศ. 2547 แต่เห็นได้ชัดว่ามาตรฐานเมตาเดตา SAML V2.0 เกิดขึ้นจาก Liberty Alliance โดยเฉพาะอย่างยิ่ง Liberty Metadata เวอร์ชัน 1.0 ^{[ LibertyMeta 1 ]}ดังนั้น เพื่อทำความเข้าใจที่มาของเมตาเดตา SAML จึงต้องศึกษาที่มาของเมตาเดตา Liberty

ประวัติความเป็นมาของเมตาเดตา SAML ที่เหลืออยู่ส่วนใหญ่เป็นกระบวนการบริหารของ OASIS หลังจากที่ร่างฉบับสุดท้ายของคณะกรรมการได้รับการเผยแพร่ในเดือนพฤศจิกายน พ.ศ. 2547 ^{[ SAMLMeta 3 ]} SSTC ได้เริ่มกระบวนการกำหนดมาตรฐานในเดือนมกราคม พ.ศ. 2548 และในที่สุด เมื่อวันที่ 5 มีนาคม พ.ศ. 2548 OASIS ก็ได้ประกาศมาตรฐาน SAML V2.0 ที่ได้รับการรับรองใหม่

ชุดข้อกำหนด V2.0 (ดู ส่วน อ้างอิงสำหรับรายการทั้งหมด) ประกอบด้วยข้อกำหนดเมตาเดตา SAML V2.0 ฉบับสุดท้าย^{[ OS 1 ]}สิบปีต่อมา ในเดือนกันยายน 2015 OASIS ได้เผยแพร่ข้อกำหนดเมตาเดตา SAML ฉบับปรับปรุงพร้อมแก้ไขข้อผิดพลาด^{[ OS 3 ]}ด้วยเหตุนี้ ข้อกำหนดเมตาเดตาฉบับเดิมจึงถูกยกเลิก เช่นเดียวกับเอกสารอื่นๆ ในชุดข้อกำหนด 2.0 ฉบับเดิม

ในช่วงทศวรรษระหว่างปี 2005 ถึง 2015 SSTC ได้พัฒนาร่างข้อกำหนด "หลังเวอร์ชัน 2.0" จำนวนหนึ่ง ร่างเอกสารบางส่วนเหล่านี้ได้กลายเป็นข้อกำหนดของคณะกรรมการ ข้อกำหนดของคณะกรรมการบางส่วนที่คัดเลือกมาแสดงอยู่ใน ส่วนเอกสาร อ้างอิงท้ายบทความนี้

ปรากฏว่า อิทธิพลของ Liberty Identity Federation Framework ต่อเมตาเดตาของ SAML นั้นมีมาก่อนการมีส่วนร่วมของ ID-FF 1.2 ในเดือนพฤศจิกายน 2003 เห็นได้ชัดว่า SSTC กำลังทดลองใช้เมตาเดตาควบคู่ไปกับ Liberty Alliance ข้อความที่ตัดตอนมาจากร่างข้อกำหนดเมตาเดตาที่เผยแพร่ในเดือนกันยายน 2003 ยืนยันเรื่องนี้ได้:

เอกสารนี้กำหนดเมตาเดตาที่อธิบายองค์ประกอบและคุณลักษณะที่จำเป็นสำหรับการใช้งานโปรไฟล์ SSO ของเว็บเบราว์เซอร์ SAML เนื่องจากโปรไฟล์ SSO ของเว็บ Liberty Alliance นั้นอิงตามโปรไฟล์ SSO ของเว็บ SAML โดยตรง เมตาเดตาที่กำหนดไว้ในเอกสารนี้จึงได้หยิบยืมมาจากคำจำกัดความของเมตาเดตาในร่างข้อกำหนด Liberty Alliance 1.2 อย่างกว้างขวาง (คัดลอกมาจาก "เมตาเดตาสำหรับโปรไฟล์ SSO ของเว็บเบราว์เซอร์ SAML 2.0" ^{[ SAMLMeta 4 ]} )

ประวัติการแก้ไขในตอนท้ายของร่างเอกสารฉบับนั้นให้คำอธิบายเกี่ยวกับตัวเองดังนี้: "ร่างฉบับเริ่มต้นโดยอิงจากร่างฉบับที่ 07 ของข้อกำหนดเมตาเดตา SAML 1.1" กล่าวอีกนัยหนึ่งคือ มีการเผยแพร่ร่างเอกสารฉบับก่อนหน้านี้แล้ว อันที่จริง ประวัติการแก้ไขในตอนท้ายของร่างฉบับก่อนหน้า^{[ SAMLMeta 5 ]}แสดงให้เห็นถึงร่องรอยของข้อกำหนดเมตาเดตาที่ย้อนกลับไปถึงเดือนพฤศจิกายน พ.ศ. 2545

จากการติดตามเอกสาร พบว่าอิทธิพลของ Liberty ID-FF ต่อเมตาเดตาของ SAML สามารถสืบย้อนไปถึงร่างข้อกำหนดที่เผยแพร่ในเดือนเมษายน พ.ศ. 2546 ^{[ SAMLMeta 6 ]}นี่คือเอกสาร OASIS ฉบับแรกที่ทราบซึ่งอ้างอิงถึง Liberty ID-FF โดยเฉพาะอย่างยิ่ง Liberty Metadata เวอร์ชัน 1.0-06 ^{[ LibertyMeta 3 ]}ซึ่งเป็นเวอร์ชันแรกๆ ของข้อกำหนด Liberty Metadata ที่มีข้อมูลน้อยมาก อย่างไรก็ตาม เป็นที่ชัดเจนว่า "Metadata for SAML 1.1 Web Browser Profiles" มีจุดประสงค์เพื่อใช้ควบคู่กับมาตรฐาน SAML V1.1 แต่แน่นอนว่าเรารู้ว่า V1.1 ไม่ได้ระบุการใช้เมตาเดตา ดูส่วนถัดไปสำหรับข้อสันนิษฐานที่เกี่ยวข้อง

รูปแบบโครงสร้างข้อมูลเมตาเบื้องต้นสองแบบอาจเป็นที่น่าสนใจ:

1. ในเดือนมิถุนายน ปี 2002 เพียงหนึ่งเดือนหลังจากที่ SSTC เสร็จสิ้นการทำงานในสิ่งที่ต่อมากลายเป็นมาตรฐาน SAML V1.0 โครงการ Shibbolethได้พัฒนาสคีมาเมตาเดตาที่ประกอบด้วย องค์ประกอบ <OriginSite>ต่างๆ<DestinationSite>สคีมานี้จะเป็นตัวขับเคลื่อนเวอร์ชันเริ่มต้นของซอฟต์แวร์ Shibboleth IdP
2. ในเดือนกุมภาพันธ์ พ.ศ. 2546 SSTC ได้เผยแพร่ร่างโครงร่างสำหรับข้อกำหนดเมตาเดตาชื่อ "เมตาเดตาสำหรับโปรไฟล์เว็บเบราว์เซอร์ SAML 1.0" ^{[ SAMLMeta 7 ]}อย่างไรก็ตาม โครงร่างดังกล่าวยังคงเป็นสิ่งที่น่าสนใจ เนื่องจากเวอร์ชันถัดไปของเอกสารชุดนั้น (และเวอร์ชันต่อๆ ไปทั้งหมด) จะแสดงไวยากรณ์เมตาเดตาของ Liberty

ไม่มีหลักฐานใดบ่งชี้ว่าความพยายามในช่วงแรกทั้งสองครั้งในการกำหนดโครงสร้างเมตาเดตาจะมีผลกระทบอย่างมีนัยสำคัญต่อการพัฒนาโครงสร้างเมตาเดตาของ Liberty

เราทราบว่ามาตรฐานเมตาเดตาสำหรับ SAML V1.0 หรือ SAML V1.1 ไม่เคยได้รับการเผยแพร่ และเราทราบด้วยว่าสิทธิในทรัพย์สินทางปัญญาที่จำเป็นสำหรับ Liberty Metadata ยังไม่มีผลบังคับใช้จนกระทั่งเดือนพฤศจิกายน 2546 ด้วยเหตุนี้ เราจึงขอเสนอบทสรุปและการคาดการณ์ดังต่อไปนี้:

1. เอกสารร่างข้อกำหนดชื่อ "Metadata for SAML 1.0 Web Browser Profiles" ^{[ SAMLMeta 8 ]}เป็นข้อกำหนดเมตาเดตา SAML ฉบับแรกที่รู้จักกัน เอกสารฉบับนี้ลงวันที่ 12 พฤศจิกายน 2545 ซึ่งเป็นเวลาหนึ่งสัปดาห์หลังจากที่มาตรฐาน SAML V1.0 ได้รับการประกาศ ซึ่งเป็นเรื่องที่น่าแปลกใจ ในทุกกรณี ไวยากรณ์เมตาเดตาที่ใช้ในเอกสารนั้นแตกต่างอย่างสิ้นเชิงจากสิ่งที่เราเรียกว่าเมตาเดตา SAML ในปัจจุบัน เอกสารฉบับนั้นไม่เคยได้รับการเผยแพร่ และที่มาของมันยังคงเป็นปริศนา
2. ร่างข้อกำหนดชื่อ "Metadata for SAML 1.1 Web Browser Profiles" ^{[ SAMLMeta 6 ]}เป็นข้อกำหนดเมตาเดตา SAML ฉบับแรกที่รู้จักกันซึ่งอิงตาม Liberty ID-FF โดยเสร็จสมบูรณ์ในเดือนเมษายน พ.ศ. 2546 ชื่อของร่างข้อกำหนดแสดงให้เห็นอย่างชัดเจนว่า SSTC ทราบว่า SAML V1.1 กำลังจะมาถึง และยิ่งไปกว่านั้น เมตาเดตา SAML จะถูกรวมอยู่ในมาตรฐาน SAML V1.1 ด้วย
3. น่าเสียดายที่เหตุการณ์นั้นไม่ได้เกิดขึ้น เนื่องจากสิทธิในทรัพย์สินทางปัญญาที่จำเป็นยังไม่พร้อมเมื่อมีการประกาศมาตรฐาน SAML V1.1 อันที่จริงการมีส่วนร่วมอย่างเป็นทางการของ Liberty ID-FF 1.2 ใน OASISเกิดขึ้นสองเดือนหลังจากที่มีการประกาศมาตรฐาน SAML V1.1 ในเดือนกันยายน พ.ศ. 2546
4. ในเดือนกันยายน พ.ศ. 2546 ไม่ถึงสองสัปดาห์หลังจากประกาศมาตรฐาน SAML V1.1 SSTC ก็ได้มุ่งเป้าไปที่ SAML V2.0 โดยแยกเอกสารฉบับร่างออกและเปลี่ยนชื่อเป็น "Metadata for SAML 2.0 Web Browser Profiles" ^{[ SAMLMeta 4 ]}
5. ข้อมูลเมตาของ SAML เริ่มใช้งานระหว่างเดือนมีนาคมถึงกรกฎาคม พ.ศ. 2547 SSTC ได้ออกประกาศขอความคิดเห็นจากสาธารณะซึ่งรวมถึงข้อกำหนดข้อมูลเมตาของ SAML ฉบับร่าง^{[ SAMLMeta 2 ]}
6. ข้อกำหนดเมตาเดตา SAML ฉบับสุดท้าย^{[ OS 1 ]}ถูกรวมอยู่ในชุดข้อกำหนดมาตรฐาน SAML V2.0 ที่ประกาศในเดือนมีนาคม พ.ศ. 2548
7. ตลอด 10 ปีถัดมา เอกสารข้อกำหนดได้มีการพัฒนา (แต่โครงสร้างยังคงเสถียร) ข้อกำหนดสำหรับเมตาเดตา SAML V2.0 พร้อมการแก้ไขข้อผิดพลาด (SAMLMeta20Errata ^{[ OS 3 ]} ) ได้รับการเผยแพร่ในเดือนกันยายน 2015

ดังที่กล่าวไว้ก่อนหน้านี้ โครงสร้างเมตาเดตา SAML V2.0 ^{[ OS 4 ]}มีจุดขยายมากมาย คุณสมบัตินี้ทำให้เกิดข้อกำหนด "หลัง V2.0" จำนวนมากที่ขยายมาตรฐานไปในหลายทิศทาง ส่วนขยายเมตาเดตาที่ได้รับความนิยมมากกว่าจะแสดงไว้ด้านล่างเพื่อความสะดวก (ดูตัวอย่างสำหรับกรณีการใช้งานเฉพาะ):

1. ส่วนขยายเมตาเดตา SAML V2.0 สำหรับข้อมูลการลงทะเบียนและการเผยแพร่ เวอร์ชัน 1.0 ^{[ CS 1 ]}
2. ส่วนขยายเมตาเดตา SAML V2.0 สำหรับแอตทริบิวต์ของเอนทิตี^{[ CS 2 ]}
3. ส่วนขยายเมตาเดต้า SAML V2.0 สำหรับส่วนติดต่อผู้ใช้การเข้าสู่ระบบและการค้นหา เวอร์ชัน 1.0 ^{[ CS 3 ]}
4. โปรโตคอลและโปรไฟล์บริการค้นหาผู้ให้บริการข้อมูลประจำตัว^{[ CS 4 ]}
5. โปรโตคอลการเริ่มต้นคำขอของผู้ให้บริการและโปรไฟล์เวอร์ชัน 1.0 ^{[ CS 5 ]}
6. โปรไฟล์เมตาเดต้า SAML V2.0 สำหรับการสนับสนุนอัลกอริทึม เวอร์ชัน 1.0 ^{[ CS 6 ]}

ข้อกำหนด "หลัง V2.0" ที่สำคัญคือSAML V2.0 Metadata Interoperability Profile ^{[ CS 7 ]}ซึ่งสร้างขึ้นบนสมมติฐานที่ว่าโครงสร้างพื้นฐานกุญแจสาธารณะ (PKI) อย่างเป็นทางการนั้นอาจมีความซับซ้อนอย่างมากและในบางกรณีก็แก้ไขได้ยาก (ตัวอย่างเช่น เป็นที่ทราบกันดีว่าการเพิกถอนใบรับรอง TLS ที่เบราว์เซอร์ใช้งานไม่ได้^{[ Misc 1 ]} ) โดยพื้นฐานแล้วMetadata Interoperability Profileเป็นความพยายามที่จะจัดหากลไกการเพิกถอนกุญแจที่ใช้งานได้สำหรับสหพันธ์ SAML

นับตั้งแต่มีการเผยแพร่ในเดือนสิงหาคม พ.ศ. 2552 เอกสารMetadata Interoperability Profileได้กลายเป็นเอกสารที่มีอิทธิพลอย่างมาก โดยเฉพาะอย่างยิ่งในระดับอุดมศึกษา (ดูตัวอย่างเช่น ข้อกำหนดที่เกี่ยวข้องกับใบรับรองสำหรับผู้ใช้งาน^{[ Misc 2 ]}ในกลุ่มสถาบันวิจัยและพัฒนาขนาดใหญ่แห่งหนึ่ง) ความสามารถในการทำงานร่วมกันของเมตาเดตามีบทบาทสำคัญในโปรไฟล์การใช้งานอย่างเป็นทางการที่เผยแพร่โดย Kantara Initiative:

การใช้งานจะต้องรองรับการตีความและการประยุกต์ใช้เมตาเดตาตามที่กำหนดไว้ในโปรไฟล์การทำงานร่วมกันของเมตาเดตา SAML V2.0 ดังนั้น การใช้งานจะต้องสามารถทำงานร่วมกันได้ (ซึ่งจะนำไปสู่ความสำเร็จหรือความล้มเหลวตามที่กำหนดโดยการกำหนดค่าเริ่มต้น) กับ SAML peer จำนวนเท่าใดก็ได้ที่มีเมตาเดตา โดยไม่ต้องมีการป้อนข้อมูลเพิ่มเติมหรือการกำหนดค่าแยกต่างหาก^{[ Misc 3 ]}

อันที่จริง คุณสมบัติสำคัญที่ทำให้การใช้งาน SAML ที่ปรับขนาดได้แตกต่างออกไป (จากการใช้งานที่ไม่สามารถปรับขนาดได้) คือความสามารถในการทำงานร่วมกันของเมตาเดตา

ในส่วนนี้ เราจะยกตัวอย่างที่เป็นรูปธรรมของ ตัวอธิบายเอนทิตี SAML ซึ่ง เป็นหน่วยพื้นฐานของนโยบายและความสามารถในการทำงานร่วมกันในเมตาเดตา SAML ตัวอย่างแต่ละตัวอย่างประกอบด้วยบิตเมตาเดตาต่อไปนี้:

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

ในตัวอย่างด้านล่างนี้ URI เฉพาะในเมตาเดตา (เช่น URL entityIDหรือตำแหน่งที่ตั้งปลายทาง) จะเชื่อมโยงกับผู้รับผิดชอบผ่านส่วนประกอบโดเมนของ URI นั้น:

• องค์กรที่เป็นเจ้าของโดเมนexample.infoมีหน้าที่รับผิดชอบต่อเอนทิตี SAML ที่ไม่ได้ระบุ (เช่น ผู้ให้บริการข้อมูลประจำตัวหรือผู้ให้บริการ)
• องค์กรที่เป็นเจ้าของโดเมนexample.orgมีหน้าที่รับผิดชอบในการจัดหาผู้ให้บริการยืนยันตัวตน SAML
• องค์กรที่เป็นเจ้าของโดเมนexample.comมีหน้าที่รับผิดชอบในการให้บริการ SAML
• องค์กรที่เป็นเจ้าของโดเมนexample.netเป็นบุคคลที่สามที่น่าเชื่อถือ ซึ่งรับผิดชอบในการลงทะเบียนและเผยแพร่ข้อมูลเมตา

โปรดทราบว่าเมตาเดตาของ SAML อธิบายถึงทุกฝ่ายที่เกี่ยวข้องในการเข้าสู่ระบบแบบ Single Sign-On (SSO) ของเว็บเบราว์เซอร์ SAML ที่ขับเคลื่อนด้วยเมตาเดตา ยกเว้นผู้ใช้เบราว์เซอร์ (ดูข้อมูลเพิ่มเติมเกี่ยวกับการเข้าสู่ระบบแบบ Single Sign-On (SSO) ของเว็บเบราว์เซอร์ SAML ได้ในข้อกำหนด SAML V2.0 Profiles ^{[ OS 2 ] )}

ตัวอย่างโค้ดต่อไปนี้แสดงให้เห็นถึงคุณลักษณะทางเทคนิคทั่วไปของ<md:EntityDescriptor>องค์ประกอบ SAML:

<md:EntityDescriptor entityID= "https://sso.example.info/entity" validUntil= "2017-08-30T19:10:29Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:mdrpi= "urn:oasis:names:tc:SAML:metadata:rpi" xmlns:mdattr= "urn:oasis:names:tc:SAML:metadata:attribute" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- แทรกองค์ประกอบ ds:Signature (ละไว้) --> <md:Extensions> <mdrpi:RegistrationInfo registrationAuthority= "https://registrar.example.net" /> <mdrpi:PublicationInfo creationInstant= "2017-08-16T19:10:29Z" publisher= "https://registrar.example.net" /> <mdattr:EntityAttributes> <saml:Attribute Name= "http://registrar.example.net/entity-category" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml:AttributeValue> https://registrar.example.net/category/self-certified </saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> </md:Extensions> <!-- แทรกอินสแตนซ์ที่เป็นรูปธรรมอย่างน้อยหนึ่งรายการของประเภทนามธรรม md:RoleDescriptor (ดูด้านล่าง) --> <md:Organization> < md:OrganizationName xml:lang= "en" > ... </md:OrganizationName> <md: OrganizationDisplayName xml:lang= "en" > ... </md:OrganizationDisplayName> <md:OrganizationURL xml:lang= "en" > https://www.example.info/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName>ฝ่ายสนับสนุนด้านเทคนิคSAML </md:SurName> <md:EmailAddress> mailto:[email protected] </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

โปรดสังเกตรายละเอียดต่อไปนี้เกี่ยวกับคำอธิบายเอนทิตีทั่วไปนี้:

• แอตทริบิวต์ นี้entityIDคือตัวระบุเฉพาะของเอนทิตี โปรดทราบว่านี่entityIDคือชื่อที่ไม่สามารถเปลี่ยนแปลงได้ของเอนทิตี ไม่ใช่ตำแหน่งที่ตั้ง
• คุณลักษณะ นี้validUntilระบุวันหมดอายุของข้อมูลเมตา
• องค์ประกอบ<ds:Signature>ดังกล่าว (ซึ่งถูกละเว้นเพื่อความง่าย) ประกอบด้วยลายเซ็นดิจิทัลที่รับรองความถูกต้องและความสมบูรณ์ของข้อมูลเมตา โดยสันนิษฐานว่าผู้ลงนามคือบุคคลที่สามที่น่าเชื่อถือซึ่งเรียกว่าผู้จดทะเบียนข้อมูลเมตา
• องค์ประกอบ<mdrpi:RegistrationInfo>ส่วนขยาย^{[ CS 1 ]}ยืนยันตัวระบุสำหรับผู้ลงทะเบียนข้อมูลเมตา
• องค์ประกอบ<mdrpi:PublicationInfo>ส่วนขยาย^{[ CS 1 ]}ยืนยันผู้เผยแพร่เมตาเดตา (ซึ่งก็คือผู้จดทะเบียนนั่นเอง) creationInstantคุณลักษณะนี้ให้เวลาที่แน่นอนในการสร้างเมตาเดตา เมื่อเปรียบเทียบค่าของcreationInstantคุณลักษณะกับค่าของvalidUntilคุณลักษณะ เราจะเห็นว่าเมตาเดตามีอายุใช้งานได้สองสัปดาห์
• องค์ประกอบ<mdattr:EntityAttributes>ส่วนขยาย^{[ CS 2 ]}ประกอบด้วยคุณลักษณะเอนทิตีเดียว คุณลักษณะเอนทิตีระบุว่าเอนทิตีนั้น "ได้รับการรับรองตนเอง" ซึ่งเป็นคุณสมบัติที่พึงประสงค์
• องค์กรที่ระบุใน<md:Organization>องค์ประกอบนั้น "รับผิดชอบต่อหน่วยงาน" ที่อธิบายโดยตัวอธิบายหน่วยงาน (ส่วนที่ 2.3.2 ของ SAMLMeta ^{[ OS 3 ]} ) <md:Organization>องค์ประกอบนี้ประกอบด้วยองค์ประกอบย่อยที่มีคุณสมบัติทางภาษาอย่างน้อยหนึ่งรายการของแต่ละประเภท
• ข้อมูลติดต่อใน<md:ContactPerson>องค์ประกอบนี้ระบุผู้ติดต่อทางเทคนิคที่รับผิดชอบหน่วยงานนั้น ๆ สามารถมีผู้ติดต่อและประเภทผู้ติดต่อได้หลายราย ดูหัวข้อ 2.3.2.2 ของ SAMLMeta ^{[ OS 3 ]}

เพื่อความกระชับ จึงได้ละเว้นคำอธิบายบทบาทที่สำคัญยิ่งนี้จากตัวอย่างเริ่มต้นนี้ ข้อกำหนดเมตาเดตาของ SAML กำหนดอินสแตนซ์ที่เป็นรูปธรรมจำนวนมากของ ประเภทนามธรรม md:RoleDescriptor (ส่วนที่ 2.4.1 ของ SAMLMeta ^{[ OS 3 ]} ) บทบาทที่สำคัญที่สุดสองบทบาทนั้นอธิบายโดย<md:IDPSSODescriptor>องค์ประกอบ <roleDescriptor> และ<md:SPSSODescriptor>องค์ประกอบ <roleDescriptor> คำอธิบายบทบาทแต่ละรายการจะแสดงอยู่ในส่วนย่อยด้านล่าง

ผู้ให้บริการข้อมูลประจำตัว SAMLจัดการจุดสิ้นสุดบริการ Single Sign-On ^{[ OS 2 ]}ที่รับคำขอการตรวจสอบสิทธิ์จากผู้ให้บริการ คำอธิบายเอนทิตีสำหรับผู้ให้บริการข้อมูลประจำตัวในบทบาทนั้นประกอบด้วย<md:IDPSSODescriptor>องค์ประกอบ ซึ่งตัวมันเองมีจุดสิ้นสุดอย่างน้อยหนึ่ง<md:SingleSignOnService>จุด ตัวอย่างต่อไปนี้แสดงจุดสิ้นสุดดังกล่าวสองจุด:

<md:EntityDescriptor entityID= "https://sso.example.org/idp" validUntil= "2017-08-30T19:10:29Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:mdrpi= "urn:oasis:names:tc:SAML:metadata:rpi" xmlns:mdattr= "urn:oasis:names:tc:SAML:metadata:attribute" xmlns:mdui= "urn:oasis:names:tc:SAML:metadata:ui" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- แทรกองค์ประกอบ ds:Signature (ละไว้) --> <md:Extensions> <mdrpi:RegistrationInfo registrationAuthority= "https://registrar.example.net" /> <mdrpi:PublicationInfo creationInstant= "2017-08-16T19:10:29Z" publisher= "https://registrar.example.net" /> <mdattr:EntityAttributes> <saml:Attribute Name= "http://registrar.example.net/entity-category" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml:AttributeValue> https://registrar.example.net/category/self-certified </saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> </md:Extensions> <md:IDPSSODescriptor protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:Extensions> <mdui:UIInfo> <mdui:DisplayName xml:lang= "en" > Example.org </mdui:DisplayName> <mdui:Description xml:lang= "en" >ผู้ให้บริการข้อมูลประจำตัวที่Example.org </mdui:Description> <mdui:Logo height= "32" width= "32" xml:lang= "en" > https://idp.example.org/myicon.png </mdui:Logo> </mdui:UIInfo> </md:Extensions> <md:KeyDescriptor use= "signing" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= "https://idp.example.< md : Organization >​​​​<md:OrganizationName xml:lang= "en" > Example.org องค์กรไม่แสวงหาผลกำไร</ md: OrganizationName> < md:OrganizationDisplayName xml:lang= "en" > Example.org </md:OrganizationDisplayName> <md:OrganizationURL xml:lang= "en" > https://www.example.org/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName>ฝ่ายสนับสนุนด้านเทคนิคSAML </md:SurName> <md:EmailAddress> mailto:[email protected] </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

เนื้อหาของ<md:IDPSSODescriptor>องค์ประกอบนี้อธิบายถึงบริการ Single Sign-On (SSO) ที่ผู้ให้บริการยืนยันตัวตน โปรดสังเกตรายละเอียดต่อไปนี้เกี่ยวกับองค์ประกอบนี้:

• คอนเทนเนอร์^{[ CS 3 ]}<mdui:UIInfo> ประกอบด้วยชุดขององค์ประกอบส่วนขยายที่มีคุณสมบัติทางภาษาซึ่งใช้ในการสร้างอินเทอร์เฟซผู้ใช้แบบไดนามิกที่ผู้ให้บริการ อินเทอร์เฟซผู้ใช้ที่สำคัญที่สุดที่ผู้ให้บริการคืออินเทอร์เฟซการค้นหาผู้ให้บริการข้อมูลประจำตัว
• ซอฟต์แวร์ผู้ให้บริการยืนยันตัวตนน่าจะได้รับการกำหนดค่าด้วยคีย์ลงนาม SAML ส่วนตัว คีย์สาธารณะที่เกี่ยวข้องจะรวมอยู่ใน<md:KeyDescriptor use="signing">องค์ประกอบนั้น ในตัวอย่างข้างต้น ข้อมูลคีย์ถูกละเว้นจากคำอธิบายคีย์เพื่อความกระชับ
• คุณลักษณะBindingของ<md:SingleSignOnService>องค์ประกอบต่างๆ คือ URI มาตรฐานที่ระบุไว้ในข้อกำหนด SAML 2.0 Binding (SAMLBind ^{[ OS 5 ]} )

ค่าของmd:SingleSignOnService/@Locationแอตทริบิวต์ในเมตาเดตาของผู้ให้บริการยืนยันตัวตนจะถูกใช้โดยผู้ให้บริการเพื่อกำหนดเส้นทางการส่งข้อความ SAML ซึ่งช่วยลดโอกาสที่ผู้ให้บริการยืนยันตัวตนที่ไม่ประสงค์ดีจะทำการโจมตีแบบคนกลาง (man-in-the-middle attack )

ผู้ให้บริการ SAMLจะจัดการเอนด์พอยต์ Assertion Consumer Service ^{[ OS 2 ]}ที่รับการยืนยันการตรวจสอบสิทธิ์จากผู้ให้บริการข้อมูลประจำตัว ตัวอธิบายเอนทิตีสำหรับผู้ให้บริการในบทบาทนั้นจะมี<md:SPSSODescriptor>องค์ประกอบ ซึ่งตัวมันเองจะมีเอนด์พอยต์อย่างน้อยหนึ่ง<md:AssertionConsumerService>รายการ ตัวอย่างต่อไปนี้แสดงให้เห็นถึงเอนด์พอยต์ดังกล่าว:

<md:EntityDescriptor entityID= "https://sso.example.com/portal" validUntil= "2017-08-30T19:10:29Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:mdrpi= "urn:oasis:names:tc:SAML:metadata:rpi" xmlns:mdattr= "urn:oasis:names:tc:SAML:metadata:attribute" xmlns:mdui= "urn:oasis:names:tc:SAML:metadata:ui" xmlns:idpdisc= "urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- แทรกองค์ประกอบ ds:Signature (ละไว้) --> <md:Extensions> <mdrpi:RegistrationInfo registrationAuthority= "https://registrar.example.net" /> <mdrpi:PublicationInfo creationInstant= "2017-08-16T19:10:29Z" publisher= "https://registrar.example.net" /> <mdattr:EntityAttributes> <saml:Attribute Name= "http://registrar.example.net/entity-category" NameFormat= <md:Extensions> <md: SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration = " urn:oasis:names :tc:SAML:2.0: attrname-format:uri" > <mdui:UIInfo> < mdui : DisplayName xml : lang = "en" >บริการผู้ขายExample.com </mdui:DisplayName> < mdui : InformationURL xml : lang= "en " > https://service.example.com/about.html </mdui:InformationURL> <mdui:PrivacyStatementURL xml:lang= "en" > https://service.example.com/privacy.html </mdui:PrivacyStatementURL> <mdui:โลโก้height= "32" width= "32" xml:lang= "en" > https://service.example.com/myicon.png </mdui:Logo> </mdui:UIInfo> <idpdisc:< md:Extensions> <md: KeyDescriptor use= "encryption" /> <md :Extensions> <md:KeyDescriptor use = "encryption" /> <md:Extensions> <md:KeyDescriptor use= "encryption" />> <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> <md:AssertionConsumerService index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "https://service.example.com/SAML2/SSO/POST" /> <md:AttributeConsumingService index= "0" > <md:ServiceName xml:lang= "en" > Example.com Employee Portal </md:ServiceName> <md :RequestedAttribute isRequired= "true" NameFormat= " <md:RequestedAttribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.5923.1.1.1.13" FriendlyName= "eduPersonUniqueId" /> <md:RequestedAttribute NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:0.9.2342.19200300.100.1.3" FriendlyName= "mail" /> </md:AttributeConsumingService> </md:SPSSODescriptor> <md:Organization> <md:OrganizationName xml:lang= "en" > Example.com Inc. </md:OrganizationName> <md:OrganizationDisplayName xml:lang= "en" > Example.com </md:OrganizationDisplayName> <md:OrganizationURL xml:lang= "en" > https://www.example.com/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName>ฝ่ายสนับสนุนด้านเทคนิคSAML </md:SurName> <md:EmailAddress> mailto:[email protected] </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

เนื้อหาของ<md:SPSSODescriptor>องค์ประกอบนี้อธิบายถึงบริการผู้บริโภคการยืนยัน (Assertion Consumer Service) ที่ผู้ให้บริการ โปรดสังเกตรายละเอียดต่อไปนี้เกี่ยวกับองค์ประกอบนี้:

• แอตทริบิวต์WantAssertionsSignedบน<md:SPSSODescriptor>องค์ประกอบนี้ประกาศว่าผู้ให้บริการต้องการให้<saml:Assertion>องค์ประกอบนั้นได้รับการลงลายมือชื่อดิจิทัล แอตทริบิวต์นี้ทำให้ผู้ให้บริการข้อมูลประจำตัวที่รับรู้เมตาเดตาทำการกำหนดค่าตัวเองโดยอัตโนมัติในระหว่างการทำงาน
• องค์ประกอบ<mdui:UIInfo>ส่วนขยาย^{[ CS 3 ]}ประกอบด้วยชุดขององค์ประกอบส่วนขยายที่มีคุณสมบัติทางภาษาซึ่งใช้ในการสร้างส่วนติดต่อผู้ใช้แบบไดนามิกที่ผู้ให้บริการข้อมูลประจำตัว ส่วนติดต่อผู้ใช้ที่สำคัญสองส่วนที่ผู้ให้บริการข้อมูลประจำตัวคือหน้าเข้าสู่ระบบและส่วนติดต่อขอความยินยอมจากผู้ใช้
• องค์ประกอบ<idpdisc:DiscoveryResponse>ส่วนขยาย^{[ CS 4 ]}กำหนดเอนด์พอยต์ที่ใช้ร่วมกับการค้นหาผู้ให้บริการข้อมูลประจำตัว
• ซอฟต์แวร์ของผู้ให้บริการน่าจะถูกกำหนดค่าด้วยคีย์ถอดรหัส SAML ส่วนตัว คีย์เข้ารหัส SAML สาธารณะจะรวมอยู่ใน<md:KeyDescriptor use="encryption">องค์ประกอบนั้น ในตัวอย่างข้างต้น ข้อมูลคีย์ถูกละเว้นจากคำอธิบายคีย์เพื่อความกระชับ
• องค์ประกอบ นี้<md:NameIDFormat>กำหนดรูปแบบที่ต้องการของ<saml:NameID>องค์ประกอบในคำยืนยัน SAML การมีอยู่ขององค์ประกอบนี้ทำให้ผู้ให้บริการข้อมูลประจำตัวที่รับรู้เมตาเดตาทำการกำหนดค่าตัวเองโดยอัตโนมัติในระหว่างการทำงาน
• แอตทริบิวต์indexของ<md:AssertionConsumerService>องค์ประกอบจะถูกใช้เป็นค่าของAssertionConsumerServiceIndexแอตทริบิวต์ใน<samlp:AuthnRequest>องค์ประกอบ นั้น
• คุณลักษณะBindingของ<md:AssertionConsumerService>องค์ประกอบคือ URI มาตรฐานที่ระบุไว้ในข้อกำหนด SAML 2.0 Binding (SAMLBind ^{[ OS 5 ]} )
• องค์ประกอบ นี้<md:AttributeConsumingService>ถูกใช้โดยผู้ให้บริการยืนยันตัวตนเพื่อสร้าง<saml:AttributeStatement>องค์ประกอบที่จะถูกส่งไปยังผู้ให้บริการร่วมกับ SAML Web Browser SSO
• แอตทริบิวต์indexของ<md:AttributeConsumingService>องค์ประกอบจะถูกใช้เป็นค่าของAttributeConsumingServiceIndexแอตทริบิวต์ใน<samlp:AuthnRequest>องค์ประกอบ นั้น

ค่าของmd:AssertionConsumerService/@Locationแอตทริบิวต์ในเมตาเดตาของผู้ให้บริการจะถูกใช้โดยผู้ให้บริการข้อมูลประจำตัวเพื่อกำหนดเส้นทางการส่งข้อความ SAML ซึ่งช่วยลดความเป็นไปได้ที่ผู้ให้บริการที่ไม่ประสงค์ดีจะทำการโจมตีแบบคนกลาง (man-in-the-middle attack )

ลำดับขั้นตอนโปรโตคอล SAML ต่อไปนี้มีจุดประสงค์เพื่อแสดงให้เห็นถึงการใช้เมตาเดตาในขั้นตอนต่างๆ ของการเข้าสู่ระบบแบบ Single Sign-On (SSO) ของเว็บเบราว์เซอร์ SAML (ดูข้อมูลเพิ่มเติมเกี่ยวกับการเข้าสู่ระบบแบบ Single Sign-On (SSO) ของเว็บเบราว์เซอร์ SAML ได้ในข้อกำหนด SAML V2.0 Profiles ^{[ OS 2 ]} )

เมตาเดตา SAML ที่เชื่อถือได้ช่วยให้มั่นใจได้ถึงการทำธุรกรรมที่ปลอดภัยระหว่างผู้ให้บริการข้อมูลประจำตัว SAML (IdP) และผู้ให้บริการบริการ SAML (SP) ก่อนที่จะมีเมตาเดตา ข้อมูลความน่าเชื่อถือจะถูกเข้ารหัสไว้ในการใช้งานในลักษณะที่เป็นกรรมสิทธิ์ ปัจจุบันการแบ่งปันข้อมูลความน่าเชื่อถือทำได้ง่ายขึ้นด้วยเมตาเดตามาตรฐาน มาตรฐานเมตาเดตา SAML 2.0 ^{[ OS 3 ]}ให้รูปแบบเมตาเดตาที่กำหนดไว้อย่างดีและสามารถทำงานร่วมกันได้ ซึ่งหน่วยงานต่างๆ สามารถใช้เพื่อเริ่มต้นกระบวนการความน่าเชื่อถือได้

ลำดับต่อไปนี้แสดงให้เห็นถึงการใช้เมตาเดต้า SAML เพื่อขับเคลื่อนกระบวนการทำงานของโปรโตคอล SAML

ผู้ใช้งานเบราว์เซอร์ร้องขอทรัพยากรแอปพลิเคชันเว็บที่ได้รับการปกป้องโดยผู้ให้บริการ SAML:

https://sp.example.com/myresource 

หากบริบทด้านความปลอดภัยที่ถูกต้องสำหรับผู้ใช้หลักมีอยู่แล้วที่ผู้ให้บริการ ให้ข้ามขั้นตอนที่ 2–13

ก่อนที่ผู้ให้บริการจะเริ่มต้นกระบวนการโปรโตคอล SAML ในขั้นตอนที่ 6 จะต้องทราบผู้ให้บริการยืนยันตัวตนที่ผู้ใช้เบราว์เซอร์ต้องการก่อน มีหลายวิธีในการทำเช่นนี้ เพื่อเป็นตัวอย่าง ผู้ให้บริการจะใช้บริการค้นหาในพื้นที่ซึ่งสอดคล้องกับโปรโตคอลและโปรไฟล์บริการค้นหาผู้ให้บริการยืนยันตัวตน^{[ CS 4 ]}

ผู้ให้บริการจะเปลี่ยนเส้นทางผู้ใช้เบราว์เซอร์ไปยังบริการค้นหา (Discovery Service):

การเปลี่ยนเส้นทาง 302 ตำแหน่ง: https://ds.example.com/idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal

โปรดทราบว่า SP entityIDจะถูกรวมอยู่ใน URL การเปลี่ยนเส้นทางตามที่ระบุไว้ในโปรโตคอลการค้นหา

ผู้ใช้เบราว์เซอร์ร้องขอการเข้าถึงบริการค้นหา (Discovery Service) โดยอาศัยการเปลี่ยนเส้นทาง:

GET /idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal HTTP / 1.1 Host : ds.example.com

(ค้นหาผู้ให้บริการยืนยันตัวตน (IdP) ที่ผู้ใช้ต้องการ)

บริการค้นหาจะค้นหาผู้ให้บริการยืนยันตัวตนที่ผู้ใช้เบราว์เซอร์ต้องการโดยใช้วิธีการที่ไม่ระบุแน่ชัด

ขณะนี้บริการค้นหา (Discovery Service) จะเปลี่ยนเส้นทางผู้ใช้เบราว์เซอร์ไปยังปลายทางตอบสนองการค้นหา (Discovery Response endpoint) ที่ผู้ให้บริการ:

302 Redirect Location: https://sp.example.com/SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp

โปรดทราบว่า IdP entityIDจะถูกรวมอยู่ใน URL การเปลี่ยนเส้นทางตามที่ระบุไว้ในโปรโตคอลการค้นหา

ผู้ใช้เบราว์เซอร์ร้องขอไปยังเอนด์พอยต์ Discovery Response ที่ผู้ให้บริการโดยอาศัยการเปลี่ยนเส้นทาง:

GET /SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp HTTP / 1.1 Host : sp.example.com

จุดสิ้นสุดการตอบสนองการค้นหาที่ผู้ให้บริการเป็นไปตามโปรโตคอลและโปรไฟล์บริการการค้นหาผู้ให้บริการข้อมูลประจำตัว^{[ CS 4 ]}

ผู้ให้บริการจะสร้าง<samlp:AuthnRequest>องค์ประกอบที่เกี่ยวข้อง เข้ารหัสคำขอ SAML ในสตริงคำค้นหา URL จากนั้นเปลี่ยนเส้นทางผู้ใช้เบราว์เซอร์ไปยังบริการ Single Sign-On ที่ผู้ให้บริการยืนยันตัวตน:

302 Redirect Location: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

สำหรับโครงร่างวิธีการสร้างสตริงคำค้นหา โปรดดูขั้นตอนการทำงานของโปรโตคอล SAML ที่เกี่ยวข้อง ในบทความ SAML 2.0 อ้างอิงถึง SAMLCore ^{[ OS 6 ]}สำหรับรายละเอียดเพิ่มเติม

ผู้ใช้เบราว์เซอร์ร้องขอไปยังปลายทางบริการ Single Sign-On ที่ผู้ให้บริการยืนยันตัวตนโดยอาศัยการเปลี่ยนเส้นทาง:

GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP / 1.1 Host : idp.example.org

ผู้ให้บริการยืนยันตัวตนจะส่งหน้าเข้าสู่ระบบกลับไปยังเบราว์เซอร์ของผู้ใช้ หน้าเข้าสู่ระบบประกอบด้วยแบบฟอร์ม HTML ที่คล้ายกับตัวอย่างต่อไปนี้:

< form method = " post " action = "https://idp.example.com/login-response" ... > ชื่อผู้ใช้: <br> < input type = "text" name = " username " > <br> รหัส ผ่าน : <br> < input type = "password" name = " password" > ... < input type = "submit" value = " Submit" / > </form>

ผู้ใช้งานเบราว์เซอร์ส่งแบบฟอร์ม HTML ไปยังผู้ให้บริการยืนยันตัวตน:

POST /login-response HTTP / 1.1 Host : idp.example.com Content-Type : application/x-www-form-urlencoded Content-Length : nnn username = username & password = password

(ออก SAML Assertion ให้กับผู้ใช้)

ในขั้นตอนนี้ ผู้ให้บริการข้อมูลประจำตัวทราบข้อมูลประจำตัวของผู้ใช้หลักแล้ว ดังนั้นผู้ให้บริการข้อมูลประจำตัวจึงสร้าง SAML Assertion ในนามของผู้ใช้หลัก สำหรับตัวอย่างที่เป็นรูปธรรมของ Assertion ดังกล่าว โปรดดูขั้นตอนการทำงานของโปรโตคอล SAML ที่เกี่ยวข้อง ในบทความ SAML 2.0 และเช่นเคย โปรดดู SAMLCore ^{[ OS 6 ]}สำหรับรายละเอียดเพิ่มเติม

องค์ประกอบ<saml:NameID>ใน SAML Assertion จะเข้ารหัสตัวระบุสำหรับผู้ใช้หลัก ในกรณีนี้ ผู้ให้บริการข้อมูลประจำตัวจะรวม SAML2 Transient NameID (SAMLCore ^{[ OS 6 ]} ) ไว้ใน SAML Assertion

ผู้ให้บริการยืนยันตัวตนจะรวมคุณลักษณะผู้ใช้สองรายการไว้ใน SAML Assertion ได้แก่ eduPersonUniqueIdและmail

ในทางปฏิบัติ ผู้ให้บริการยืนยันตัวตนจะลงลายมือชื่อดิจิทัลและเข้ารหัส SAML Assertion จากนั้นห่อหุ้ม Assertion ด้วย SAML Response และลงลายมือชื่อในออบเจ็กต์ Response อีกครั้ง โดยปกติแล้วผู้ให้บริการยืนยันตัวตนจะลงลายมือชื่อใน Response เพียงอย่างเดียว แต่ในกรณีนี้ทั้ง Assertion และ Response ต่างก็ได้รับการลงลายมือชื่อดิจิทัลแล้ว

ผู้ให้บริการยืนยันตัวตนจะส่งเอกสาร XHTML กลับไปยังเบราว์เซอร์ของผู้ใช้ เอกสารดังกล่าวประกอบด้วยการตอบสนอง SAML ที่เข้ารหัสในรูปแบบ XHTML ดังต่อไปนี้:

< form method = "post" action = "https://sp.example.com/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLResponse" value = "response" /> < input type = "hidden" name = "RelayState" value = "token" /> ... < input type = "submit" value = " Submit" / > </form>

แบบฟอร์ม XHTML จะถูกส่งโดยอัตโนมัติจากเบราว์เซอร์ (เนื่องจากมีโค้ด JavaScript เล็กน้อยในหน้าเว็บ):

POST /SAML2/SSO/POST HTTP / 1.1 Host : sp.example.com Content-Type : application/x-www-form-urlencoded Content-Length : nnn SAMLResponse = response & RelayState = token

ผู้ให้บริการสร้างบริบทด้านความปลอดภัยสำหรับผู้ใช้หลัก และเปลี่ยนเส้นทางผู้ใช้เบราว์เซอร์ไปยังทรัพยากรเว็บแอปพลิเคชันดั้งเดิม:

การเปลี่ยนเส้นทาง 302 ไปยังตำแหน่ง: https://sp.example.com/myresource

ในที่สุด ผู้ใช้เบราว์เซอร์จะร้องขอทรัพยากรเป้าหมายจากผู้ให้บริการโดยอาศัยการเปลี่ยนเส้นทาง:

https://sp.example.com/myresource 

เนื่องจากมีบริบทด้านความปลอดภัยอยู่ ผู้ให้บริการจึงส่งคืนทรัพยากรไปยังตัวแทนผู้ใช้เบราว์เซอร์ตามที่ร้องขอ

• ภาษาการยืนยันความปลอดภัย (SAML)
• SAML 2.0
• XML (ภาษามาร์กอัปที่ขยายได้)
• XML Schema (W3C)
• ลายเซ็น XML
• การเข้ารหัส XML