ภาษาการยืนยันความปลอดภัย (SAML) เป็น มาตรฐาน XMLสำหรับการแลกเปลี่ยน ข้อมูล การตรวจสอบสิทธิ์และการอนุญาตระหว่างโดเมนความปลอดภัย SAML เป็นผลิตภัณฑ์ของคณะกรรมการด้านเทคนิคบริการความปลอดภัยขององค์กร OASIS

SAML 1.1ได้รับการรับรองเป็นมาตรฐาน OASIS ในเดือนกันยายน พ.ศ. 2546 ประเด็นสำคัญของ SAML 1.1 ได้รับการกล่าวถึงโดยละเอียดในเอกสารทางการ SAMLCore ^{[ 1 ]}และ SAMLBind ^{[ 2 ]} หากคุณยังใหม่กับ SAML คุณควรศึกษา หัวข้อ SAMLเบื้องต้นก่อน จากนั้นจึงศึกษาเอกสาร SAMLOverview ^{[ 3 ]}จาก OASIS

ก่อน SAML 1.1 นั้นSAML 1.0ได้รับการยอมรับเป็นมาตรฐาน OASIS ในเดือนพฤศจิกายน 2545 SAML ได้มีการปรับปรุงเล็กน้อยหนึ่งครั้ง (V1.1) และการปรับปรุงครั้งใหญ่หนึ่งครั้ง (V2.0) นับตั้งแต่ V1.0 ซึ่งตัวมันเองก็เป็นโปรโตคอลที่ค่อนข้างง่าย อย่างไรก็ตาม SAML 1.0 มีความสำคัญมากกว่าแค่ในเชิงประวัติศาสตร์ เนื่องจากโครงการริเริ่มการตรวจสอบสิทธิ์ทางอิเล็กทรอนิกส์ ของรัฐบาลกลางสหรัฐฯ ได้นำ SAML 1.0 มาใช้เป็นเทคโนโลยีหลักของตน

SAML เวอร์ชัน 1.0 และ 1.1 มีความคล้ายคลึงกัน ดู SAMLDiff ^{[ 4 ]}สำหรับความแตกต่างเฉพาะระหว่างมาตรฐานทั้งสอง บทความนี้เน้นที่ SAML 1.1 เนื่องจากเป็นมาตรฐานที่สำคัญซึ่งมาตรฐานและการใช้งานอื่นๆ อีกมากมายขึ้นอยู่กับ

คำเตือน:ผู้พัฒนาและผู้ติดตั้งควรทราบว่าตัวอย่างโค้ดทั้งหมดในบทความนี้ไม่ใช่มาตรฐานและใช้เพื่อแสดงตัวอย่างเท่านั้น โปรดศึกษา ข้อกำหนด มาตรฐานในเอกสารข้อกำหนด OASIS SAML

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

<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" AssertionID= "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer= "https://idp.example.org/saml" IssueInstant= "2002-06-19T17:05:37.795Z" > <saml:Conditions NotBefore= "2002-06-19T17:00:37.795Z" NotOnOrAfter= "2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement AuthenticationMethod= "urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant= "2002-06-19T17:05:17.706Z" > <saml:Subject> <saml:NameIdentifier Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > [email protected] </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:bearer </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion>

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

<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" Issuer= "https://idp.example.org/saml" ... > <saml:Conditions NotBefore= "..." NotAfter= "..." /> <saml:AuthenticationStatement AuthenticationMethod= "..." AuthenticationInstant= "..." > <saml:Subject> ... </saml:Subject> </saml:AuthenticationStatement> <saml:AttributeStatement> <saml:Subject> ... </saml:Subject> <saml:Attribute AttributeName= "urn:mace:dir:attribute-def:eduPersonAffiliation" AttributeNamespace= "urn:mace:shibboleth:1.0:attributeNamespace:uri" > <saml:AttributeValue>สมาชิก</saml:AttributeValue> <saml:AttributeValue>นักเรียน</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

โดยทั่วไปแล้ว คุณสมบัติต่างๆ มักได้มาจาก ไดเร็กทอรี LDAPดังนั้นการแสดงคุณสมบัติอย่างสม่ำเสมอในโดเมนความปลอดภัยต่างๆ จึงมีความสำคัญอย่างยิ่ง

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

