بيانات تعريف SAML

يشير مصطلح البيانات الوصفية الثابتة إلى ملف بيانات وصفية يُضاف مباشرةً إلى تطبيق SAML بواسطة مسؤول النظام. وبذلك، يصبح المسؤول مسؤولاً عن صيانة البيانات الوصفية بغض النظر عن كيفية الحصول عليها في الأصل. وبالتالي، تُسهم البيانات الوصفية الثابتة في التكوين الثابت العام لتطبيق SAML.

لسوء الحظ، تتسم بيانات تعريف SAML بطبيعتها غير الثابتة، كما يتضح من السيناريو النموذجي التالي بين موفر هوية SAML (IdP) وموفر خدمة SAML (SP). لنفترض أن مالك موفر الهوية (IdP) يحصل على بيانات تعريف SAML من شريك مزود الخدمة (SP). قد تُرسل بيانات تعريف مزود الخدمة إلى مالك موفر الهوية عبر البريد الإلكتروني، أو قد يقوم مالك موفر الهوية بتسجيل الدخول إلى تطبيق ويب محمي وتنزيل بيانات تعريف مزود الخدمة عبر متصفح. بغض النظر عن كيفية الحصول على بيانات التعريف، فإن النتيجة واحدة: يقوم مالك موفر الهوية بتكوين بيانات تعريف مزود الخدمة مباشرةً في برنامج موفر الهوية.

لنفترض الآن أن بيانات تعريف موفر الخدمة (SP) تحتوي على مفتاح تشفير عام. من المفترض أن مفتاح فك التشفير الخاص المقابل مُهيأ في برنامج موفر الخدمة. إذا تم اختراق مفتاح فك التشفير الخاص (أو إذا لزم استبداله لأي سبب آخر)، فإن مفتاح التشفير العام في بيانات تعريف موفر الخدمة يصبح غير موثوق به ويجب استبداله أيضًا.

بما أن بيانات تعريف موفر الخدمة (SP) مُهيأة بشكل ثابت في برنامج موفر الهوية (IdP)، فإن مالك موفر الهوية هو الوحيد القادر على استبدال مفتاح التشفير العام في بيانات تعريف موفر الخدمة. وبالتالي، يتحمل مالك موفر الهوية مسؤولية بيانات تعريف موفر الخدمة. يؤدي هذا التباين إلى مشاكل في التوافق بين الأنظمة.

وينطبق الأمر نفسه على جانب موفر الخدمة. فمن خلال تكوين بيانات تعريف موفر الهوية بشكل ثابت في برنامج موفر الخدمة، يتحمل مالك موفر الخدمة ضمنيًا مسؤولية صيانة بيانات تعريف موفر الهوية عند حدوث أي تغيير. ونظرًا لأن موفر الهوية (أو موفر الخدمة) عادةً ما يكون لديه العديد من الشركاء، فإن تكوين بيانات التعريف الثابتة لا يتناسب مع التوسع، فضلًا عن أن إدارة التغييرات المرتبطة ببيانات التعريف الثابتة صعبة للغاية.

ليس من المستغرب أن تتوق عمليات مشاركة البيانات الوصفية إلى الأتمتة. فكل ملف بيانات وصفية يُهيأ بشكل ثابت في تطبيق SAML بواسطة مسؤول النظام يُراكم ديونًا تقنية. ويمنع تراكم هذه الديون تطبيق SAML من التوسع إلى أقصى إمكاناته.

لتجنب تراكم الديون التقنية، يجب أتمتة عملية مشاركة البيانات الوصفية. يتمثل أحد الحلول في الاستعانة بطرف ثالث موثوق به، يتولى مسؤولية جمع البيانات الوصفية وتنسيقها وتوزيعها عبر الشبكة. تتميز البيانات الوصفية المنسقة بتنسيق موحد، وهي أقل عرضة للثغرات الأمنية (سواء كانت مقصودة أم لا)، وبالتالي فهي آمنة للاستخدام.

