SAML 2.0

ภาษามาร์กอัปการยืนยันความปลอดภัย ( SAML ) 2.0เป็นเวอร์ชันของ มาตรฐาน SAMLสำหรับการแลกเปลี่ยน ข้อมูลประจำตัว การตรวจสอบ สิทธิ์ และการอนุญาตระหว่างโดเมนความปลอดภัย SAML 2.0 เป็นโปรโตคอลแบบXMLที่ใช้โทเค็นความปลอดภัยที่มีการยืนยันเพื่อส่งข้อมูลเกี่ยวกับหลักการ (โดยปกติคือผู้ใช้ปลายทาง ) ระหว่างหน่วยงาน SAML ที่เรียกว่าผู้ให้บริการข้อมูลประจำตัวและผู้บริโภค SAML ที่เรียกว่าผู้ให้บริการ SAML 2.0 ช่วยให้สามารถ ลงชื่อเข้าใช้ครั้งเดียว (SSO) ข้ามโดเมนบนเว็บซึ่งช่วยลดภาระการบริหารจัดการในการแจกจ่ายโทเค็นการตรวจสอบสิทธิ์หลายรายการให้กับผู้ใช้ SAML 2.0 ได้รับการรับรองเป็น มาตรฐาน OASISในเดือนมีนาคม 2548 โดยแทนที่SAML 1.1ประเด็นสำคัญของ SAML 2.0 ได้รับการกล่าวถึงโดยละเอียดในเอกสารอย่างเป็นทางการ SAMLCore ^{[ 1 ]} SAMLBind ^{[ 2 ]} SAMLProf ^{[ 3 ]}และ SAMLMeta ^{[ 4 ]}

บุคคลประมาณ 30 คนจากบริษัทและองค์กรมากกว่า 24 แห่งมีส่วนร่วมในการสร้าง SAML 2.0 โดยเฉพาะอย่างยิ่งLiberty Allianceได้บริจาคข้อกำหนด Identity Federation Framework (ID-FF) ให้กับ OASIS ซึ่งกลายเป็นพื้นฐานของข้อกำหนด SAML 2.0 ดังนั้น SAML 2.0 จึงเป็นการรวมกันของSAML 1.1 , Liberty ID-FF 1.2 (เก็บถาวรเมื่อ 2021-02-24 ที่Wayback Machine ) และShibboleth 1.3

ข้อความยืนยัน (Assertion) คือชุดข้อมูลที่ประกอบด้วยข้อความตั้งแต่ศูนย์ข้อความขึ้นไปที่สร้างโดยผู้มีอำนาจ SAML ข้อความยืนยัน SAML มักสร้างขึ้นเกี่ยวกับหัวข้อ (subject) ซึ่งแสดงด้วย<Subject>องค์ประกอบ <subject> ข้อกำหนด SAML 2.0 กำหนดข้อความยืนยันสามประเภทที่ผู้มีอำนาจ SAML สามารถสร้างได้ ข้อความที่กำหนดโดย SAML ทั้งหมดจะเชื่อมโยงกับหัวข้อ ข้อความยืนยันทั้งสามประเภทมีคำจำกัดความดังนี้:

• คำแถลงการยืนยันตัวตน: ผู้ถูกกล่าวอ้างได้รับการยืนยันตัวตนด้วยวิธีการเฉพาะเจาะจงในเวลาที่กำหนด
• ข้อความแสดงคุณลักษณะ: หัวข้อของการยืนยันนั้นเกี่ยวข้องกับคุณลักษณะที่ระบุไว้
• คำแถลงการตัดสินใจเกี่ยวกับการอนุญาต: คำขออนุญาตให้ผู้ถูกกล่าวหาเข้าถึงทรัพยากรที่ระบุได้รับการอนุมัติหรือถูกปฏิเสธ