<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" Issuer= "https://idp.example.org/saml" ... > <saml:Conditions ... /> <saml:AuthorizationDecisionStatement Decision= "Permit" Resource= "https://sp.example.com/confidential_report.html" > <saml:Subject> ... </saml:Subject> <saml:Action>อ่าน</saml:Action> </saml:AuthorizationDecisionStatement> </saml:Assertion>

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

โปรโตคอล SAML เป็นโปรโตคอลแบบร้องขอ-ตอบกลับที่เรียบง่าย ผู้ร้องขอ SAML จะส่งRequestองค์ประกอบ SAML ไปยังผู้ตอบกลับ:

<samlp:Request xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" RequestID= "aaf23196-1773-2113-474a-fe114412ab72" IssueInstant= "2006-07-17T22:26:40Z" > <!-- แทรกองค์ประกอบ SAML อื่นๆ ที่นี่ --> </samlp:Request>

ในทำนองเดียวกัน ตัวตอบ SAML จะส่งองค์ประกอบ SAML กลับResponseไปยังผู้ร้องขอ:

<samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "b07b804c-7c29-ea16-7300-4f3d6f7928ac" InResponseTo= "aaf23196-1773-2113-474a-fe114412ab72" IssueInstant= "2006-07-17T22:26:41Z" > <!-- แทรกองค์ประกอบ SAML อื่นๆ ที่นี่ รวมถึง assertion --> </samlp:Response>

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

SAML 1.1 กำหนดโปรโตคอลการผูกข้อมูล เพียงโปรโตคอลเดียวอย่างเป็นทางการ นั่นคือ การผูกข้อมูล SAML SOAP การใช้งาน SAML 1.1 ที่เข้ากันได้จะต้องใช้งาน SAML ผ่าน SOAP ผ่าน HTTP (การผูกโปรโตคอลแบบซิงโครนัส) กลไกการขนส่งอื่นๆ นอกเหนือจาก HTTP ได้รับอนุญาต ตราบใดที่ยังคงรักษาคุณสมบัติที่ไม่ขึ้นกับโปรโตคอลของการผูกข้อมูล SAML SOAP ไว้ (ดูหัวข้อ 3.1.2 ของ SAMLBind ^{[ 2 ]} )

การเชื่อมต่อ SAML 1.1 SOAP สร้างขึ้นบนพื้นฐานของSOAP เวอร์ชัน 1.1 (การกำหนดหมายเลขเป็นเพียงเรื่องบังเอิญ) ผู้ร้องขอ SAML จะห่อหุ้มRequestองค์ประกอบ SAML ไว้ภายในเนื้อหาของข้อความ SOAP ในทำนองเดียวกัน ผู้ตอบ SAML จะส่งคืนResponseองค์ประกอบ SAML ภายในเนื้อหาของข้อความ SOAP ที่ส่งคืน หากมีข้อผิดพลาด ผู้ตอบจะส่งคืนรหัสข้อผิดพลาด SOAP แทน

โค้ด SAML ใดๆ ต้องรวมอยู่ในส่วนเนื้อหาของ SOAP SAML 1.1 ไม่ได้กำหนดส่วนหัว SOAP เฉพาะสำหรับ SAML ผู้ร้องขอสามารถแทรกส่วนหัว SOAP ใดๆ ก็ได้ตามต้องการ (แม้ว่าจะไม่มีข้อกำหนดบังคับก็ตาม)

โปรดจำไว้ว่าใน SOAP 1.1 SOAPActionจะต้องมีส่วนหัว HTTP รวมอยู่กับคำขอ HTTP ทุกครั้ง (แม้ว่าค่าของส่วนหัวอาจว่างเปล่าก็ได้) ผู้ร้องขอ SAML อาจกำหนดค่าต่อไปนี้ให้กับSOAPActionส่วนหัว:

SOAPAction: http://www.oasis-open.org/committees/security 

อย่างไรก็ตาม ตัวตอบรับ SAML ไม่ควรพึ่งพาค่านี้