في حالة بيانات تعريف SAML، يُطلق على هذا الطرف الثالث الموثوق اسم اتحاد SAML. يلتزم مجتمع مُستخدمي SAML المُكوّن للاتحاد طواعيةً بواحد أو أكثر من ملفات تعريف SAML لتعزيز قابلية التشغيل البيني والثقة. ولتحقيق هذه الغاية، غالبًا ما يتشارك المشاركون في الاتحاد بنية تحتية مركزية لتبادل بيانات التعريف، مما يسمح للاتحاد بالتوسع ليشمل آلاف عمليات نشر SAML القابلة للتشغيل البيني.

استجابةً لبروتوكول مايكروسوفت باسبورت ، ابتكر تحالف ليبرتي إطار عمل اتحاد الهوية ( ID-FF) ، وهي تقنية اتحادية طُوّرت على مدى ثلاث سنوات بين عامي 2002 و2004. ( يُوفّر تاريخ بروتوكول SAML  المذكور سابقًا سياقًا لفهم إطار عمل اتحاد الهوية). في 14 نوفمبر 2003، قدّم تحالف ليبرتي الإصدار  1.2 من إطار عمل اتحاد الهوية إلى منظمة OASIS . تضمنت هذه المساهمة وثيقة بعنوان " مواصفات وصف واكتشاف بيانات ليبرتي الوصفية  ، الإصدار 1.0 " ^{[ LibertyMeta 1 ]} ، والتي تضمنت أهداف التصميم التالية:

1. " whois for SAML federations" (استنادًا إلى عنصري " Organizationو" ContactPersonفي البيانات الوصفية)
2. اكتشاف البيانات الوصفية بشكل ديناميكي (مع حل عبر نظام أسماء النطاقات والموقع المعروف جيدًا)
3. أمان على مستوى المستند باستخدام توقيع XML

وكما اتضح، فقد تم الحفاظ على كل تلك الأهداف في  معيار البيانات الوصفية OASIS SAML V2.0 الموصوف لاحقًا في هذه المقالة.

يُعرَّف مستند المخطط المرفق بأرشيف Liberty ID-FF  1.2  القديم باسم Liberty Metadata الإصدار 1.1، بينما  تم تقديم Liberty Metadata الإصدار 1.0 إلى منظمة OASIS. وقد أوضح مؤلف المخطط هذا التناقض الظاهر (بيتر ديفيس، مراسلة شخصية). بين نوفمبر 2003 (عندما  تم تقديم الإصدار 1.0 إلى OASIS) وديسمبر 2004 (عندما  أكملت Liberty الإصدار 1.1)، استمر تطوير مواصفات Liberty metadata بالتوازي مع مسار عمل OASIS. انظر الرسم البياني أدناه للاطلاع على تمثيل مرئي. تشير الأسهم في الرسم البياني إلى التبعيات، بينما تشير الخطوط المتقطعة إلى أوجه التكافؤ.

تُقدَّم المراجع ذات الصلة بمشروع Liberty في نهاية هذه المقالة. يُمكن الاطلاع على مخطط البيانات الوصفية الأصلي المُساهم به في OASIS كاملاً في القسم  7 من مواصفات Liberty Metadata الإصدار  1.0 ^{[ LibertyMeta 1 ]} . وبالمثل، تتضمن مواصفات Liberty Metadata الإصدار  1.1 ^{[ LibertyMeta 2 ]} قائمة بمخطط الإصدار  1.1. يُمكن الوصول إلى كلٍّ من مخطط الإصدار  1.0 ومخطط الإصدار  1.1 هنا عبر موقع Wayback Machine التابع لأرشيف الإنترنت .