SAML assertion ประเภทสำคัญอย่างหนึ่งคือ"bearer" assertionซึ่งใช้เพื่ออำนวยความสะดวกในการเข้าสู่ระบบแบบ Single Sign-On (SSO) ผ่านเว็บเบราว์เซอร์ นี่คือตัวอย่างของ bearer assertion ที่มีอายุสั้น ซึ่งออกโดยผู้ให้บริการข้อมูลประจำตัว (https://idp.example.org/SAML2) ให้กับผู้ให้บริการ (https://sp.example.com/SAML2) assertion นี้ประกอบด้วย Authentication Assertion <saml:AuthnStatement>และ Attribute Assertion <saml:AttributeStatement>ซึ่งผู้ให้บริการจะใช้ในการตัดสินใจเกี่ยวกับการควบคุมการเข้าถึง คำนำหน้าsaml:แสดงถึง namespace ของ SAML V2.0 assertion

<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs= "http://www.w3.org/2001/XMLSchema" ID= "_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <saml:Subject> <saml:NameID Format=" "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "aaf23196-1773-2113-474a-fe114412ab72" Recipient= "https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "b07b804c-7c29-ea16-7300-4f3d6f7928ac" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext ></saml:AuthnStatement > <saml:AttributeStatement> <saml:Attribute xmlns:x500= "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" x500:Encoding= "LDAP" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.5923.1.1.1.1" FriendlyName= "eduPersonAffiliation" > <saml:AttributeValue xsi:type= "xs:string" > member </saml:AttributeValue> <saml:<saml:AttributeValue xsi:type= "xs:string" > staff </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

โปรดสังเกตว่าในตัวอย่างข้างต้น<saml:Assertion>องค์ประกอบดังกล่าวประกอบด้วยองค์ประกอบย่อยดังต่อไปนี้:

• องค์ประกอบ<saml:Issuer>ที่ประกอบด้วยตัวระบุเฉพาะของผู้ให้บริการข้อมูลประจำตัว
• องค์ประกอบ<ds:Signature>ซึ่งประกอบด้วยลายเซ็นดิจิทัล ที่รักษาความสมบูรณ์ (ไม่แสดงในภาพ) ทับอยู่บน<saml:Assertion>องค์ประกอบ นั้น
• องค์ประกอบ<saml:Subject>ที่ใช้ระบุตัวตนของผู้ใช้งานที่ผ่านการรับรอง (แต่ในกรณีนี้ ตัวตนของผู้ใช้งานจะถูกซ่อนไว้เบื้องหลังตัวระบุชั่วคราวที่ไม่โปร่งใส ด้วยเหตุผลด้านความเป็นส่วนตัว)
• องค์ประกอบ<saml:Conditions>ซึ่งระบุเงื่อนไขที่ใช้ในการพิจารณาว่าข้อความกล่าวอ้างนั้นถูกต้อง
• องค์ประกอบ<saml:AuthnStatement>ที่อธิบายถึงกระบวนการยืนยันตัวตน ณ ผู้ให้บริการยืนยันตัวตน
• องค์ประกอบ<saml:AttributeStatement>ซึ่งระบุคุณลักษณะหลายค่าที่เชื่อมโยงกับหลักการที่ได้รับการตรวจสอบสิทธิ์

กล่าวโดยสรุป ข้อความดังกล่าวสื่อถึงข้อมูลต่อไปนี้:

ข้อความยืนยัน ("b07b804c-7c29-ea16-7300-4f3d6f7928ac") ออกเมื่อเวลา "2004-12-05T09:22:05Z" โดยผู้ให้บริการข้อมูลประจำตัว (https://idp.example.org/SAML2) เกี่ยวกับหัวข้อ (3f7b3dcf-1674-4ecd-92c8-1544f346baf8) สำหรับผู้ให้บริการ (https://sp.example.com/SAML2) เท่านั้น

โดยเฉพาะอย่างยิ่ง ข้อความยืนยันตัวตนระบุข้อความต่อไปนี้:

ผู้ใช้งานหลักที่ระบุใน<saml:Subject>องค์ประกอบดังกล่าวได้รับการยืนยันตัวตนเมื่อเวลา "2004-12-05T09:22:00Z" โดยใช้รหัสผ่านที่ส่งผ่านช่องทางที่ได้รับการป้องกัน

ในทำนองเดียวกัน ข้อความแสดงคุณลักษณะก็ยืนยันว่า:

ผู้บริหารหลักที่ระบุไว้ใน<saml:Subject>องค์ประกอบนี้ มีคุณสมบัติ 'บุคลากร' และ 'สมาชิก' ของสถาบันนี้

โปรโตคอลต่อไปนี้ได้รับการกำหนดไว้ใน SAMLCore: ^{[ 1 ]}

• โปรโตคอลการสอบถามและการร้องขอการยืนยัน
• โปรโตคอลคำขอการตรวจสอบสิทธิ์
• โปรโตคอลการแก้ไขสิ่งประดิษฐ์
• โปรโตคอลการจัดการตัวระบุชื่อ
• โปรโตคอลการออกจากระบบครั้งเดียว
• โปรโตคอลการแมปตัวระบุชื่อ

โปรโตคอลที่สำคัญที่สุดในจำนวนนี้ คือ โปรโตคอลการร้องขอการตรวจสอบสิทธิ์ (Authentication Request Protocol) ซึ่งจะกล่าวถึงรายละเอียดในส่วนถัดไป

ในSAML 1.1โปรไฟล์ SSO บนเว็บเบราว์เซอร์จะเริ่มต้นโดยผู้ให้บริการข้อมูลประจำตัว (IDP)กล่าวคือ<samlp:Response>องค์ประกอบที่ไม่ได้รับการร้องขอจะถูกส่งจากผู้ให้บริการข้อมูลประจำตัวไปยังผู้ให้บริการ (ผ่านทางเบราว์เซอร์) (คำนำหน้าsamlp:แสดงถึงเนมสเปซของโปรโตคอล SAML)

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

เมื่อผู้ใช้งานหลัก (หรือหน่วยงานที่กระทำการแทนผู้ใช้งานหลัก) ต้องการขอรับการยืนยันที่มีข้อความรับรองความถูกต้อง ระบบ<samlp:AuthnRequest>จะส่งองค์ประกอบไปยังผู้ให้บริการยืนยันตัวตน:

<samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "aaf23196-1773-2113-474a-fe114412ab72" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" AssertionConsumerServiceIndex= "0" AttributeConsumingServiceIndex= "0" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "true" Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" < /samlp:AuthnRequest>

องค์ประกอบ ข้างต้น<samlp:AuthnRequest>ซึ่งโดยนัยแล้วร้องขอการยืนยันที่มีข้อความรับรองความถูกต้องนั้นเห็นได้ชัดว่าถูกสร้างขึ้นโดยผู้ให้บริการ (https://sp.example.com/SAML2) และนำเสนอต่อผู้ให้บริการยืนยันตัวตน (ผ่านทางเบราว์เซอร์) ผู้ให้บริการยืนยันตัวตนจะตรวจสอบความถูกต้องของบุคคล (หากจำเป็น) และส่งการตอบกลับการรับรองความถูกต้อง ซึ่งจะถูกส่งกลับไปยังผู้ให้บริการ (อีกครั้งผ่านทางเบราว์เซอร์)

ข้อความ SAML ถูกส่งจากเอนทิตีหนึ่งไปยังอีกเอนทิตีหนึ่งได้ทั้งโดยค่าหรือโดยการอ้างอิงการอ้างอิงถึงข้อความ SAML เรียกว่าอาร์ติแฟกต์ผู้รับอาร์ติแฟกต์จะแก้ไขการอ้างอิงโดยการส่งคำขอ<samlp:ArtifactResolve>โดยตรงไปยังผู้ส่งอาร์ติแฟกต์ ซึ่งผู้ส่งอาร์ติแฟกต์จะตอบกลับด้วยข้อความจริงที่อาร์ติแฟกต์อ้างอิงถึง

สมมติว่าผู้ให้บริการยืนยันตัวตนส่ง<samlp:ArtifactResolve>คำขอ ต่อไปนี้ โดยตรงไปยังผู้ให้บริการ (ผ่านช่องทางลับ):

<samlp:ArtifactResolve xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "_cce4ee769ed970b501d680f697989d14" Version= "2.0" IssueInstant= "2004-12-05T09:21:58Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- ข้อความ ArtifactResolve ควรมีการลงนาม --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Artifact> AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8= </samlp:Artifact> </samlp:ArtifactResolve>

ในทางกลับกัน ผู้ให้บริการจะส่งคืนองค์ประกอบ SAML ที่อ้างอิงโดยอาร์ติแฟกต์ที่แนบมา โปรโตคอลนี้เป็นพื้นฐานของHTTP Artifact Binding

การเชื่อมโยงที่รองรับโดย SAML 2.0 ได้รับการสรุปไว้ในข้อกำหนดการเชื่อมโยง (SAMLBind ^{[ 2 ]} ):

• การผูกข้อมูล SAML SOAP (อิงตาม SOAP 1.1)
• การจับตัวแบบย้อนกลับของ SOAP (PAOS)
• การผูกการเปลี่ยนเส้นทาง HTTP
• การผูก HTTP POST
• การผูกอาร์ติแฟกต์ HTTP
• การผูก URI ของ SAML

สำหรับการเข้าสู่ระบบแบบ Single Sign-On (SSO) ผ่านเว็บเบราว์เซอร์นั้น มักใช้ HTTP Redirect Binding และ HTTP POST Binding ตัวอย่างเช่น ผู้ให้บริการอาจใช้ HTTP Redirect เพื่อส่งคำขอ ในขณะที่ผู้ให้บริการยืนยันตัวตนใช้ HTTP POST เพื่อส่งการตอบกลับ ตัวอย่างนี้แสดงให้เห็นว่า การเลือก Binding ของแต่ละฝ่ายนั้นเป็นอิสระจากการเลือก Binding ของคู่ค้า

ข้อความโปรโตคอล SAML สามารถส่งได้โดยตรงในสตริงคำค้นหาของ URL ในคำขอ HTTP GET เนื่องจากความยาวของ URL มีข้อจำกัดในทางปฏิบัติ การเชื่อมโยง HTTP Redirect จึงเหมาะสำหรับข้อความสั้นๆ เช่น<samlp:AuthnRequest>ข้อความ ส่วนข้อความที่ยาวกว่า (เช่น ข้อความที่มีการยืนยัน SAML ที่ลงนามหรือเข้ารหัส เช่น SAML Response) มักจะส่งผ่านการเชื่อมโยงอื่นๆ เช่น การเชื่อม โยง HTTP POST

คำขอหรือการตอบกลับ SAML ที่ส่งผ่าน HTTP Redirect จะมี พารามิเตอร์สตริงคำค้นหา SAMLRequestหรือSAMLResponseพารามิเตอร์อื่นๆ ตามลำดับ ก่อนที่จะส่ง ข้อความจะถูกบีบอัด (โดยไม่มีส่วนหัวและค่าตรวจสอบความถูกต้อง) เข้ารหัสแบบ base64และเข้ารหัสแบบ URL ตามลำดับ เมื่อได้รับแล้ว กระบวนการจะถูกย้อนกลับเพื่อกู้คืนข้อความต้นฉบับ

ตัวอย่างเช่น การเข้ารหัส<samlp:AuthnRequest>ข้อความข้างต้นจะได้ผลลัพธ์ดังนี้:

https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=fZFfa8IwFMXfBb9DyXvaJtZ1BqsURRC2 Mabbw95ivc5Am3TJrXPffmmLY3%2FA15Pzuyf33On8XJXBCaxTRmeEhTEJQBdmr%2FRbRp63K3pL5rPhYOpkVdY ib%2FCon%2BC9AYfDQRB4WDvRvWWksVoY6ZQTWlbgBBZik9%2FfCR7GorYGTWFK8pu6DknnwKL%2FWEetlxmR8s BHbHJDWZqOKGdsRJM0kfQAjCUJ43KX8s78ctnIz%2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2%2FBK5MNo1F dgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1CWJgqanfl0%2Bin8xutxYOvZL18NK UqPlvZR5el%2BVhYkAgZQdsA6fWVsZXE63W2itrTQ2cVaKV2CjSSqL1v9P%2FAXv4C 

ข้อความข้างต้น (จัดรูปแบบเพื่อให้อ่านง่าย) อาจมีการลงนามเพื่อเพิ่มความปลอดภัย ในทางปฏิบัติ ข้อมูลทั้งหมดที่อยู่ในคำขอ<samlp:AuthnRequest>เช่นIssuerซึ่งประกอบด้วย SP ID และNameIDPolicyได้รับการตกลงกันระหว่าง IdP และ SP ไว้ล่วงหน้าแล้ว (ผ่านการแลกเปลี่ยนข้อมูลด้วยตนเองหรือผ่านเมตาเดต้า SAML ) ในกรณีนั้น การลงนามในคำขอจึงไม่ใช่ข้อจำกัดด้านความปลอดภัย เมื่อคำขอ<samlp:AuthnRequest>มีข้อมูลที่ IdP ไม่ทราบมาก่อน เช่น URL ของ Assertion Consumer Service ขอแนะนำให้ลงนามในคำขอเพื่อวัตถุประสงค์ด้านความปลอดภัย

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

< form method = "post" action = "https://idp.example.org/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLRequest" value = "request" /> ...พารามิเตอร์อินพุตอื่นๆ.... </ ฟอร์ม>

ค่าของSAMLRequestพารามิเตอร์คือการเข้ารหัสแบบ base64 ของ<samlp:AuthnRequest>องค์ประกอบ ซึ่งจะถูกส่งไปยังผู้ให้บริการยืนยันตัวตนผ่านทางเบราว์เซอร์ บริการ SSO ของผู้ให้บริการยืนยันตัวตนจะตรวจสอบความถูกต้องของคำขอและตอบกลับด้วยเอกสารที่มีแบบฟอร์ม XHTML อีกฉบับหนึ่ง:

< form method = "post" action = "https://sp.example.com/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLResponse" value = "response" /> ... </ ฟอร์ม>

ค่าของSAMLResponseพารามิเตอร์คือการเข้ารหัสแบบ base64 ของ<samlp:Response>องค์ประกอบ ซึ่งจะถูกส่งไปยังผู้ให้บริการผ่านทางเบราว์เซอร์เช่นกัน

หากต้องการทำให้การส่งแบบฟอร์มเป็นไปโดยอัตโนมัติ คุณสามารถใส่โค้ด JavaScript บรรทัดต่อไปนี้ลงในส่วนใดก็ได้ของหน้า XHTML:

window.onload = function ( ) { document.forms [ 0 ] .submit ( ) ; }​

แน่นอนว่า ข้อสันนิษฐานนี้ขึ้นอยู่กับว่าองค์ประกอบฟอร์มแรกในหน้าเว็บนั้นมีformองค์ประกอบที่มี SAMLResponse ดังกล่าวข้างต้นอยู่หรือไม่ ( forms[0])

การผูกอาร์ติแฟกต์ HTTP ใช้โปรโตคอลการแก้ไขอาร์ติแฟกต์และการผูก SAML SOAP (ผ่าน HTTP) เพื่อแก้ไขข้อความ SAML โดยการอ้างอิง พิจารณาตัวอย่างเฉพาะต่อไปนี้ สมมติว่าผู้ให้บริการต้องการส่ง<samlp:AuthnRequest>ข้อความไปยังผู้ให้บริการข้อมูลประจำตัว ในขั้นต้น ผู้ให้บริการจะส่งอาร์ติแฟกต์ไปยังผู้ให้บริการข้อมูลประจำตัวผ่านการเปลี่ยนเส้นทาง HTTP:

https://idp.example.org/SAML2/SSO/Artifact?SAMLart= artifact

ถัดไป ผู้ให้บริการยืนยันตัวตนจะส่ง<samlp:ArtifactResolve>คำขอ (เช่นArtifactResolveRequestที่แสดงไว้ก่อนหน้านี้) ไปยังผู้ให้บริการโดยตรงผ่านช่องทางสำรอง สุดท้าย ผู้ให้บริการจะส่งคืน<samlp:ArtifactResponse>องค์ประกอบที่มีข้อความที่อ้างอิงถึง<samlp:AuthnRequest>:

<samlp:ArtifactResponse xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "_d84a49e5958803dedcff4c984c2b0d95" InResponseTo= "_cce4ee769ed970b501d680f697989d14" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" > <!-- ข้อความ ArtifactResponse ควรมีการลงนาม --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= <samlp:Status="urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "_306f8ec5b618f361c70b6ffb1480eade" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" Destination= "https://idp.example.org/SAML2/SSO/Artifact" ProtocolBinding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" AssertionConsumerServiceURL=" < samlp : AuthnRequest > < / samlp : ArtifactResponse ...​​

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

โดยทั่วไปอาร์ติแฟกต์ SAML 2.0 ถูกกำหนดไว้ดังนี้ (SAMLBind ^{[ 2 ]} ):

SAML_artifact := B64 (TypeCode EndpointIndex RemainingArtifact) รหัสประเภท := ไบต์1ไบต์2 EndpointIndex := ไบต์1ไบต์2 

ดังนั้น อาร์ติแฟกต์ SAML 2.0 จึงประกอบด้วยส่วนประกอบสามส่วน ได้แก่ ไบต์สองไบต์TypeCodeไบต์สองไบต์EndpointIndexและลำดับไบต์ใดๆ ที่เรียกว่า ไบต์อ้างอิงRemainingArtifactข้อมูลทั้งสามส่วนนี้จะถูกรวมเข้าด้วยกันและเข้ารหัสแบบ base64 เพื่อให้ได้อาร์ติแฟกต์ที่สมบูรณ์

ตัวTypeCodeระบุเฉพาะนี้ใช้ระบุรูปแบบของอาร์ติแฟกต์ SAML 2.0 กำหนดอาร์ติแฟกต์ดังกล่าวไว้เพียงหนึ่งเดียว คือประเภท 0x0004 นี่EndpointIndexคือการอ้างอิงถึงจุดสิ้นสุดการแก้ไขอาร์ติแฟกต์เฉพาะที่จัดการโดยผู้ออกอาร์ติแฟกต์ (ซึ่งอาจเป็น IdP หรือ SP ดังที่กล่าวไว้ก่อนหน้านี้) RemainingArtifactซึ่งกำหนดโดยคำจำกัดความของประเภท คือ "ส่วนสำคัญ" ของอาร์ติแฟกต์

รูปแบบของอาร์ติแฟกต์ประเภท 0x0004มีการกำหนดเพิ่มเติมดังนี้:

รหัสประเภท := 0x0004 RemainingArtifact := SourceId MessageHandle SourceId := ลำดับ 20 ไบต์ MessageHandle := ลำดับ 20 ไบต์ 

ดังนั้น อาร์ติแฟกต์ประเภท 0x0004 จึงมีขนาด 44 ไบต์ (ก่อนเข้ารหัส) SourceIdเป็นลำดับไบต์แบบสุ่ม แม้ว่าในทางปฏิบัติจะSourceIdเป็น ค่าแฮ ช SHA-1ของ entityID ของผู้ออกอาร์MessageHandleติแฟกต์ก็ตาม เป็นลำดับไบต์แบบสุ่มที่อ้างอิงถึงข้อความ SAML ที่ผู้ออกอาร์ติแฟกต์ยินดีที่จะสร้างขึ้นตามคำขอ

ตัวอย่างเช่น ลองพิจารณาข้อมูลประเภท 0x0004 ที่เข้ารหัสแบบเลขฐานสิบหกนี้:

00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f 

ถ้าสังเกตดีๆ จะเห็นTypeCode(0x0004) และEndpointIndex(0x0000) อยู่ด้านหน้าของอาร์ติแฟกต์ 20 ไบต์ถัดไปคือค่าแฮช SHA-1 ของ entityID ของผู้ออก (https://idp.example.org/SAML2) ตามด้วยไบต์สุ่มอีก 20 ไบต์ การเข้ารหัสแบบ base64 ของ 44 ไบต์นี้คือสิ่งที่คุณเห็นใน ตัวอย่าง ArtifactResolveRequestด้านบน

ใน SAML 2.0 เช่นเดียวกับ SAML 1.1 กรณีการใช้งาน หลัก ยังคงเป็นการเข้าสู่ระบบแบบ Single Sign-On (SSO) ผ่านเว็บเบราว์เซอร์ แต่ขอบเขตของ SAML 2.0 นั้นกว้างกว่าเวอร์ชันก่อนหน้าของ SAML ดังที่แสดงในรายการโปรไฟล์ที่ครอบคลุมต่อไปนี้:

• โปรไฟล์ SSO
  • โปรไฟล์ SSO ของเว็บเบราว์เซอร์
  • โปรไฟล์ไคลเอ็นต์หรือพร็อกซีขั้นสูง (ECP)
  • โปรไฟล์การค้นหาผู้ให้บริการข้อมูลประจำตัว
  • โปรไฟล์การออกจากระบบครั้งเดียว
  • โปรไฟล์การจัดการตัวระบุชื่อ
• โปรไฟล์ความละเอียดของสิ่งประดิษฐ์
• โปรไฟล์การสอบถาม/คำขอการยืนยัน
• โปรไฟล์การแมปตัวระบุชื่อ
• โปรไฟล์แอตทริบิวต์ SAML
  • ข้อมูลคุณลักษณะพื้นฐาน
  • โปรไฟล์แอตทริบิวต์ X.500/LDAP
  • โปรไฟล์คุณลักษณะ UUID
  • โปรไฟล์คุณลักษณะ DCE PAC
  • โปรไฟล์แอตทริบิวต์XACML

แม้ว่าจำนวนโปรไฟล์ที่รองรับจะมีจำนวนมาก แต่ข้อกำหนดของโปรไฟล์ (SAMLProf ^{[ 3 ]} ) ก็ได้รับการทำให้ง่ายขึ้น เนื่องจากลักษณะการผูกของแต่ละโปรไฟล์ได้ถูกแยกออกเป็นข้อกำหนดการผูกแยกต่างหาก (SAMLBind ^{[ 2 ]} )

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

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

กระบวนการส่งข้อความเริ่มต้นด้วยการร้องขอทรัพยากรที่มีการรักษาความปลอดภัยจากผู้ให้บริการ

1. ร้องขอทรัพยากรเป้าหมายที่ SP

ผู้ใช้งานหลัก (ผ่านทางตัวแทนผู้ใช้ HTTP) ร้องขอทรัพยากรเป้าหมายที่ผู้ให้บริการ:

https://sp.example.com/myresource 

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

ผู้ให้บริการอาจใช้วิธีการใดก็ได้ในการค้นหาผู้ให้บริการยืนยันตัวตนที่จะใช้ เช่น สอบถามผู้ใช้ ใช้ผู้ให้บริการยืนยันตัวตนที่กำหนดค่าไว้ล่วงหน้า เป็นต้น

2. เปลี่ยนเส้นทางไปยังบริการ IdP SSO

ผู้ให้บริการจะสร้าง SAMLRequest ที่เหมาะสม (และ RelayState หากมี) จากนั้นจะเปลี่ยนเส้นทางเบราว์เซอร์ไปยังบริการ IdP SSO โดยใช้การเปลี่ยนเส้นทาง HTTP 302 มาตรฐาน

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

โทเค็น นี้RelayStateเป็นข้อมูลอ้างอิงที่ไม่โปร่งใสถึงข้อมูลสถานะที่เก็บรักษาไว้ที่ผู้ให้บริการ ค่าของSAMLRequestพารามิเตอร์คือค่าขององค์ประกอบที่ถูกบีบอัด เข้ารหัสแบบ base64 และเข้ารหัสแบบ URL แล้ว<samlp:AuthnRequest>:

<samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" AssertionConsumerServiceIndex= "0" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "true" Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" /> </samlp:AuthnRequest>

อาจมีการลงนาม SAMLRequest โดยใช้คีย์ลงนาม SP อย่างไรก็ตาม โดยทั่วไปแล้วไม่จำเป็นต้องทำเช่นนั้น

3. ขอใช้บริการ SSO ที่ IdP

ตัวแทนผู้ใช้จะส่งคำขอ GET ไปยังบริการ SSO ที่ผู้ให้บริการยืนยันตัวตน:

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

โดยที่ค่าของ พารามิเตอร์ ` SAMLRequestand` RelayStateจะเหมือนกับค่าที่ให้ไว้ในการเปลี่ยนเส้นทาง บริการ SSO ของผู้ให้บริการข้อมูลประจำตัวจะประมวลผล<samlp:AuthnRequest>องค์ประกอบ `<a>` (โดยการถอดรหัส URL, ถอดรหัส base64 และขยายคำขอ ตามลำดับ) และทำการตรวจสอบความปลอดภัย หากผู้ใช้ไม่มีบริบทความปลอดภัยที่ถูกต้อง ผู้ให้บริการข้อมูลประจำตัวจะระบุตัวตนผู้ใช้ด้วยกลไกใดๆ ก็ตาม (รายละเอียดถูกละไว้)

4. ตอบกลับด้วยแบบฟอร์ม XHTML

บริการ SSO จะตรวจสอบความถูกต้องของคำขอและตอบกลับด้วยเอกสารที่มีแบบฟอร์ม 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>

ค่าของRelayStateพารามิเตอร์ถูกเก็บรักษาไว้จากขั้นตอนที่ 3 ค่าของSAMLResponseพารามิเตอร์คือการเข้ารหัสแบบ base64 ของ<samlp:Response>องค์ประกอบต่อไปนี้:

<samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_2" InResponseTo= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" Destination= "https://sp.example.com/SAML2/SSO/POST" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:saml=" "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_3" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- การยืนยันที่ส่งผ่าน POST ต้องมีลายเซ็น --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "identifier_1" Recipient= "https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "identifier_3" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:<saml:AuthnContextClassRef></saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response>

5. ติดต่อฝ่ายบริการลูกค้าสัมพันธ์ของ SP เพื่อขอคำปรึกษา

ตัวแทนผู้ใช้จะส่งคำขอ POST ไปยังบริการ Assertion Consumer Service ที่ผู้ให้บริการ:

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

โดยค่าของ พารามิเตอร์ ` SAMLResponseand` RelayStateจะถูกดึงมาจากแบบฟอร์ม XHTML ในขั้นตอนที่ 4

6. เปลี่ยนเส้นทางไปยังทรัพยากรเป้าหมาย

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

7. ร้องขอทรัพยากรเป้าหมายที่ SP อีกครั้ง

ตัวแทนผู้ใช้ร้องขอทรัพยากรเป้าหมายที่ผู้ให้บริการ (อีกครั้ง):

https://sp.example.com/myresource 

8. ตอบกลับด้วยทรัพยากรที่ร้องขอ

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

นี่คือการใช้งานโปรไฟล์ SAML 2.0 Web Browser SSO (SAMLProf ^{[ 3 ]} ) ที่ค่อนข้างง่าย โดยที่ทั้งผู้ให้บริการ (SP) และผู้ให้บริการข้อมูลประจำตัว (IdP) ใช้การผูก HTTP POST

กระบวนการส่งข้อความเริ่มต้นด้วยการร้องขอทรัพยากรที่มีการรักษาความปลอดภัยที่ SP

1. ร้องขอทรัพยากรเป้าหมายที่ SP

ผู้ใช้งานหลัก (ผ่านทางตัวแทนผู้ใช้ HTTP) ร้องขอทรัพยากรเป้าหมายที่ผู้ให้บริการ:

https://sp.example.com/myresource 

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

2. ตอบกลับด้วยแบบฟอร์ม XHTML

ผู้ให้บริการตอบกลับด้วยเอกสารที่มีแบบฟอร์ม XHTML:

< form method = "post" action = "https://idp.example.org/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLRequest" value = "request" /> < input type = "hidden" name = "RelayState" value = " token " /> ... < input type = "submit" value = "Submit" /> </form>

โทเค็น นี้RelayStateเป็นข้อมูลอ้างอิงที่ไม่โปร่งใสถึงข้อมูลสถานะที่เก็บรักษาไว้ที่ผู้ให้บริการ ค่าของSAMLRequestพารามิเตอร์คือการเข้ารหัสแบบ base64 ของ<samlp:AuthnRequest>องค์ประกอบต่อไปนี้:

<samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" AssertionConsumerServiceIndex= "0" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "true" Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" /> </samlp:AuthnRequest>

ก่อนที่<samlp:AuthnRequest>จะแทรกองค์ประกอบลงในแบบฟอร์ม XHTML องค์ประกอบนั้นจะถูกเข้ารหัสแบบ base64 ก่อน

3. ขอใช้บริการ SSO ที่ IdP

ตัวแทนผู้ใช้จะส่งคำขอ POST ไปยังบริการ SSO ที่ผู้ให้บริการยืนยันตัวตน:

POST /SAML2/SSO/POST HTTP / 1.1 Host : idp.example.org Content-Type : application/x-www-form-urlencoded Content-Length : nnnSAMLRequest = request & RelayState = token

โดยค่าของ พารามิเตอร์ `<a> SAMLRequest` และ `<a> RelayState` จะถูกดึงมาจากฟอร์ม XHTML ในขั้นตอนที่ 2 บริการ SSO จะประมวลผล<samlp:AuthnRequest>องค์ประกอบ `<a>` (โดยการถอดรหัส URL, ถอดรหัส base64 และขยายคำขอ ตามลำดับ) และทำการตรวจสอบความปลอดภัย หากผู้ใช้ไม่มีบริบทความปลอดภัยที่ถูกต้อง ผู้ให้บริการข้อมูลประจำตัวจะระบุตัวผู้ใช้ (รายละเอียดถูกละไว้)

4. ตอบกลับด้วยแบบฟอร์ม XHTML

บริการ SSO จะตรวจสอบความถูกต้องของคำขอและตอบกลับด้วยเอกสารที่มีแบบฟอร์ม 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>

ค่าของRelayStateพารามิเตอร์ถูกเก็บรักษาไว้จากขั้นตอนที่ 3 ค่าของSAMLResponseพารามิเตอร์คือการเข้ารหัสแบบ base64 ของ<samlp:Response>องค์ประกอบต่อไปนี้:

<samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_2" InResponseTo= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" Destination= "https://sp.example.com/SAML2/SSO/POST" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:saml=" "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_3" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- การยืนยันที่ส่งผ่าน POST ต้องมีลายเซ็น --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "identifier_1" Recipient= "https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "identifier_3" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:<saml:AuthnContextClassRef></saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response>

5. ติดต่อฝ่ายบริการลูกค้าสัมพันธ์ของ SP เพื่อขอคำปรึกษา

ตัวแทนผู้ใช้จะส่งคำขอ POST ไปยังบริการผู้บริโภคการยืนยันที่ผู้ให้บริการ:

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

โดยค่าของ พารามิเตอร์ ` SAMLResponseand` RelayStateจะถูกดึงมาจากแบบฟอร์ม XHTML ในขั้นตอนที่ 4

6. เปลี่ยนเส้นทางไปยังทรัพยากรเป้าหมาย

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

7. ร้องขอทรัพยากรเป้าหมายที่ SP อีกครั้ง

ตัวแทนผู้ใช้ร้องขอทรัพยากรเป้าหมายที่ผู้ให้บริการ (อีกครั้ง):

https://sp.example.com/myresource 

8. ตอบกลับด้วยทรัพยากรที่ร้องขอ

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

นี่คือการใช้งานที่ซับซ้อนของโปรไฟล์ SAML 2.0 Web Browser SSO (SAMLProf ^{[ 3 ]} ) ซึ่งทั้งผู้ให้บริการ (SP) และผู้ให้บริการข้อมูลประจำตัว (IdP) ใช้การผูก HTTP Artifact โดย Artifact ทั้งสองจะถูกส่งไปยังปลายทางที่เกี่ยวข้องผ่านทาง HTTP GET

กระบวนการส่งข้อความเริ่มต้นด้วยการร้องขอทรัพยากรที่มีการรักษาความปลอดภัยที่ SP:

1. ร้องขอทรัพยากรเป้าหมายที่ SP

ผู้ใช้งานหลัก (ผ่านทางตัวแทนผู้ใช้ HTTP) ร้องขอทรัพยากรเป้าหมายที่ผู้ให้บริการ:

https://sp.example.com/myresource 

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

2. เปลี่ยนเส้นทางไปยังบริการ Single Sign-On (SSO) ที่ IdP

ผู้ให้บริการจะเปลี่ยนเส้นทางตัวแทนผู้ใช้ไปยังบริการ Single Sign-On (SSO) ที่ผู้ให้บริการยืนยันตัวตน โดยจะมีการเพิ่ม RelayStateพารามิเตอร์และSAMLartพารามิเตอร์เข้าไปใน URL การเปลี่ยนเส้นทาง

3. ขอใช้บริการ SSO ที่ IdP

ตัวแทนผู้ใช้ร้องขอใช้บริการ SSO ที่ผู้ให้บริการยืนยันตัวตน:

https://idp.example.org/SAML2/SSO/Artifact?SAMLart= artifact_1 &RelayState= token

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

4. ร้องขอบริการแก้ไขปัญหาเกี่ยวกับสิ่งประดิษฐ์ที่ SP

บริการ SSO จะยกเลิกการอ้างอิงอาร์ติแฟกต์โดยการส่ง<samlp:ArtifactResolve>องค์ประกอบที่ผูกกับข้อความ SAML SOAP ไปยังบริการแก้ไขอาร์ติแฟกต์ที่ผู้ให้บริการ:

<samlp:ArtifactResolve xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:58Z" Destination= "https://sp.example.com/SAML2/ArtifactResolution" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- ข้อความ ArtifactResolve ควรมีการลงนาม --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Artifact> ''artifact_1'' </samlp:Artifact> </samlp:ArtifactResolve>

โดยที่ค่าของ<samlp:Artifact>องค์ประกอบนั้นคืออาร์ติแฟกต์ SAML ที่ส่งในขั้นตอนที่ 3

5. ตอบกลับด้วย SAML AuthnRequest

บริการแก้ไขอาร์ติแฟกต์ที่ผู้ให้บริการจะส่งคืน<samlp:ArtifactResponse>องค์ประกอบ (ที่มี<samlp:AuthnRequest>องค์ประกอบ) ที่ผูกกับข้อความ SAML SOAP ไปยังบริการ SSO ที่ผู้ให้บริการข้อมูลประจำตัว:

<samlp:ArtifactResponse xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "identifier_2" InResponseTo= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" > <!-- ข้อความ ArtifactResponse ควรมีการลงนาม --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <samlp:AuthnRequest xmlns:samlp=" "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_3" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" Destination= "https://idp.example.org/SAML2/SSO/Artifact" ProtocolBinding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" AssertionConsumerServiceURL= "https://sp.example.com/SAML2/SSO/Artifact" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "false" Format= <samlp:AuthnRequest></samlp:ArtifactResponse> < /samlp :AuthnRequest ...

บริการ SSO จะประมวลผล<samlp:AuthnRequest>องค์ประกอบและทำการตรวจสอบความปลอดภัย หากผู้ใช้ไม่มีบริบทความปลอดภัยที่ถูกต้อง ผู้ให้บริการข้อมูลประจำตัวจะระบุตัวผู้ใช้ (รายละเอียดถูกละไว้)

6. เปลี่ยนเส้นทางไปยังฝ่ายบริการลูกค้าของ Assertion

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

7. ติดต่อฝ่ายบริการลูกค้าของ SP เพื่อขอคำยืนยัน

ตัวแทนผู้ใช้ร้องขอการบริการผู้บริโภคการยืนยันที่ผู้ให้บริการ:

https://sp.example.com/SAML2/SSO/Artifact?SAMLart= artifact_2 &RelayState= token

tokenค่าโทเค็นจากขั้นตอนที่ 3 อยู่ที่ไหน และ artifact_2อาร์ติแฟกต์ SAML ที่ออกในขั้นตอนที่ 6 อยู่ ที่ไหน

8. ร้องขอบริการแก้ไขปัญหาอาร์ติแฟกต์ที่ IdP

บริการผู้บริโภคการยืนยันจะยกเลิกการอ้างอิงอาร์ติแฟกต์โดยการส่ง<samlp:ArtifactResolve>องค์ประกอบที่ผูกกับข้อความ SAML SOAP ไปยังบริการแก้ไขอาร์ติแฟกต์ที่ผู้ให้บริการข้อมูลประจำตัว:

<samlp:ArtifactResolve xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_4" Version= "2.0" IssueInstant= "2004-12-05T09:22:04Z" Destination= "https://idp.example.org/SAML2/ArtifactResolution" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <!-- ข้อความ ArtifactResolve ควรมีการลงนาม --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Artifact> ''artifact_2'' </samlp:Artifact> </samlp:ArtifactResolve>

โดยที่ค่าของ<samlp:Artifact>องค์ประกอบนั้นคืออาร์ติแฟกต์ SAML ที่ส่งในขั้นตอนที่ 7

9. ตอบกลับด้วย SAML Assertion

บริการแก้ไขอาร์ติแฟกต์ที่ผู้ให้บริการข้อมูลประจำตัวจะส่งคืน<samlp:ArtifactResponse>องค์ประกอบ (ที่มี<samlp:Response>องค์ประกอบ) ที่ผูกกับข้อความ SAML SOAP ไปยังบริการผู้บริโภคการยืนยันที่ผู้ให้บริการ:

<samlp:ArtifactResponse xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "identifier_5" InResponseTo= "identifier_4" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <!-- ข้อความ ArtifactResponse ควรมีการลงนาม --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_6" InResponseTo= "identifier_3" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" Destination= "https://sp.example.com/SAML2/SSO/Artifact" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_7" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- ต้องมีองค์ประกอบ Subject --> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > [email protected] </saml:NameID> <saml:SubjectConfirmation Method=" "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "identifier_3" Recipient= "https://sp.example.com/SAML2/SSO/Artifact" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:หัวข้อ> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience></saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "identifier_7" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response> </samlp:ArtifactResponse>

10. เปลี่ยนเส้นทางไปยังทรัพยากรเป้าหมาย

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

11. ร้องขอทรัพยากรเป้าหมายที่ SP อีกครั้ง

ตัวแทนผู้ใช้ร้องขอทรัพยากรเป้าหมายที่ผู้ให้บริการ (อีกครั้ง):

https://sp.example.com/myresource 

12. ตอบกลับด้วยแหล่งข้อมูลที่ร้องขอ

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

โปรไฟล์การค้นหาผู้ให้บริการข้อมูลประจำตัว SAML 2.0 นำเสนอแนวคิดต่อไปนี้:

• โดเมนทั่วไป
• คุกกี้โดเมนทั่วไป
• บริการเขียนคุกกี้โดเมนทั่วไป
• บริการอ่านคุกกี้โดเมนทั่วไป

เพื่อเป็นตัวอย่างสมมุติของโดเมนร่วมสมมติว่า Example UK (example.co.uk) และ Example Deutschland (example.de) เป็นส่วนหนึ่งขององค์กรเสมือน Example Global Alliance ( example.com ) ในตัวอย่างนี้ โดเมนexample.comคือโดเมนร่วม ทั้ง Example UK และ Example Deutschland ต่างก็มีตัวตนอยู่ในโดเมนนี้ (uk.example.com และ de.example.com ตามลำดับ)

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

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

โปรไฟล์Assertion Query/Request เป็นโปรไฟล์ทั่วไปที่รองรับ การสืบค้นหลายประเภทโดยใช้ส่วนประกอบ SAML 2.0 ดังต่อไปนี้:

• องค์ประกอบ<samlp:AssertionIDRequest>ที่ใช้ในการร้องขอการยืนยันโดยใช้ตัวระบุเฉพาะ ( ID)
• องค์ประกอบ<samlp:SubjectQuery>ดังกล่าว ซึ่งเป็นจุดขยายเชิงนามธรรมที่อนุญาตให้กำหนดคำสั่งค้นหา SAML ตามหัวเรื่องใหม่ได้
• องค์ประกอบ<samlp:AuthnQuery>นี้ใช้สำหรับร้องขอ การยืนยันตัวตน ที่มีอยู่เกี่ยวกับบุคคลที่กำหนดจากหน่วยงานตรวจสอบสิทธิ์
• องค์ประกอบ<samlp:AttributeQuery>นี้ใช้สำหรับขอคุณลักษณะเกี่ยวกับหัวข้อที่กำหนดจากหน่วยงานที่รับผิดชอบด้านคุณลักษณะ
• องค์ประกอบ<samlp:AuthzDecisionQuery>ดังกล่าว ซึ่งใช้ในการขอการตัดสินใจอนุญาตจากบุคคลที่สามที่เชื่อถือได้

การเชื่อมต่อ SAML SOAP มักใช้ร่วมกับการสืบค้นข้อมูล

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

<samlp:AttributeQuery xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "aaf23196-1773-2113-474a-fe114412ab72" Version= "2.0" IssueInstant= "2006-07-17T20:31:40Z" > <saml:Issuer Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" > [email protected],OU=User,O=NCSA-TEST,C=US </saml:Issuer> <saml:Subject> <saml:NameID Format= <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" > [email protected],OU=User,O=NCSA-TEST,C=US </saml:NameID> </saml:Subject> <saml:Attribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:2.5.4.42" FriendlyName= "givenName" > </saml:Attribute> <saml:Attribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.1466.115.121.1.26" FriendlyName= "mail" > </saml:Attribute> </samlp:AttributeQuery>

โปรดสังเกตว่าในกรณีนี้คือ ซึ่งบางครั้งเรียกว่าIssuerการสอบถามแอตทริบิวต์ด้วยตนเองผู้ให้บริการข้อมูลประจำตัวอาจส่งคืนข้อความยืนยันต่อไปนี้ โดยห่อด้วยองค์ประกอบ (ไม่ได้แสดงไว้): Subject<samlp:Response>

<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs= "http://www.w3.org/2001/XMLSchema" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" ID= "_33776a319493ad607b7ab3e689482e45" Version= "2.0" IssueInstant= "2006-07-17T20:31:41Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature> ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" > [email protected],OU=User,O=NCSA-TEST,C=US </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" > <saml:SubjectConfirmationData> <ds:KeyInfo> <ds:X509Data> <!-- ใบรับรอง X.509 ของหลักการ --> <ds:X509Certificate> MIICiDCCAXACCQDE+9eiWrm62jANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJV UzESMBAGA1UEChMJTkNTQS1URVNUMQ0wCwYDVQQLEwRVc2VyMRMwEQYDVQQDEwpT UC1TZXJ2aWNlMB4XDTA2MDcxNzIwMjE0MVoXDTA2MDcxODIwMjE0MVowSzELMAkG A1UEBhMCVVMxEjAQBgNVBAoTCU5DU0EtVEVTVDENMAsGA1UECxMEVXNlcjEZMBcG A1UEAwwQdHJzY2F2b0B1aXVjLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv9QMe4lRl3XbWPcflbCjGK9gty6zBJmp+tsaJINM0VaBaZ3t+tSXknelYife nCc2O3yaX76aq53QMXy+5wKQYe8Rzdw28Nv3a73wfjXJXoUhGkvERcscs9EfIWcC g2bHOg8uSh+Fbv3lHih4lBJ5MCS2buJfsR7dlr/xsadU2RcCAwEAATANBgkqhkiG 9w0BAQQFAAOCAQEAdyIcMTob7TVkelfJ7+I1j0LO24UlKvbLzd2OPvcFTCv6fVHx Ejk0QxaZXJhreZ6+rIdiMXrEzlRdJEsNMxtDW8++sVp6avoB5EX1y3ez+CEAIL4g cjvKZUR4dMryWshWIBHKFFul+r7urUgvWI12KbMeE9KP+kiiiiTskLcKgFzngw1J selmHhTcTCrcDocn5yO2+d3dog52vSOtVFDBsBuvDixO2hv679JR6Hlqjtk4GExp E9iVI0wdPE038uQIJJTXlhsMMLvUGVh/c0ReJBn92Vj4dI/yy6PtY/8ncYLYNkjg oVN0J/ymOktn9lTlFyTiuY4OuJsZRO1+zWLy9g== </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </saml:SubjectConfirmationData> </saml:SubjectConfirmation> </saml:Subject> <!-- อายุการใช้งานของการยืนยันถูกจำกัดโดยใบรับรอง X.509 ของหลักการ --> <saml:Conditions NotBefore= "2006-07-17T20:31:41Z" NotOnOrAfter= "2006-07-18T20:21:41Z" > </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2006-07-17T20:31:41Z" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient </saml:AuthnContextClassRef> </saml:AuthnContext ></saml:AuthnStatement > <saml:AttributeStatement> <saml:Attribute xmlns:x500= "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" x500 :Encoding= "LDAP" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:2.5.4.42" FriendlyName= "givenName" > <saml:AttributeValue xsi:type= "xs:string" > Tom </saml:AttributeValue> </saml:Attribute> <saml:Attribute xmlns:x500=" "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" x500:Encoding= "LDAP" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.1466.115.121.1.26" FriendlyName= "mail" > <saml:AttributeValue xsi:type= "xs:string" > [email protected] </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

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

กล่าวโดยแท้จริงแล้ว เมตาเดตาคือสิ่งที่ทำให้ SAML ทำงานได้ (หรือทำงานได้ดี) การใช้งานเมตาเดตาที่สำคัญบางประการ ได้แก่:

• ผู้ให้บริการเตรียมส่งข้อมูล<samlp:AuthnRequest>ไปยังผู้ให้บริการยืนยันตัวตนผ่านทางเบราว์เซอร์ ผู้ให้บริการรู้ได้อย่างไรว่าผู้ให้บริการยืนยันตัวตนนั้นเป็นของจริง ไม่ใช่ผู้ให้บริการยืนยันตัวตนที่ประสงค์ร้ายพยายามขโมยรหัสผ่านของผู้ใช้ ผู้ให้บริการจะตรวจสอบรายชื่อผู้ให้บริการยืนยันตัวตนที่เชื่อถือได้ในเมตาเดต้าก่อนที่จะส่งคำขอการยืนยันตัวตน
• ในสถานการณ์ก่อนหน้านี้ ผู้ให้บริการทราบได้อย่างไรว่าจะส่งผู้ใช้ไปที่ใดพร้อมกับคำขอการตรวจสอบสิทธิ์? ผู้ให้บริการจะค้นหาตำแหน่งปลายทางที่กำหนดไว้ล่วงหน้าของผู้ให้บริการข้อมูลประจำตัวที่เชื่อถือได้ในข้อมูลเมตา
• ผู้ให้บริการยืนยันตัวตนจะได้รับ<samlp:AuthnRequest>องค์ประกอบจากผู้ให้บริการผ่านทางเบราว์เซอร์ ผู้ให้บริการยืนยันตัวตนจะรู้ได้อย่างไรว่าผู้ให้บริการนั้นเป็นของแท้และไม่ใช่ผู้ให้บริการที่เป็นอันตรายที่พยายามเก็บรวบรวมข้อมูลส่วนบุคคลของผู้ใช้? ผู้ให้บริการยืนยันตัวตนจะตรวจสอบรายชื่อผู้ให้บริการที่เชื่อถือได้ในเมตาเดตาก่อนที่จะส่งการตอบสนองการยืนยันตัวตน
• ในสถานการณ์ก่อนหน้านี้ ผู้ให้บริการยืนยันตัวตนเข้ารหัส SAML assertion อย่างไรเพื่อให้ผู้ให้บริการที่เชื่อถือได้ (และเฉพาะผู้ให้บริการที่เชื่อถือได้เท่านั้น) สามารถถอดรหัส assertion นั้นได้ ผู้ให้บริการยืนยันตัวตนใช้ใบรับรองการเข้ารหัสของผู้ให้บริการในเมตาเดต้าเพื่อเข้ารหัส assertion นั้น
• จากสถานการณ์ก่อนหน้านี้ ผู้ให้บริการยืนยันตัวตนทราบได้อย่างไรว่าจะส่งผู้ใช้ไปที่ใดพร้อมกับผลตอบรับการตรวจสอบสิทธิ์ ผู้ให้บริการยืนยันตัวตนจะค้นหาตำแหน่งปลายทางที่กำหนดไว้ล่วงหน้าของผู้ให้บริการที่เชื่อถือได้ในข้อมูลเมตา
• ผู้ให้บริการทราบได้อย่างไรว่าการตอบรับการตรวจสอบสิทธิ์มาจากผู้ให้บริการข้อมูลประจำตัวที่เชื่อถือได้? ผู้ให้บริการจะตรวจสอบลายเซ็นบนคำยืนยันโดยใช้คีย์สาธารณะของผู้ให้บริการข้อมูลประจำตัวจากข้อมูลเมตา
• ผู้ให้บริการทราบได้อย่างไรว่าจะต้องแก้ไขปัญหาที่ได้รับจากผู้ให้บริการยืนยันตัวตนที่เชื่อถือได้อย่างไร? ผู้ให้บริการจะค้นหาตำแหน่งปลายทางที่กำหนดไว้ล่วงหน้าของบริการแก้ไขปัญหาของผู้ให้บริการยืนยันตัวตนจากข้อมูลเมตา

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

ผู้ให้บริการยืนยันตัวตนจะเผยแพร่ข้อมูลเกี่ยวกับตนเองใน<md:EntityDescriptor>องค์ประกอบ:

<md:EntityDescriptor entityID= "https://idp.example.org/SAML2" validUntil= "2013-03-22T23:00:00Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- แทรกองค์ประกอบ ds:Signature (ละไว้) --> <!-- แทรกองค์ประกอบ md:IDPSSODescriptor (ด้านล่าง) --> <md:Organization> <md:OrganizationName xml:lang= "en" >องค์กรไม่แสวงหาผลกำไรแห่งหนึ่งในนิวยอร์ก</md:OrganizationName> <md:OrganizationDisplayName xml:lang= " en" >องค์กรไม่แสวงหาผลกำไร</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>

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

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

ตามคำจำกัดความ ผู้ให้บริการข้อมูลประจำตัวจะจัดการบริการ SSO ที่สนับสนุนโปรไฟล์ SAML Web Browser SSO ที่ระบุไว้ใน SAMLProf ^{[ 3 ]}ดูตัวอย่างเช่น ผู้ให้บริการข้อมูลประจำตัวที่อธิบายไว้ใน<md:IDPSSODescriptor>องค์ประกอบที่แสดงในส่วนถัดไป

บริการ SSO ของผู้ให้บริการยืนยันตัวตนนั้น อธิบายไว้ใน<md:IDPSSODescriptor>องค์ประกอบ:

<md:IDPSSODescriptor protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:KeyDescriptor use= "signing" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:ArtifactResolutionService isDefault= "true" index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location= "https://idp.example.org/SAML2/ArtifactResolution" /> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress </md:NameIDFormat> <md:NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> <md:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= "https://idp.example.org/SAML2/SSO/Redirect" /> <md:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "https://idp.example.org/SAML2/SSO/POST" /> <md:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location= "https://idp.example.org/SAML2/Artifact" /> <saml:Attribute NameFormat=" "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.5923.1.1.1.1" FriendlyName= "eduPersonAffiliation" > <saml:AttributeValue>สมาชิก</saml:AttributeValue> <saml:AttributeValue>นักศึกษา</saml:AttributeValue> <saml:AttributeValue>อาจารย์</saml:AttributeValue> <saml:AttributeValue>พนักงาน</saml:AttributeValue> <saml:AttributeValue>เจ้าหน้าที่</saml:AttributeValue> </saml:Attribute> </md:IDPSSODescriptor>

องค์ประกอบเมตาเดตาข้างต้นอธิบายถึงบริการ SSO ที่ผู้ให้บริการยืนยันตัวตน โปรดสังเกตรายละเอียดต่อไปนี้เกี่ยวกับองค์ประกอบนี้:

• ซอฟต์แวร์ผู้ให้บริการยืนยันตัวตนได้รับการกำหนดค่าด้วยคีย์ลงนาม SAML ส่วนตัวและ/หรือคีย์ TLS ส่วนตัวสำหรับการสื่อสารผ่านช่องทางสำรอง คีย์สาธารณะที่เกี่ยวข้องจะรวมอยู่ใน<md:KeyDescriptor use="signing">องค์ประกอบในเมตาเดตาของผู้ให้บริการยืนยันตัวตน เพื่อความกระชับ จึงได้ละเว้นรายละเอียดของคีย์ทั้งหมดออกจากคำอธิบายคีย์
• คุณลักษณะBindingของ องค์ประกอบบ่งชี้ว่า ควรใช้<md:ArtifactResolutionService>การเชื่อมโยง SAML SOAP (SAMLBind ^{[ 2 ] ) สำหรับการแก้ไขสิ่งประดิษฐ์}
• คุณลักษณะLocationของ<md:ArtifactResolutionService>องค์ประกอบนี้ถูกนำไปใช้ในขั้นตอนที่ 8 ของโปรไฟล์ " สิ่งประดิษฐ์คู่ "
• ค่าของindexแอตทริบิวต์ของ<md:ArtifactResolutionService>องค์ประกอบจะถูกนำมาใช้EndpointIndexในการสร้างอาร์ติแฟกต์ประเภท SAML 0x0004
• องค์ประกอบต่างๆ ระบุว่า บริการ SSO รองรับ<md:NameIDFormat>รูปแบบตัวระบุชื่อ SAML (SAMLCore ^{[ 1 ] ) ใดบ้าง}
• คุณลักษณะBindingของ<md:SingleSignOnService>องค์ประกอบคือ URI มาตรฐานที่ระบุไว้ในข้อกำหนด SAML 2.0 Binding (SAMLBind ^{[ 2 ]} )
• คุณลักษณะLocationของ<md:SingleSignOnService>องค์ประกอบที่รองรับการผูกข้อมูล HTTP POST จะถูกนำไปใช้ในขั้นตอนที่ 2 ของโปรไฟล์ " double POST "
• คุณลักษณะLocationของ<md:SingleSignOnService>องค์ประกอบที่รองรับการผูก HTTP Artifact จะถูกนำไปใช้ในขั้นตอนที่ 2 ของโปรไฟล์ " double artifact "
• องค์ประกอบ นี้<saml:Attribute>อธิบายถึงคุณลักษณะที่ผู้ให้บริการยืนยันตัวตนยินดีที่จะกำหนด (ขึ้นอยู่กับนโยบาย) <saml:AttributeValue>องค์ประกอบอื่นๆ จะแสดงรายการค่าที่เป็นไปได้ที่คุณลักษณะนั้นอาจมีได้

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

เช่นเดียวกับผู้ให้บริการข้อมูลประจำตัว ผู้ให้บริการจะเผยแพร่ข้อมูลเกี่ยวกับตนเองใน<md:EntityDescriptor>องค์ประกอบ:

<md:EntityDescriptor entityID= "https://sp.example.com/SAML2" validUntil= "2013-03-22T23:00:00Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- แทรกองค์ประกอบ ds:Signature (ละเว้น) --> <!-- แทรกองค์ประกอบ md:SPSSODescriptor (ดูด้านล่าง) --> <md:Organization> <md:OrganizationName xml:lang= "en" >ผู้ขายเชิงพาณิชย์บางรายในแคลิฟอร์เนีย</md:OrganizationName> <md:OrganizationDisplayName xml:lang= "en" >บางรายผู้จำหน่ายเชิงพาณิชย์</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>

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

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

ตามคำจำกัดความ ผู้ให้บริการจะจัดการบริการผู้บริโภคการยืนยันที่สนับสนุนโปรไฟล์ SAML Web Browser SSO ที่ระบุไว้ใน SAMLProf ^{[ 3 ]}ดูตัวอย่างเช่น ผู้ให้บริการที่อธิบายไว้ใน<md:SPSSODescriptor>องค์ประกอบที่แสดงในส่วนถัดไป

ข้อความยืนยันว่าบริการลูกค้านั้นบรรจุอยู่ใน<md:SPSSODescriptor>องค์ประกอบ:

<md:SPSSODescriptor protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:KeyDescriptor use= "signing" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:KeyDescriptor use= "encryption" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:ArtifactResolutionService isDefault= "true" index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location= "https://sp.example.com/SAML2/ArtifactResolution" /> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress </md:NameIDFormat> <md:NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> <md:AssertionConsumerService isDefault= "true" index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "https://sp.example.com/SAML2/SSO/POST" /> <md:AssertionConsumerService index= "1" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location= "https://sp.example.com/SAML2/Artifact" /> <md:AttributeConsumingService isDefault= "true" index= "1" > <md:ServiceName xml:lang=" < md : RequestedAttribute> < 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.1" FriendlyName= "eduPersonAffiliation" > </md:RequestedAttribute> </md:AttributeConsumingService> </md:SPSSODescriptor>

โปรดสังเกตรายละเอียดต่อไปนี้เกี่ยวกับ<md:SPSSODescriptor>องค์ประกอบเมตาเดตา:

• ซอฟต์แวร์ของผู้ให้บริการได้รับการกำหนดค่าด้วยคีย์ลงนาม SAML ส่วนตัวและ/หรือคีย์ TLS ส่วนตัวสำหรับช่องทางการสื่อสารเบื้องหลัง คีย์สาธารณะที่เกี่ยวข้องจะรวมอยู่ใน<md:KeyDescriptor use="signing">องค์ประกอบในเมตาเดตาของผู้ให้บริการ เพื่อความกระชับ จึงได้ละเว้นรายละเอียดของคีย์ออกจากคำอธิบายคีย์
• ในทำนองเดียวกัน ซอฟต์แวร์ของผู้ให้บริการได้รับการกำหนดค่าด้วยคีย์ถอดรหัส SAML ส่วนตัว คีย์เข้ารหัส SAML สาธารณะรวมอยู่ใน<md:KeyDescriptor use="encryption">องค์ประกอบในเมตาเดตาของผู้ให้บริการ เนื้อหาของคีย์ถูกละเว้นจากคำอธิบายคีย์เพื่อความกระชับ
• แอตทริบิวต์indexของ<md:AssertionConsumerService>องค์ประกอบจะถูกใช้เป็นค่าของAssertionConsumerServiceIndexแอตทริบิวต์ใน<samlp:AuthnRequest>องค์ประกอบ นั้น
• คุณลักษณะBindingของ<md:AssertionConsumerService>องค์ประกอบคือ URI มาตรฐานที่ระบุไว้ในข้อกำหนด SAML 2.0 Binding (SAMLBind ^{[ 2 ]} )
• แอตทริบิวต์Locationของ<md:AssertionConsumerService>องค์ประกอบที่รองรับการผูก HTTP POST ( index="0") จะถูกใช้ในขั้นตอนที่ 4 ของโปรไฟล์ " double POST "
• คุณลักษณะLocationของ<md:AssertionConsumerService>องค์ประกอบที่รองรับการผูก HTTP Artifact ( index="1") จะถูกใช้ในขั้นตอนที่ 6 ของโปรไฟล์ " double artifact "
• องค์ประกอบ นี้<md:AttributeConsumingService>ถูกใช้โดยผู้ให้บริการยืนยันตัวตนเพื่อสร้าง<saml:AttributeStatement>องค์ประกอบที่จะถูกส่งไปยังผู้ให้บริการร่วมกับการเข้าสู่ระบบแบบ Single Sign-On (SSO) ผ่านเว็บเบราว์เซอร์
• แอตทริบิวต์indexของ<md:AttributeConsumingService>องค์ประกอบจะถูกใช้เป็นค่าของAttributeConsumingServiceIndexแอตทริบิวต์ใน<samlp:AuthnRequest>องค์ประกอบ นั้น

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

ในตัวอย่างก่อนหน้านี้<md:EntityDescriptor>แสดงให้เห็นว่าแต่ละองค์ประกอบมีการลงลายมือชื่อดิจิทัลแล้ว แต่ในทางปฏิบัติ<md:EntityDescriptor>องค์ประกอบหลายๆ อย่างจะถูกจัดกลุ่มเข้าด้วยกันภายใต้<md:EntitiesDescriptor>องค์ประกอบเดียวที่มีลายมือชื่อดิจิทัลเดียวครอบคลุมทั้งกลุ่ม:

<md:EntitiesDescriptor validUntil= "2013-03-22T23:00:00Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- แทรกองค์ประกอบ ds:Signature (ละไว้) --> <md:EntityDescriptor entityID= "https://idp.example.org/SAML2" > ... </md:EntityDescriptor> <md:EntityDescriptor entityID= "https://sp.example.com/SAML2" > ... </md:EntityDescriptor> </md:EntitiesDescriptor>

โปรดสังเกตรายละเอียดต่อไปนี้เกี่ยวกับ<md:EntitiesDescriptor>องค์ประกอบข้างต้น:

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

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

• ภาษามาร์กอัปการยืนยันความปลอดภัย
• SAML 1.1
• เมตาเดต้า SAML
• ผลิตภัณฑ์และบริการที่ใช้ SAML
• OpenID Connect