การเชื่อมต่อที่ปลอดภัยไม่จำเป็นสำหรับคำขอและการตอบกลับ SAML แต่ในสถานการณ์ที่ ต้องการ ความสมบูรณ์และความลับ ของข้อความ จำเป็นต้องใช้ HTTP ผ่าน SSL 3.0 หรือ TLS 1.0 พร้อมใบรับรองฝั่งเซิร์ฟเวอร์

ตัวตอบ SAML อาจส่งการตอบกลับ "403 Forbidden" เมื่อปฏิเสธการตอบสนองต่อผู้ร้องขอ SAML ในกรณีที่เกิดข้อผิดพลาด SOAP ตัวตอบต้องส่งการตอบกลับ "500 Internal Server Error" (ต้องมีองค์ประกอบ SOAP fault รวมอยู่ด้วย) มิเช่นนั้น จะส่งการตอบกลับ "200 OK" แม้ว่าจะมีข้อผิดพลาดในการประมวลผล SAML ก็ตาม การตอบกลับดังกล่าวจะรวมStatusองค์ประกอบ SAML ไว้ในส่วนเนื้อหาของ SOAP ด้วย

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

1. โปรไฟล์เบราว์เซอร์/POST
2. โปรไฟล์เบราว์เซอร์/อาร์ติแฟกต์

โปรไฟล์ Browser/POST อาศัยการทำงานแบบ "พุช" ซึ่งส่งการยืนยัน SSO ผ่านค่าโดยใช้ HTTP POST เรากล่าวว่าผู้ให้บริการข้อมูลประจำตัว "พุช" การยืนยันไปยังผู้ให้บริการบริการ

โปรไฟล์เบราว์เซอร์/อาร์ติแฟกต์ใช้กลไกแบบ "ดึง" (pull) โดยพื้นฐานแล้ว โปรไฟล์จะส่งการยืนยัน SSO จากผู้ให้บริการข้อมูลประจำตัวไปยังผู้ให้บริการโดยการอ้างอิง (ผ่านเบราว์เซอร์โดยใช้การเปลี่ยนเส้นทาง HTTP) ซึ่งจะถูกดึงกลับโดยการแลกเปลี่ยนแบบ back-channel (กล่าวคือ ผู้ให้บริการ "ดึง" การยืนยันจากผู้ให้บริการข้อมูลประจำตัวโดยใช้ SAML ผ่าน SOAP ผ่าน HTTP)

โปรไฟล์เหล่านี้รองรับ การเข้าสู่ระบบครั้งเดียว (SSO) ข้ามโดเมนข้อกำหนดไม่ได้กำหนดโปรไฟล์เพิ่มเติมใดๆ โดยเฉพาะอย่างยิ่ง SAML 1.1 ไม่รองรับโปรไฟล์เพื่อรักษาความปลอดภัย ข้อความ บริการเว็บและไม่รองรับโปรไฟล์การออกจากระบบครั้งเดียว

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

หลังจากเข้าใช้บริการโอนย้ายระหว่างไซต์แล้ว ผู้ใช้งานหลักจะถูกโอนไปยังบริการผู้บริโภคการยืนยันที่ผู้ให้บริการ วิธีการโอนย้ายผู้ใช้งานหลักจากบริการโอนย้ายระหว่างไซต์ไปยังบริการผู้บริโภคการยืนยันนั้นขึ้นอยู่กับโปรไฟล์ที่ใช้ ในกรณีของโปรไฟล์ Browser/Artifact จะใช้การเปลี่ยนเส้นทาง (redirect) ในกรณีของโปรไฟล์ Browser/POST ลูกค้าจะส่งคำขอ POST (โดยมีหรือไม่มีการแทรกแซงจากผู้ใช้)

เพื่อเร่งกระบวนการประมวลผลโดยบริการผู้บริโภคการยืนยัน จึงมีการระบุ URL สองรายการแยกกัน:

1. URL ของผู้บริโภคที่ยืนยัน (โปรไฟล์เบราว์เซอร์/POST)
2. URL ตัวรับอาร์ติแฟกต์ (เบราว์เซอร์/โปรไฟล์อาร์ติแฟกต์)

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