على مدى الأشهر الثلاثة عشر التالية، من نوفمبر 2003 إلى ديسمبر 2004، قامت اللجنة الفنية لخدمات أمن منظمة OASIS (SAML) بتطوير مواصفات بيانات Liberty الوصفية لتصبح ما عُرف لاحقًا باسم بيانات SAML الوصفية. خلال تلك الفترة، عمّمت اللجنة مواصفات البيانات الوصفية لتشمل دعم بروتوكولات متعددة (بما في ذلك بروتوكولات غير SAML)، والأهم من ذلك، تمّ تحديث مخطط بيانات Liberty الوصفية بإضافة العديد من نقاط التوسعة. تاريخيًا، كان لتوسيع نطاق بيانات SAML الوصفية آثارٌ بالغة الأهمية، كما سنرى.

بحلول مارس 2004، تم دمج معظم مساهمة مشروع ليبرتي في مسار عمل منظمة أواسيس. ^{[ SAMLMeta 1 ]} ومنذ ذلك الحين، سار مسارا عمل ليبرتي وأواسيس بالتوازي (ولكن ليس بشكل مستقل، حيث كان نفس الأشخاص يعملون على كلا المواصفتين). وبين مارس ويوليو 2004، شهدت مواصفة بيانات تعريف SAML الناشئة تغييرات كبيرة.

في يوليو 2004، أصدرت لجنة SSTC دعوة عامة لتقديم التعليقات على مجموعة كاملة من  مسودات مواصفات SAML V2.0. وتضمنت هذه المجموعة مسودة عمل  لمواصفات بيانات تعريف SAML V2.0 المُصاغة حديثًا. ^{[ SAMLMeta 2 ]}

بالنظر إلى الماضي، يبدو أن الجزء الأكبر من  مواصفات بيانات SAML V2.0 الوصفية قد تم تطويره بين مارس ويوليو 2004، ولكن من الواضح أن  معيار بيانات SAML V2.0 الوصفية قد انبثق من رحم تحالف ليبرتي، وتحديداً بيانات ليبرتي الوصفية الإصدار  1.0. ^{[ LibertyMeta 1 ]} وبالتالي، لفهم أصول بيانات SAML الوصفية، يجب دراسة مصدر بيانات ليبرتي الوصفية.

أما ما تبقى من تاريخ بيانات تعريف SAML فهو في معظمه عملية إدارية لمنظمة OASIS. بعد نشر المسودة النهائية للجنة في نوفمبر 2004، ^{[ SAMLMeta 3 ]،} بدأت لجنة SSTC عملية التقييس في يناير 2005. وأخيرًا، في 5  مارس 2005، أعلنت OASIS عن معيار SAML V2.0 المُعتمد حديثًا  .

تضمنت مجموعة مواصفات الإصدار 2.0 (انظر قسم المراجع  للاطلاع على القائمة الكاملة) مواصفات بيانات تعريف SAML V2.0 النهائية . ^{[ OS 1 ]} بعد عقد من الزمن، في سبتمبر 2015، نشرت منظمة OASIS مواصفات بيانات تعريف SAML منقحة مع تصحيحات. ^{[ OS 3 ]} ونتيجة لذلك، تم إيقاف العمل بمواصفات بيانات التعريف الأصلية، وكذلك الوثائق الأخرى في مجموعة مواصفات الإصدار 2.0 الأصلية.

خلال العقد الفاصل بين عامي 2005 و2015، وضعت لجنة SSTC عدداً من مسودات المواصفات "ما بعد الإصدار 2.0". وقد تحولت بعض هذه المسودات إلى مواصفات معتمدة من قبل اللجنة. ويرد في قسم المراجع في نهاية هذه المقالة مجموعة مختارة من هذه المواصفات.

اتضح أن تأثير إطار عمل اتحاد هوية ليبرتي على بيانات تعريف SAML يسبق مساهمة ID-FF  1.2 في نوفمبر 2003. ويبدو أن SSTC كانت تعمل على بيانات التعريف بالتوازي مع تحالف ليبرتي. ويؤكد ذلك مقتطف من مسودة مواصفات بيانات التعريف المنشورة في سبتمبر 2003.

تحدد هذه الوثيقة البيانات الوصفية التي تصف العناصر والخصائص المطلوبة لاستخدام ملفات تعريف تسجيل الدخول الموحد (SSO) لمتصفح الويب SAML. ونظرًا لأن ملفات تعريف تسجيل الدخول الموحد (SSO) لمتصفح الويب الخاصة بتحالف ليبرتي تستند مباشرةً إلى ملفات تعريف تسجيل الدخول الموحد (SSO) لمتصفح الويب SAML، فإن البيانات الوصفية المحددة في هذه الوثيقة تستقي بشكل كبير من تعريفات البيانات الوصفية الواردة في مسودة  مواصفات تحالف ليبرتي 1.2. (مقتطف من "البيانات الوصفية  لملفات تعريف تسجيل الدخول الموحد (SSO) لمتصفح الويب SAML 2.0" ^{[ SAMLMeta 4 ]} )

يُقدّم سجلّ التعديلات في نهاية مسودة الوثيقة وصفًا لها على النحو التالي: "مسودة أولية مبنية على المسودة  07 من  مواصفات بيانات التعريف SAML 1.1". بعبارة أخرى، نُشرت مسودات سابقة. في الواقع، يُظهر سجلّ التعديلات في نهاية المسودة السابقة ^{[ SAMLMeta 5 ]} سلسلة من مواصفات بيانات التعريف تعود إلى نوفمبر 2002.

بتتبع مسار الوثائق، يمكن تتبع تأثير Liberty ID-FF على بيانات تعريف SAML إلى مسودة مواصفات نُشرت في أبريل 2003. ^{[ SAMLMeta 6 ]} هذه هي أول وثيقة معروفة من OASIS تُشير إلى Liberty ID-FF، وتحديدًا Liberty Metadata الإصدار  1.0-06، ^{[ LibertyMeta 3 ]} وهي نسخة مبكرة من مواصفات Liberty Metadata لا يُعرف عنها الكثير. ومع ذلك، من الواضح أن "بيانات تعريف  ملفات تعريف متصفح الويب SAML 1.1" كانت مُصممة لتكون مُكملة لمعيار SAML  V1.1، ولكننا نعلم بالطبع أن الإصدار V1.1 لا يُحدد استخدام بيانات التعريف. انظر القسم التالي للاطلاع على التخمينات ذات الصلة.

قد يكون هناك نوعان من مخططات البيانات الوصفية المبكرة ذات أهمية:

1. في يونيو 2002، وبعد شهر واحد فقط من إتمام لجنة SSTC عملها على ما أصبح فيما بعد  معيار SAML V1.0، طوّر مشروع Shibboleth مخطط بيانات وصفية يتألف من عناصر <OriginSite>محددة <DestinationSite>. وقد اعتمد هذا المخطط على الإصدارات الأولية لبرنامج Shibboleth IdP.
2. في فبراير 2003، أصدرت SSTC مسودة مخطط لمواصفات البيانات الوصفية بعنوان "البيانات الوصفية لملفات تعريف متصفح الويب SAML 1.0". ^{[ SAMLMeta 7 ]} ومع ذلك، لا يزال هذا المخطط مثيرًا للفضول، حيث أن الإصدار التالي مباشرة من تدفق المستندات هذا (وجميع الإصدارات اللاحقة) سيعرض صيغة البيانات الوصفية Liberty.

لا يوجد دليل يشير إلى أن أيًا من هاتين المحاولتين المبكرتين لتحديد مخطط البيانات الوصفية كان لهما أي تأثير ملحوظ على تطوير مخطط البيانات الوصفية الخاص بـ Liberty.

نعلم أن معايير البيانات الوصفية لـ SAML  الإصدار 1.0 أو SAML  الإصدار 1.1 لم تُنشر قط. كما نعلم أن حقوق الملكية الفكرية اللازمة لبيانات Liberty الوصفية لم تكن مُفعّلة حتى نوفمبر 2003. وبناءً على ذلك، نقدم الملخص والتخمين التاليين:

1. كانت مسودة المواصفات بعنوان "بيانات تعريفية لملفات  تعريف متصفح الويب SAML 1.0" ^{[ SAMLMeta 8 ]} أول مواصفات معروفة لبيانات تعريف SAML. ويحمل المستند تاريخ 12  نوفمبر 2002، أي بعد أسبوع واحد من الإعلان عن معيار SAML  V1.0، وهو أمر مثير للريبة. وعلى أي حال، فإن صيغة البيانات التعريفية المستخدمة في ذلك المستند تختلف تمامًا عما نعرفه اليوم باسم بيانات تعريف SAML. لم يُنشر ذلك المستند قط، ولا تزال أصوله غامضة.
2. كانت مسودة المواصفات بعنوان "البيانات الوصفية لملفات  تعريف متصفح الويب SAML 1.1" ^{[ SAMLMeta 6 ]} أول مواصفات معروفة للبيانات الوصفية لـ SAML تستند إلى Liberty ID-FF. وقد اكتملت في أبريل 2003. ويوضح عنوان مسودة المواصفات أن لجنة SSTC كانت على علم  بقدوم SAML V1.1، وأن البيانات الوصفية لـ SAML كانت ستُدرج في  معيار SAML V1.1.
3. لسوء الحظ، لم يحدث ذلك لأن حقوق الملكية الفكرية اللازمة لم تكن متوفرة عند  الإعلان عن معيار SAML V1.1. في الواقع، جاءت المساهمة الرسمية لـ Liberty ID-FF 1.2 في منظمة OASIS بعد شهرين من الإعلان عن معيار SAML  V1.1 في سبتمبر 2003.
4. في سبتمبر 2003، وبعد أقل من أسبوعين من الإعلان عن  معيار SAML V1.1، وجهت لجنة SSTC أنظارها نحو SAML  V2.0 من خلال إنشاء نسخة من مسار المستند وإعادة تسمية مسودة المستند إلى: "البيانات الوصفية  لملفات تعريف متصفح الويب SAML 2.0". ^{[ SAMLMeta 4 ]}
5. ظهرت بيانات تعريف SAML بين مارس ويوليو 2004. أصدرت لجنة SSTC دعوة عامة لتقديم التعليقات تضمنت مواصفات مرشحة لبيانات تعريف SAML. ^{[ SAMLMeta 2 ]}
6. تم تضمين مواصفات SAML Metadata النهائية ^{[ OS 1 ]} في مجموعة مواصفات SAML  V2.0 القياسية التي تم الإعلان عنها في مارس 2005.
7. على مدى السنوات العشر التالية، تطورت وثائق المواصفات (لكن المخطط ظل ثابتًا). نُشرت مواصفات  بيانات تعريف SAML V2.0 مع تصحيحات الأخطاء (SAMLMeta20Errata ^{[ OS 3 ] ) في سبتمبر 2015.}

كما ذُكر سابقًا، يحتوي مخطط بيانات تعريف SAML  V2.0 ^{[ OS 4 ]} على العديد من نقاط التوسعة. وقد أدت هذه الميزة إلى انتشار مواصفات "ما بعد الإصدار 2.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 ]}

من أهم مواصفات ما بعد الإصدار 2.0، ملف تعريف قابلية التشغيل البيني لبيانات تعريف SAML  V2.0، ^{[ CS 7 ]} ، الذي ينطلق من فرضية أن البنية التحتية الرسمية للمفاتيح العامة (PKI) قد تكون معقدة للغاية، وفي بعض الحالات عصية على الحل (من المعروف، على سبيل المثال، أن إلغاء شهادات TLS من جانب المتصفح معطل ^{[ Misc 1 ]} ). باختصار، يُعد ملف تعريف قابلية التشغيل البيني لبيانات التعريف محاولة لتوفير آلية فعالة لإلغاء المفاتيح في اتحادات SAML.