โปรดทราบว่าผู้ให้บริการข้อมูลประจำตัว SAML 1.1 ที่เป็นไปตามมาตรฐานจะต้องให้บริการการถ่ายโอนข้อมูลระหว่างไซต์ ในทำนองเดียวกัน ผู้ให้บริการ SAML 1.1 จะต้องให้บริการผู้บริโภคการยืนยันข้อมูลด้วย

โปรไฟล์ SAML 1.1 Browser/POST ระบุขั้นตอนสี่ (4) ขั้นตอนดังต่อไปนี้ คำศัพท์ที่ใช้ในข้อกำหนดเดิมได้รับการแก้ไขเล็กน้อยเพื่อให้สอดคล้องกับข้อกำหนด SAML 2.0

กระบวนการส่งข้อความเริ่มต้นด้วยคำขอที่ส่งไปยัง IdP (Identity Provider)

ผู้ใช้งานหลัก (ผ่านตัวแทนผู้ใช้ HTTP) ร้องขอการบริการโอนย้ายข้อมูลระหว่างไซต์ที่ผู้ให้บริการยืนยันตัวตน:

https://idp.example.org/TransferService?TARGET= target

โดย ที่targetทรัพยากรที่ต้องการอยู่ที่ผู้ให้บริการ เช่น https://sp.example.com/home กล่าวคือ ตัวแทนผู้ใช้จะส่งคำขอ GET ต่อไปนี้ผ่าน SSL/TLS:

GET /TransferService?TARGET=target HTTP / 1.1 Host : idp.example.org

โปรไฟล์ไม่ได้ระบุวิธีการที่TARGETเอเจนต์ผู้ใช้ได้รับ URL ของบริการโอนย้าย (พร้อมพารามิเตอร์)

บริการถ่ายโอนข้อมูลระหว่างไซต์จะส่งคืนเอกสาร HTML ที่มีFORMองค์ประกอบ <html >:

HTTP / 1.1 200 OK Content-Type : text/html Content-Length : nnnn ... < form method = "post" action = "https://sp.example.com/ACS/POST" ... > < input type = "hidden" name = "TARGET" value = "target" /> < input type = "hidden" name = "SAMLResponse" value = "''response'" /> ... < input type = "submit" value = " Submit" / > </form> ... 

โดยที่TARGETพารามิเตอร์ได้รับการเก็บรักษาไว้จากขั้นตอนที่ 1 ค่าของSAMLResponseพารามิเตอร์คือ การเข้ารหัส แบบ base64ขององค์ประกอบ SAML Responseดังต่อไปนี้:

<samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "_P1YaA+Q/wSM/t/8E3R8rNhcpPTM=" IssueInstant= "2002-06-19T17:05:37.795Z" > <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "samlp:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= " < saml:Conditions NotBefore= " 2002-06-19T17:00:37.795Z " NotOnOrAfter= " 2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement AuthenticationMethod = "urn:oasis:names: tc : SAML :1.0 :am : password" AuthenticationInstant= " 2002-06-19T17:05:17.706Z" > < saml :Subject> <saml:NameIdentifier Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > [email protected] </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:bearer </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response>

การตอบสนอง SAML ต้องได้รับการลงลายมือชื่อดิจิทัลโดยผู้ให้บริการยืนยันตัวตน

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

ตัวแทนผู้ใช้ร้องขอ Assertion Consumer Service จากผู้ให้บริการ:

POST /ACS/POST HTTP / 1.1 Host : sp.example.com Content-Type : application/x-www-form-urlencoded Content-Length : nnnn TARGET=target&SAMLResponse=response

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

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

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

แน่นอนว่านี่ถือว่าหน้าเว็บมีFORMองค์ประกอบเพียงรายการเดียว ( forms[0])

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

โปรไฟล์เบราว์เซอร์/อาร์ติแฟกต์ SAML 1.1 ระบุขั้นตอนหก (6) ขั้นตอนดังต่อไปนี้ คำศัพท์ที่ใช้ในข้อกำหนดเดิมได้รับการแก้ไขเล็กน้อยเพื่อให้สอดคล้องกับข้อกำหนด SAML 2.0