منذ نشرها في أغسطس 2009، أصبحت وثيقة "ملف تعريف قابلية التشغيل البيني للبيانات الوصفية" وثيقة مؤثرة للغاية، لا سيما في التعليم العالي (انظر، على سبيل المثال، متطلبات الشهادات الخاصة بالمنفذين ^{[ متفرقات 2 ]} في أحد اتحادات البحث والتعليم الكبيرة). وتلعب قابلية التشغيل البيني للبيانات الوصفية دورًا رئيسيًا في ملف تعريف التنفيذ الرسمي الذي نشرته مبادرة كانتارا.

Implementations MUST support the interpretation and application of metadata as defined by the SAML V2.0 Metadata Interoperability Profile. It follows that implementations MUST be capable of interoperating (leading to success or failure as dictated by default configuration) with any number of SAML peers for which metadata is available, without additional inputs or separate configuration.^{[Misc 3]}

Indeed, the key feature that distinguishes a scalable SAML implementation (from one that is not) is metadata interoperability.

The following code sample illustrates the common technical features of a SAML <md:EntityDescriptor> element:

<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:technical-support@example.info </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>العنصرين md:RoleDescriptor و md <md:SPSSODescriptor>:RoleDescriptor. يوضح القسمان الفرعيان أدناه كلًا من واصفات الأدوار هذه.

يدير موفر هوية SAML نقطة نهاية خدمة تسجيل الدخول الموحد ^{[ 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: عنصر التوقيع (محذوف) --> <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.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:IDPSSODescriptor> <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:technical-support@example.org </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

يصف محتوى هذا <md:IDPSSODescriptor>العنصر خدمة تسجيل الدخول الموحد لدى موفر الهوية. لاحظ التفاصيل التالية حول هذا العنصر:

• تحتوي الحاوية ^{[ CS 3 ]}<mdui:UIInfo> على مجموعة من عناصر الامتداد المؤهلة لغوياً ، والتي تُستخدم لبناء واجهات مستخدم ديناميكية لدى مزود الخدمة. وتُعد واجهة اكتشاف موفر الهوية أهم واجهة مستخدم لدى مزود الخدمة.
• من المفترض أن برنامج موفر الهوية مُهيأ بمفتاح توقيع SAML خاص. ويُدرج المفتاح العام المقابل في العنصر <md:KeyDescriptor use="signing">. في المثال أعلاه، حُذفت بيانات المفتاح من واصف المفتاح للاختصار.
• سمات Bindingالعناصر <md:SingleSignOnService>هي معرّفات الموارد الموحدة القياسية المحددة في مواصفات ربط SAML  2.0 (SAMLBind ^{[ OS 5 ]} ).

يستخدم موفر الخدمة قيم md:SingleSignOnService/@Locationالسمات الموجودة في بيانات تعريف موفر الهوية لتوجيه رسائل SAML، مما يقلل من احتمالية قيام موفر هوية مارق بتدبير هجوم الوسيط .

يدير موفر خدمة SAML نقطة نهاية خدمة مستهلك التأكيدات ^{[ 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= <!-- إدراج عنصر التوقيع 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:protocol" > < md:Extensions> <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:Logo height= "32" width= "32" xml:lang= "en" > https://service.example.com/myicon.png </mdui:Logo> </mdui:UIInfo> <idpdisc:DiscoveryResponse index= "0" Binding= "urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location= "https://service.example.com/SAML2/Login" /> </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 </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:technical-support@example.com </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

يصف محتوى هذا <md:SPSSODescriptor>العنصر خدمة مستهلك التأكيدات لدى مزود الخدمة. لاحظ التفاصيل التالية حول هذا العنصر:

• تُشير السمة 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 (SAMLBind ^{[ OS 5 ]} ).
• <md:AttributeConsumingService>يستخدم موفر الهوية هذا العنصر لصياغة <saml:AttributeStatement>عنصر يتم دفعه إلى موفر الخدمة بالتزامن مع تسجيل الدخول الموحد لمتصفح الويب SAML.
• تُستخدم سمة indexالعنصر <md:AttributeConsumingService>كقيمة للسمة AttributeConsumingServiceIndexفي <samlp:AuthnRequest>العنصر.

يستخدم موفر الهوية قيمة السمة md:AssertionConsumerService/@Locationفي بيانات تعريف موفر الخدمة لتوجيه رسائل SAML، مما يقلل من احتمالية قيام موفر خدمة مارق بتدبير هجوم الوسيط .

يطلب مستخدم المتصفح موردًا لتطبيق ويب محميًا بواسطة موفر خدمة SAML:

https://sp.example.com/myresource

إذا كان سياق أمان صالح للمستخدم الرئيسي موجودًا بالفعل لدى مزود الخدمة، فتجاوز الخطوات من 2 إلى 13.

قبل أن يتمكن مزود الخدمة من بدء تدفق بروتوكول SAML في الخطوة  6، يجب معرفة موفر الهوية المفضل لمستخدم المتصفح. توجد طرق عديدة للقيام بذلك. ولأغراض التوضيح، سيستخدم مزود الخدمة خدمة اكتشاف محلية تتوافق مع بروتوكول وملف تعريف خدمة اكتشاف موفر الهوية. ^{[ CS 4 ]}

يقوم مزود الخدمة بإعادة توجيه مستخدم المتصفح إلى خدمة الاكتشاف:

إعادة توجيه 302 الموقع: https://ds.example.com/idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal

لاحظ أن موفر الخدمة (SP) entityIDمُضمن في عنوان URL لإعادة التوجيه كما هو محدد بواسطة بروتوكول الاكتشاف.

يطلب مستخدم المتصفح خدمة الاكتشاف عن طريق إعادة التوجيه:

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

(اكتشف موفر الهوية المفضل للمستخدم)

تكتشف خدمة الاكتشاف موفر الهوية المفضل لمستخدم المتصفح بوسائل غير محددة.

تقوم خدمة الاكتشاف الآن بإعادة توجيه مستخدم المتصفح إلى نقطة نهاية استجابة الاكتشاف لدى مزود الخدمة:

إعادة توجيه 302 : https://sp.example.com/SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp

لاحظ أن موفر الهوية (IdP) entityIDمُضمن في عنوان URL لإعادة التوجيه كما هو محدد بواسطة بروتوكول الاكتشاف.

يطلب مستخدم المتصفح نقطة نهاية استجابة الاكتشاف لدى مزود الخدمة عن طريق إعادة التوجيه:

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

تتوافق نقطة نهاية استجابة الاكتشاف لدى مزود الخدمة مع بروتوكول وملف تعريف خدمة اكتشاف موفر الهوية. ^{[ CS 4 ]}

يقوم موفر الخدمة بإنشاء <samlp:AuthnRequest>عنصر ذي صلة، ويقوم بتشفير طلب SAML في سلسلة استعلام URL، ثم يعيد توجيه مستخدم المتصفح إلى خدمة تسجيل الدخول الموحد لدى موفر الهوية:

إعادة توجيه 302 : https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

للاطلاع على مخطط لكيفية إنشاء سلسلة الاستعلام، راجع تدفق بروتوكول SAML ذي الصلة في مقالة SAML 2.0. راجع SAMLCore ^{[ OS 6 ]} لمزيد من التفاصيل.

يطلب مستخدم المتصفح نقطة نهاية خدمة تسجيل الدخول الموحد لدى موفر الهوية عن طريق إعادة التوجيه:

طلب 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 = " إرسال" / > </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 للمستخدم)

في هذه المرحلة، يكون موفر الهوية على دراية بهوية المستخدم الرئيسي، وبالتالي يقوم بإنشاء تأكيد SAML نيابةً عنه. للاطلاع على مثال عملي لهذا التأكيد، يُرجى مراجعة تدفق بروتوكول SAML ذي الصلة في مقالة SAML 2.0. وكما هو معتاد، يُرجى الرجوع إلى SAMLCore ^{[ OS 6 ]} لمزيد من التفاصيل.

يُشفّر العنصر <saml:NameID>الموجود في تأكيد SAML مُعرّفًا للمستخدم الرئيسي. في هذه الحالة، يُضمّن مُزوّد ​​الهوية مُعرّف اسم مؤقت SAML2 (SAMLCore ^{[ OS 6 ]} ) في تأكيد SAML.

يتضمن موفر الهوية سمتين للمستخدم في تأكيد SAML: eduPersonUniqueIdو mail.

من الناحية التشغيلية، يقوم موفر الهوية بتوقيع وتشفير تأكيد SAML رقميًا، ثم يغلّف التأكيد في استجابة SAML، ويوقع كائن الاستجابة أيضًا. عادةً ما يوقع موفر الهوية الاستجابة فقط، ولكن في هذه الحالة يتم توقيع كل من التأكيد والاستجابة رقميًا.

يقوم موفر الهوية بإعادة مستند 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 = " إرسال" / > </form>

يتم إرسال نموذج XHTML تلقائيًا بواسطة المتصفح (بسبب جزء صغير من جافا سكريبت في الصفحة):

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

وبما أن سياق الأمان موجود، فإن مزود الخدمة يعيد المورد إلى وكيل مستخدم المتصفح كما هو مطلوب.

ملاحظة: تم إدراج مخطط بيانات Liberty الوصفية حرفيًا في وثائق المواصفات المذكورة أدناه. نظرًا  لتعطل الرابط المباشر لوثيقة XSD الإصدار 1.1 على موقع Liberty الإلكتروني، فقد تم تحميل نسخة من وثيقة XSD الخاصة ببيانات Liberty الوصفية الإصدار  1.1 على الموقع. هذه الوثيقة مُضمنة أيضًا في أرشيف Liberty ID-FF  1.2 القديم .

تم إيقاف العمل بمعايير SAML  V2.0 الأصلية التي نُشرت في مارس 2005 لصالح المواصفات المنقحة مع الأخطاء المذكورة أدناه.

• إس.  كانتور وآخرون. التأكيدات والبروتوكولات للغة ترميز تأكيدات الأمان (SAML)  الإصدار 2.0 الصادرة عن منظمة OASIS. معيار OASIS، مارس 2005. معرف المستند:  saml-core-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
• إس.  كانتور وآخرون. روابط لغة ترميز تأكيدات الأمان (SAML)  الإصدار 2.0 من منظمة OASIS. معيار OASIS، مارس 2005. معرف المستند:  saml-bindings-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
• ج.  هيوز وآخرون. ملفات تعريف لغة ترميز تأكيدات الأمان (SAML)  الإصدار 2.0 من منظمة OASIS. معيار OASIS، مارس 2005. معرف المستند:  saml-profiles-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
• إس.  كانتور وآخرون. البيانات الوصفية للغة ترميز تأكيدات الأمان (SAML)  الإصدار 2.0 من منظمة OASIS. معيار OASIS، مارس 2005. معرف المستند:  saml-metadata-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

باستثناء الإشارات التاريخية إلى  معيار بيانات التعريف الأصلي SAML V2.0، تشير الحواشي التالية إلى  مواصفات SAML V2.0 مع التصويبات . تشمل هذه المواصفات جميع التصويبات التي أقرتها اللجنة الفنية لخدمات أمن OASIS (SAML) منذ  نشر معايير SAML V2.0 في مارس 2005. يُرجى الرجوع إلى ويكي OASIS SAML للاطلاع على أحدث إصدار من أي مواصفة SAML.

هذه مجموعة فرعية صغيرة من مواصفات لجنة "ما بعد الإصدار 2.0" التي نشرتها اللجنة الفنية لخدمات أمن OASIS (SAML). يُرجى الرجوع إلى ويكي OASIS SAML للاطلاع على أحدث إصدار من أي مواصفات SAML.