กระบวนการส่งข้อความเริ่มต้นด้วยคำขอที่ส่งไปยัง IdP (Identity Provider)

ผู้ใช้งานหลัก (ผ่านตัวแทนผู้ใช้ HTTP) ร้องขอการบริการโอนย้ายข้อมูลระหว่างไซต์ที่ผู้ให้บริการยืนยันตัวตน:

https://idp.example.org/TransferService?TARGET= target

โดย ที่targetทรัพยากรที่ต้องการอยู่ที่ผู้ให้บริการ เช่น https://sp.example.com/home กล่าวคือ ตัวแทนผู้ใช้จะส่งคำขอ GET ต่อไปนี้ผ่าน SSL/TLS:

GET /TransferService?TARGET=target HTTP / 1.1 Host : idp.example.org

โปรไฟล์ไม่ได้ระบุวิธีการที่TARGETเอเจนต์ผู้ใช้ได้รับ URL ของบริการถ่ายโอน (พร้อมพารามิเตอร์)

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

HTTP / 1.1 302 Found Location : https://sp.example.com/ACS/Artifact?TARGET=target&SAMLart=artifact

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

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

ตัวแทนผู้ใช้ร้องขอ Assertion Consumer Service จากผู้ให้บริการ:

https://sp.example.com/ACS/Artifact?TARGET= target &SAMLart= สิ่งประดิษฐ์

โดยที่targetและartifactยังคงเหมือนเดิม กล่าวคือ ตัวแทนผู้ใช้จะส่งคำขอ GET ต่อไปนี้ผ่าน SSL/TLS:

GET /ACS/Artifact?TARGET=target&SAMLart=artifact HTTP / 1.1 Host : sp.example.com

บริการ Assertion Consumer Service ของผู้ให้บริการจะเริ่มต้นการแลกเปลี่ยนข้อมูลแบบ back-channel กับบริการ Artifact Resolution Service ของผู้ให้บริการข้อมูลประจำตัว โดยข้อความ SAML SOAP จะถูกผูกเข้ากับคำขอ HTTP POST:

POST /ArtifactResolutionService HTTP/1.1 โฮสต์: idp.example.org ประเภทเนื้อหา: ข้อความ/XML ความยาวของเนื้อหา: nnn SOAPAction: http://www.oasis-open.org/committees/security <SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header/> <SOAP-ENV:Body> <samlp:Request xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" RequestID= "_192.168.16.51.1024506224022" IssueInstant= "2002-06-19T17:03:44.022Z" > <samlp:AssertionArtifact> artifact </samlp:AssertionArtifact> </samlp:Request> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

โดยข้อมูลartifactดังกล่าวถูกส่งมาจากผู้ให้บริการยืนยันตัวตนไปยังผู้ให้บริการในขั้นตอนที่ 2 และ 3 ก่อนหน้านี้

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

HTTP/1.1 200 OK ประเภทเนื้อหา: ข้อความ/XML Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header/> <SOAP-ENV:Body> <samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "_P1YaA+Q/wSM/t/8E3R8rNhcpPTM=" InResponseTo= "_192.168.16.51.1024506224022" IssueInstant= "2002-06-19T17:05:37.795Z" > <samlp:Status> <samlp:StatusCode Value= <samlp: Status > <samlp: Assertion xmlns:saml=" urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= " 1 " AssertionID= "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer= "https://idp.example.org/saml" IssueInstant= "2002-06-19T17:05:37.795Z" > <saml:Conditions NotBefore= "2002-06-19T17:00:37.795Z" NotOnOrAfter= "2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement AuthenticationMethod=" "urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant= "2002-06-19T17:05:17.706Z" > <saml:Subject> <saml:NameIdentifier Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > [email protected] </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:artifact </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

ในกรณีนี้ ข้อความยืนยันตัวตนจะประกอบด้วยNameIdentifierที่อยู่อีเมลของผู้ใช้งานหลัก

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

• SAML
• SAML 2.0
• ผลิตภัณฑ์และบริการที่ใช้ SAML