SAML 2.0

📅 آخر تحديث: ٤ أغسطس ٢٠٢٦
✍️ نُشر في: ٤ أغسطس ٢٠٢٦
📷 يحتوي على 3 صور
الموسوعة الحرة

لغة تأشير تأكيدات الأمان ( SAML ) 2.0 هي إصدار من معيار SAML لتبادل هويات المصادقة والتفويض بين نطاقات الأمان . SAML 2.0 بروتوكول قائم على XML يستخدم رموز أمان تحتوي على تأكيدات لتمرير معلومات حول كيان رئيسي (عادةً مستخدم نهائي ) بين جهة SAML، تُسمى موفر الهوية ، ومستهلك SAML، يُسمى موفر الخدمة . يُمكّن SAML 2.0 تسجيل الدخول الموحد (SSO) عبر النطاقات وعبر الويب ، مما يُساعد على تقليل العبء الإداري لتوزيع رموز مصادقة متعددة على المستخدم. تم اعتماد SAML 2.0 كمعيار OASIS في مارس 2005، ليحل محل SAML 1.1 . تُغطى الجوانب الأساسية لـ SAML 2.0 بالتفصيل في الوثائق الرسمية: SAMLCore [ 1 ] ، SAMLBind [ 2 ] ، SAMLProf [ 3 ] ، وSAMLMeta [ 4 ] .    

شارك نحو 30 شخصًا من أكثر من 24 شركة ومنظمة في تطوير SAML  2.0. ومن الجدير بالذكر أن تحالف ليبرتي قدّم مواصفات إطار عمل اتحاد الهوية (ID-FF) إلى منظمة OASIS، والتي أصبحت أساسًا  لمواصفات SAML 2.0. وبذلك ،  يُمثّل SAML 2.0 تكاملًا بين SAML 1.1 ، و Liberty ID-FF  1.2 (مؤرشف بتاريخ 24 فبراير 2021 في Wayback Machine) ، و Shibboleth  1.3 .

تأكيدات SAML 2.0

التأكيد هو حزمة من المعلومات تتضمن صفرًا أو أكثر من البيانات الصادرة عن جهة معتمدة في SAML. عادةً ما تُصدر تأكيدات SAML حول موضوع، يُمثله <Subject>العنصر `<project>`. تُحدد مواصفات SAML 2.0 ثلاثة أنواع مختلفة من بيانات التأكيد التي يُمكن لجهة معتمدة في SAML إنشاؤها. جميع البيانات المُعرّفة في SAML مرتبطة بموضوع. تُعرّف أنواع بيانات التأكيد الثلاثة كما يلي:

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

يُعدّ ما يُسمى بتأكيد "الحامل" نوعًا مهمًا من تأكيدات SAML ، ويُستخدم لتسهيل تسجيل الدخول الموحد عبر متصفحات الويب. فيما يلي مثال على تأكيد حامل قصير الأجل صادر من موفر هوية ( https://idp.example.org/SAML2 ) إلى موفر خدمة ( https://sp.example.com/SAML2 ). يتضمن التأكيد كلاً من تأكيد المصادقة <saml:AuthnStatement>وتأكيد السمة <saml:AttributeStatement>، واللذان يُفترض أن موفر الخدمة يستخدمهما لاتخاذ قرار بشأن التحكم في الوصول. saml:يُمثل البادئة نطاق اسم تأكيد SAML V2.0.

مثال على SAML

<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=" <saml:NameID> <saml:SubjectConfirmation Method="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: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>العنصر بصفات "الموظف" و"العضو" في هذه المؤسسة.

بروتوكولات SAML 2.0

تم تحديد البروتوكولات التالية في SAMLCore: [ 1 ]

سيتم مناقشة أهم هذه البروتوكولات - بروتوكول طلب المصادقة - بالتفصيل أدناه.

بروتوكول طلب المصادقة

في بروتوكول 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 .

روابط SAML 2.0

تم تحديد الروابط التي يدعمها SAML  2.0 في مواصفات الروابط (SAMLBind [ 2 ] ):

في تسجيل الدخول الموحد عبر متصفح الويب، يُستخدم عادةً كلٌ من ربط إعادة التوجيه HTTP وربط طلب POST HTTP. على سبيل المثال، قد يستخدم مزود الخدمة ربط إعادة التوجيه HTTP لإرسال الطلب، بينما يستخدم موفر الهوية ربط POST HTTP لإرسال الاستجابة. يوضح هذا المثال أن اختيار الكيان لربط البيانات مستقل عن اختيار شريكه.

ربط إعادة التوجيه عبر HTTP

يمكن تضمين رسائل بروتوكول SAML مباشرةً في سلسلة استعلام عنوان URL لطلب HTTP GET. ونظرًا لأن طول عناوين URL محدود عمليًا، فإن ربط إعادة التوجيه عبر HTTP مناسب للرسائل القصيرة، مثل <samlp:AuthnRequest>رسالة . أما الرسائل الأطول (مثل تلك التي تحتوي على تأكيدات SAML موقعة أو مشفرة، مثل استجابات SAML) فتُرسل عادةً عبر روابط أخرى مثل ربط HTTP POST .

تحتوي طلبات أو استجابات SAML المُرسلة عبر إعادة توجيه HTTP على 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) وعنوان URL الخاص به ( SAML metadata ). في هذه الحالة، لا يُعد توقيع الطلب قيدًا أمنيًا. أما إذا احتوى الطلب على معلومات غير معروفة لموفر الهوية مسبقًا، مثل عنوان URL الخاص بخدمة مستهلك التأكيد (Assertion Consumer Service URL)، فيُنصح بتوقيع الطلب لأغراض أمنية.NameIDPolicy<samlp:AuthnRequest>

ربط HTTP POST

في المثال التالي، يستخدم كل من مزود الخدمة ومزود الهوية ربط HTTP POST. في البداية، يستجيب مزود الخدمة لطلب من وكيل المستخدم بمستند يحتوي على نموذج XHTML :

< form method = "post" action = "https://idp.example.org/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLRequest" value = "''request''" /> ... معلمات إدخال أخرى.... </ form >

قيمة المعامل SAMLRequestهي ترميز base64 لعنصر ما <samlp:AuthnRequest>، والذي يُرسل إلى موفر الهوية عبر المتصفح. تقوم خدمة تسجيل الدخول الموحد (SSO) لدى موفر الهوية بالتحقق من صحة الطلب، ثم تستجيب بمستند يحتوي على نموذج XHTML آخر.

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

قيمة المعلمة SAMLResponseهي ترميز base64 لعنصر ما <samlp:Response>، والذي يتم إرساله بالمثل إلى مزود الخدمة عبر المتصفح.

لأتمتة عملية إرسال النموذج، يمكن أن يظهر سطر جافا سكريبت التالي في أي مكان على صفحة XHTML:

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

يفترض هذا بالطبع أن عنصر النموذج الأول في الصفحة يحتوي على formعنصر SAMLResponse المذكور أعلاه ( forms[0]).

ربط عناصر HTTP

يستخدم ربط بيانات 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> < 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= "https://sp.example.com/SAML2/SSO/Artifact" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "false" Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" /> </samlp:AuthnRequest> </samlp:ArtifactResponse>

بالطبع، يمكن أن يسير التدفق في الاتجاه المعاكس أيضًا، أي أن مزود الهوية قد يصدر وثيقة تعريفية، وهذا في الواقع أكثر شيوعًا. انظر، على سبيل المثال، مثال ملف تعريف " الوثيقة التعريفية المزدوجة " لاحقًا في هذا الموضوع.

تنسيق القطعة الأثرية

بشكل عام، يتم تعريف عنصر SAML  2.0 على النحو التالي (SAMLBind [ 2 ] ):

SAML_artifact := B64 (TypeCode EndpointIndex RemainingArtifact) TypeCode := Byte1Byte2 EndpointIndex := Byte1Byte2

وبالتالي، تتكون بيانات SAML  2.0 من ثلاثة مكونات: بايتان TypeCode، وبايتان EndpointIndex، وتسلسل عشوائي من البايتات يُسمى RemainingArtifact. تُدمج هذه المعلومات الثلاثة وتُشفّر باستخدام Base64 للحصول على البيانات الكاملة.

يُحدد هذا TypeCodeالعنصر تنسيق العنصر بشكل فريد.  يُعرّف SAML 2.0 عنصرًا واحدًا فقط من هذا النوع، وهو  0x0004. EndpointIndexيُشير هذا العنصر إلى نقطة نهاية مُحددة لحلّ العنصر، تُديرها جهة إصدار العنصر (والتي قد تكون إما موفر الهوية أو موفر الخدمة، كما ذُكر سابقًا). أما العنصر RemainingArtifact، الذي يُحدده تعريف النوع، فهو جوهر العنصر.

يتم تعريف تنسيق القطعة الأثرية من النوع  0x0004 على النحو التالي:

TypeCode := 0x0004 RemainingArtifact := SourceId MessageHandle SourceId := 20-byte_sequence MessageHandle := 20-byte_sequence

وبالتالي، فإنّ حجم العنصر من النوع  0x0004 هو 44  بايت (غير مُشفّر). SourceIdيمثل هذا تسلسلًا عشوائيًا من البايتات، مع أنّه عمليًا، SourceIdيُمثّل تجزئة SHA-1 لمعرّف الكيان الخاص بالمُصدر. أما هذا، MessageHandleفهو تسلسل عشوائي من البايتات يُشير إلى رسالة SAML التي يرغب مُصدر العنصر في إنتاجها عند الطلب.

على سبيل المثال، ضع في اعتبارك هذا العنصر المشفر بالنظام الست عشري من النوع  0x0004:

00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f

إذا دققت النظر، ستلاحظ TypeCode(0x0004) و EndpointIndex(0x0000) في بداية العنصر. أما  البايتات العشرين التالية فهي عبارة عن تجزئة SHA-1 لمعرف الكيان الخاص بالمُصدر ( https://idp.example.org/SAML2  )، متبوعةً بعشرين بايتًا عشوائيًا. ويُظهر مثال ArtifactResolveRequest أعلاه ترميز base64 لهذه البايتات الأربع والأربعين .

ملفات تعريف SAML 2.0

في SAML  2.0، كما هو الحال في SAML 1.1، لا تزال حالة الاستخدام  الأساسية هي تسجيل الدخول الموحد عبر متصفح الويب، ولكن نطاق SAML 2.0 أوسع من الإصدارات السابقة من SAML، كما هو موضح في القائمة الشاملة التالية للملفات التعريفية: 

على الرغم من أن عدد الملفات الشخصية المدعومة كبير جدًا، إلا أن مواصفات الملفات الشخصية (SAMLProf [ 3 ] ) مبسطة نظرًا لأن جوانب الربط لكل ملف شخصي قد تم فصلها إلى مواصفات ربط منفصلة (SAMLBind [ 2 ] ).

ملف تعريف تسجيل الدخول الموحد لمتصفح الويب

يحدد معيار SAML  2.0 ملف تعريف تسجيل الدخول الموحد (SSO) لمتصفح الويب، والذي يتضمن موفر هوية (IdP) وموفر خدمة (SP) ومستخدمًا رئيسيًا يستخدم وكيل مستخدم HTTP. يمتلك موفر الخدمة أربعة خيارات ربط، بينما يمتلك موفر الهوية ثلاثة، مما ينتج عنه اثنا عشر سيناريو نشر محتملًا. نوضح فيما يلي ثلاثة من سيناريوهات النشر هذه.

طلب إعادة توجيه موفر الخدمة؛ استجابة موفر الهوية من نوع POST

هذا أحد أكثر السيناريوهات شيوعًا. يرسل موفر الخدمة طلب SAML إلى خدمة تسجيل الدخول الموحد لموفر الهوية باستخدام ربط إعادة التوجيه HTTP. ثم يُعيد موفر الهوية استجابة SAML إلى خدمة مستهلك تأكيدات موفر الخدمة باستخدام ربط POST HTTP.

تسجيل الدخول الموحد عبر متصفح الويب SAML 2.0 (ربط إعادة توجيه موفر الخدمة / استجابة POST لموفر الهوية)

تبدأ عملية نقل الرسائل بطلب للحصول على مورد آمن من مزود الخدمة.

1. اطلب المورد المستهدف من موفر الخدمة

يقوم المستخدم الرئيسي (عبر وكيل مستخدم HTTP) بطلب مورد مستهدف من مزود الخدمة:

https://sp.example.com/myresource

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

قد يستخدم مزود الخدمة أي نوع من الآليات لاكتشاف موفر الهوية الذي سيتم استخدامه، على سبيل المثال، سؤال المستخدم، أو استخدام موفر هوية مُعد مسبقًا، وما إلى ذلك.

2. إعادة التوجيه إلى خدمة تسجيل الدخول الموحد لمزود الهوية

يقوم موفر الخدمة بإنشاء طلب SAML مناسب (و RelayState، إن وجد)، ثم يعيد توجيه المتصفح إلى خدمة IdP SSO باستخدام إعادة توجيه HTTP 302 القياسية .

إعادة توجيه 302 : 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>

يمكن توقيع طلب SAML باستخدام مفتاح توقيع موفر الخدمة. ولكن عادةً، لا يكون ذلك ضرورياً.

3. اطلب خدمة تسجيل الدخول الموحد (SSO) من موفر الهوية (IdP).

يقوم وكيل المستخدم بإصدار طلب GET إلى خدمة تسجيل الدخول الموحد (SSO) لدى موفر الهوية:

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

حيث تكون قيم المعاملات SAMLRequestهي RelayStateنفسها المُقدمة في إعادة التوجيه. تقوم خدمة تسجيل الدخول الموحد (SSO) لدى موفر الهوية بمعالجة العنصر <samlp:AuthnRequest>(عن طريق فك تشفير عنوان 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:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response>

5. اطلب خدمة المستهلك المعنية بالتأكيدات لدى مزود الخدمة

يقوم وكيل المستخدم بإصدار طلب 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

حيث يتم أخذ قيم المعاملات SAMLResponseمن RelayStateنموذج XHTML في الخطوة  4.

6. إعادة التوجيه إلى المورد المستهدف

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

7. اطلب المورد المستهدف من موفر الخدمة مرة أخرى

يطلب برنامج المستخدم المورد المستهدف من مزود الخدمة (مرة أخرى):

https://sp.example.com/myresource

8. الرد بالموارد المطلوبة

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

طلب POST من مزود الخدمة؛ استجابة POST من موفر الهوية

هذا نشر بسيط نسبيًا  لملف تعريف تسجيل الدخول الموحد لمتصفح الويب SAML 2.0 (SAMLProf [ 3 ] ) حيث يستخدم كل من موفر الخدمة (SP) وموفر الهوية (IdP) ربط HTTP POST.

الدخول الموحد (SSO) لمتصفح الويب SAML 2.0 (POST)

يبدأ تدفق الرسائل بطلب للحصول على مورد مؤمن لدى موفر الخدمة.

1. اطلب المورد المستهدف من موفر الخدمة

يقوم المستخدم الرئيسي (عبر وكيل مستخدم 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

حيث تُؤخذ قيم المعاملات SAMLRequestمن نموذج XHTML في الخطوة 2. تعالج خدمة تسجيل الدخول الموحد العنصر (عن طريق فك تشفير عنوان URL، وفك تشفير base64، وتضخيم الطلب، بهذا الترتيب) وتُجري فحصًا أمنيًا. إذا لم يكن لدى المستخدم سياق أمان صالح، يُحدد موفر الهوية هوية المستخدم (التفاصيل محذوفة).RelayState <samlp:AuthnRequest>

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:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response>

5. اطلب خدمة المستهلك المعنية بالتأكيدات لدى مزود الخدمة

يقوم وكيل المستخدم بإصدار طلب 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

حيث يتم أخذ قيم المعاملات SAMLResponseمن RelayStateنموذج XHTML في الخطوة  4.

6. إعادة التوجيه إلى المورد المستهدف

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

7. اطلب المورد المستهدف من موفر الخدمة مرة أخرى

يطلب برنامج المستخدم المورد المستهدف من مزود الخدمة (مرة أخرى):

https://sp.example.com/myresource

8. الرد بالموارد المطلوبة

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

عنصر إعادة توجيه موفر الخدمة؛ عنصر إعادة توجيه موفر الهوية

هذا تطبيق معقد لملف  تعريف تسجيل الدخول الموحد لمتصفح الويب SAML 2.0 (SAMLProf [ 3 ] )، حيث يستخدم كل من موفر الخدمة (SP) وموفر الهوية (IdP) ربط HTTP Artifact. ويتم تسليم كلا العنصرين إلى نقاط النهاية الخاصة بهما عبر HTTP GET.

تسجيل الدخول الموحد عبر متصفح الويب SAML 2.0 (الملف)

يبدأ تدفق الرسائل بطلب للحصول على مورد آمن لدى موفر الخدمة:

1. اطلب المورد المستهدف من موفر الخدمة

يقوم المستخدم الرئيسي (عبر وكيل مستخدم HTTP) بطلب مورد مستهدف من مزود الخدمة:

https://sp.example.com/myresource

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

2. إعادة التوجيه إلى خدمة تسجيل الدخول الموحد (SSO) لدى موفر الهوية (IdP).

يقوم مزود الخدمة بإعادة توجيه وكيل المستخدم إلى خدمة تسجيل الدخول الموحد (SSO) لدى موفر الهوية. ويتم إلحاق RelayStateمُعاملين SAMLartبعنوان URL لإعادة التوجيه.

3. اطلب خدمة تسجيل الدخول الموحد (SSO) من موفر الهوية (IdP).

يطلب برنامج المستخدم خدمة تسجيل الدخول الموحد (SSO) من موفر الهوية:

https://idp.example.org/SAML2/SSO/Artifact ?SAMLart= artifact_1 &RelayState= الرمز المميز

حيث 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

تقوم خدمة حل البيانات في مزود الخدمة بإرجاع <samlp:ArtifactResponse>عنصر (يحتوي على <samlp:AuthnRequest>عنصر) مرتبط برسالة SAML SOAP إلى خدمة تسجيل الدخول الموحد في مزود الهوية:

<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=" < saml : Issuer > https://sp.example.com/SAML2 < / saml : Issuer > < samlp : NameIDPolicy AllowCreate = " false "​ Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" /> </samlp:AuthnRequest> </samlp:ArtifactResponse>

تقوم خدمة تسجيل الدخول الموحد بمعالجة <samlp:AuthnRequest>العنصر وإجراء فحص أمني. إذا لم يكن لدى المستخدم سياق أمان صالح، يقوم موفر الهوية بتحديد هوية المستخدم (تم حذف التفاصيل).

6. إعادة التوجيه إلى خدمة المستهلك للتأكيد

تقوم خدمة تسجيل الدخول الموحد (SSO) لدى موفر الهوية بإعادة توجيه وكيل المستخدم إلى خدمة مستهلك التأكيدات لدى موفر الخدمة. ويتم إلحاق RelayStateالمعلمة السابقة ومعلمة جديدة SAMLartبعنوان URL لإعادة التوجيه.

7. اطلب خدمة المستهلك المعنية بالتأكيدات من مزود الخدمة

يطلب وكيل المستخدم خدمة تأكيد المستهلك من مزود الخدمة:

https://sp.example.com/SAML2/SSO/Artifact ?SAMLart= artifact_2 &RelayState= الرمز المميز

أين tokenقيمة الرمز المميز من الخطوة  3، وأين artifact_2عنصر SAML الصادر في الخطوة  6؟

8. اطلب خدمة حل مشكلات البيانات من مزود الهوية

تقوم خدمة المستهلك الخاصة بالتأكيد بإلغاء مرجعية العنصر عن طريق إرسال <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

تقوم خدمة حل البيانات في موفر الهوية بإرجاع <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=" <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: Status :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><!-- عنصر الموضوع مطلوب --> < saml:Subject> < saml: NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > user@mail.example.org </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. اطلب المورد المستهدف من موفر الخدمة مرة أخرى

يطلب برنامج المستخدم المورد المستهدف من مزود الخدمة (مرة أخرى):

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 على التوالي).

ملف تعريف الارتباط الخاص بالنطاق المشترك هو ملف تعريف ارتباط آمن للمتصفح يقتصر نطاقه على النطاق المشترك. بالنسبة لكل مستخدم متصفح، يخزن ملف تعريف الارتباط هذا قائمة بسجل موفري الهوية الذين تمت زيارتهم مؤخرًا. يتم تحديد اسم وقيمة ملف تعريف الارتباط في ملف تعريف اكتشاف موفر الهوية (SAMLProf [ 3 ] ).

بعد إتمام عملية المصادقة بنجاح، يطلب موفر الهوية (IdP) من خدمة كتابة ملفات تعريف الارتباط الخاصة بالنطاق المشترك (Common Domain Cookie Writing Service ). تقوم هذه الخدمة بإلحاق المعرّف الفريد لموفر الهوية بملف تعريف الارتباط الخاص بالنطاق المشترك. وعندما يتلقى موفر الخدمة (SP) طلبًا غير مصادق عليه لمورد محمي، فإنه يطلب من خدمة قراءة ملفات تعريف الارتباط الخاصة بالنطاق المشترك (Common Domain Cookie Reading Service ) لاكتشاف موفر الهوية الذي استخدمه مستخدم المتصفح مؤخرًا.

ملف تعريف استعلام/طلب التأكيد

ملف تعريف استعلام/طلب التأكيد هو ملف تعريف عام يستوعب أنواعًا عديدة مما يسمى بالاستعلامات  باستخدام عناصر SAML 2.0 التالية :

  • العنصر <samlp:AssertionIDRequest>، الذي يُستخدم لطلب تأكيد بناءً على مُعرّفه الفريد ( ID).
  • العنصر <samlp:SubjectQuery>، وهو نقطة امتداد مجردة تسمح بتعريف استعلامات SAML جديدة قائمة على الموضوع
  • العنصر <samlp:AuthnQuery>، الذي يُستخدم لطلب تأكيدات المصادقة الموجودة حول موضوع معين من جهة مصادقة
  • العنصر <samlp:AttributeQuery>، الذي يُستخدم لطلب سمات حول موضوع معين من جهة مرجعية للسمات
  • العنصر <samlp:AuthzDecisionQuery>المستخدم لطلب قرار تفويض من طرف ثالث موثوق به

غالبًا ما يتم استخدام ربط SAML SOAP بالتزامن مع الاستعلامات.

استعلام سمة SAML

يُعدّ استعلام السمات ربما أهم أنواع استعلامات 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" > CN=trscavo@example.com,OU=User,O=NCSA-TEST,C=US </saml:Issuer> <saml:Subject> <saml:NameID <saml:Attribute NameFormat= "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" > CN=trscavo@example.com,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 > </saml:Attribute> </samlp:AttributeQuery>

لاحظ أن `the` Issuerهو `the` Subjectفي هذه الحالة. يُطلق على هذا أحيانًا اسم استعلام ذاتي عن السمة . قد يُعيد مُزوّد ​​الهوية التأكيد التالي، مُغلّفًا في <samlp:Response>عنصر `<a>` (غير معروض):

<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" > CN=trscavo@example.com,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" > trscavo@example.org </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

على عكس تأكيد حامل الشهادة الموضح سابقًا، يتمتع هذا التأكيد بفترة صلاحية أطول تتوافق مع فترة صلاحية شهادة X.509 التي استخدمها المستخدم للتحقق من هويته لدى موفر الهوية. علاوة على ذلك، ولأن التأكيد مُوقّع، يمكن للمستخدم إرساله إلى جهة معتمدة، وطالما استطاع المستخدم إثبات حيازته للمفتاح الخاص المقابل (ومن هنا جاءت تسمية "حامل المفتاح")، يمكن للجهة المعتمدة التأكد من صحة التأكيد.

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

بكل بساطة، البيانات الوصفية هي ما يجعل بروتوكول SAML يعمل (أو يعمل بكفاءة). ومن أهم استخدامات البيانات الوصفية ما يلي:

  • يستعد مزود الخدمة لإرسال <samlp:AuthnRequest>عنصر إلى موفر الهوية عبر المتصفح. كيف يتأكد مزود الخدمة من أن موفر الهوية موثوق وليس موفر هوية خبيثًا يحاول سرقة كلمة مرور المستخدم؟ يستشير مزود الخدمة قائمة موفري الهوية الموثوق بهم في البيانات الوصفية قبل إرسال طلب المصادقة.
  • في السيناريو السابق، كيف يعرف مزود الخدمة إلى أين يرسل المستخدم مع طلب المصادقة؟ يبحث مزود الخدمة عن موقع نقطة نهاية مُعد مسبقًا لمزود الهوية الموثوق به في البيانات الوصفية .
  • يستقبل موفر الهوية <samlp:AuthnRequest>عنصرًا من موفر الخدمة عبر المتصفح. كيف يتأكد موفر الهوية من أن موفر الخدمة موثوق وليس موفر خدمة خبيثًا يسعى لجمع معلومات تعريفية شخصية عن المستخدم؟ يستشير موفر الهوية قائمة موفري الخدمات الموثوق بهم في البيانات الوصفية قبل إصدار استجابة المصادقة.
  • في السيناريو السابق، كيف يقوم موفر الهوية بتشفير تأكيد SAML بحيث يتمكن موفر الخدمة الموثوق به (وحده) من فك تشفير التأكيد؟ يستخدم موفر الهوية شهادة التشفير الخاصة بموفر الخدمة الموجودة في البيانات الوصفية لتشفير التأكيد.
  • استكمالاً للسيناريو السابق، كيف يعرف موفر الهوية إلى أين يرسل المستخدم مع استجابة المصادقة؟ يبحث موفر الهوية عن موقع نقطة نهاية مُعدة مسبقاً لموفر الخدمة الموثوق به في البيانات الوصفية .
  • كيف يتأكد مزود الخدمة من أن استجابة المصادقة واردة من مزود هوية موثوق؟ يتحقق مزود الخدمة من التوقيع على التأكيد باستخدام المفتاح العام لمزود الهوية من البيانات الوصفية .
  • كيف يعرف مزود الخدمة مكان حل البيانات المستلمة من مزود هوية موثوق؟ يقوم مزود الخدمة بالبحث عن موقع نقطة النهاية المتفق عليها مسبقًا لخدمة حل البيانات الخاصة بمزود الهوية من البيانات الوصفية .

تضمن البيانات الوصفية إجراء معاملات آمنة بين موفر الهوية وموفر الخدمة. قبل ظهور البيانات الوصفية، كانت معلومات الثقة تُشفّر في التطبيق بطريقة خاصة. أما الآن، فقد سهّلت البيانات الوصفية القياسية مشاركة معلومات الثقة.  يوفر 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= <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:saml-support@example.org </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 المحدد في 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> member </saml:AttributeValue> <saml:AttributeValue> student </saml:AttributeValue> <saml:AttributeValue> faculty </saml:AttributeValue> <saml:AttributeValue> employee </saml:AttributeValue> <saml:AttributeValue> staff </saml:AttributeValue> </saml:Attribute> </md:IDPSSODescriptor>

يصف عنصر البيانات الوصفية السابق خدمة تسجيل الدخول الموحد (SSO) لدى موفر الهوية. لاحظ التفاصيل التالية حول هذا العنصر:

  • تم تكوين برنامج موفر الهوية باستخدام مفتاح توقيع SAML خاص و/أو مفتاح TLS خاص للقناة الخلفية. ويُدرج المفتاح العام المقابل في عنصر <md:KeyDescriptor use="signing">بيانات تعريف موفر الهوية. وللاختصار، تم حذف بيانات المفتاح من وصف المفتاح.
  • تشير سمة Bindingالعنصر إلى أنه يجب استخدام <md:ArtifactResolutionService>ربط SAML SOAP (SAMLBind [ 2 ] ) لحل القطع الأثرية.
  • يتم استخدام سمة العنصر في الخطوة 8 Locationمن ملف تعريف " القطعة الأثرية المزدوجة ".<md:ArtifactResolutionService> 
  • تُستخدم قيمة سمة indexالعنصر في إنشاء عنصر SAML من النوع 0x0004.<md:ArtifactResolutionService>EndpointIndex 
  • تشير العناصر <md:NameIDFormat>إلى تنسيقات معرف اسم SAML (SAMLCore [ 1 ] ) التي تدعمها خدمة SSO.
  • سمات Bindingالعناصر <md:SingleSignOnService>هي معرّفات الموارد الموحدة القياسية المحددة في مواصفات ربط SAML  2.0 (SAMLBind [ 2 ] ).
  • يتم استخدام سمة Locationالعنصر <md:SingleSignOnService>الذي يدعم ربط HTTP POST في الخطوة  2 من ملف تعريف " POST المزدوج ".
  • يتم استخدام سمة Locationالعنصر <md:SingleSignOnService>الذي يدعم ربط HTTP Artifact في الخطوة  2 من ملف تعريف " العنصر المزدوج ".
  • يصف هذا <saml:Attribute>العنصر سمةً يرغب موفر الهوية في تأكيدها (رهناً بالسياسة المتبعة). <saml:AttributeValue>وتُعدد العناصر القيم المحتملة التي قد تأخذها هذه السمة.

كما ذكرنا في بداية هذا القسم، يتم استخدام قيم السمات Locationمن قبل مزود الخدمة لتوجيه رسائل SAML، مما يقلل من احتمالية قيام مزود هوية مارق بتدبير هجوم الوسيط .

بيانات تعريف مزود الخدمة

على غرار موفر الهوية، ينشر موفر الخدمة بيانات عن نفسه في <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:saml-support@example.com </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 المحدد في 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= "en" > بوابة موفر الخدمة </md:ServiceName> <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 خاص. ويتضمن عنصر <md:KeyDescriptor use="encryption">بيانات تعريف مزود الخدمة مفتاح تشفير SAML عام. وقد تم حذف بيانات المفتاح من وصف المفتاح للاختصار.
  • تُستخدم سمة indexالعنصر <md:AssertionConsumerService>كقيمة للسمة AssertionConsumerServiceIndexفي <samlp:AuthnRequest>العنصر.
  • سمات Bindingالعناصر <md:AssertionConsumerService>هي معرّفات الموارد الموحدة القياسية المحددة في مواصفات ربط SAML  2.0 (SAMLBind [ 2 ] ).
  • يتم استخدام سمة العنصر الذي يدعم ربط HTTP POST ( ) في الخطوة 4 Locationمن <md:AssertionConsumerService>ملف تعريف " POST المزدوج ".index="0" 
  • يتم استخدام سمة العنصر الذي يدعم ربط HTTP Artifact ( ) في الخطوة 6 Locationمن <md:AssertionConsumerService>ملف تعريف " العنصر المزدوج ".index="1" 
  • <md:AttributeConsumingService>يستخدم موفر الهوية هذا العنصر لصياغة <saml:AttributeStatement>عنصر يتم دفعه إلى موفر الخدمة بالتزامن مع تسجيل الدخول الموحد لمتصفح الويب.
  • تُستخدم سمة indexالعنصر <md:AttributeConsumingService>كقيمة للسمة AttributeConsumingServiceIndexفي <samlp:AuthnRequest>العنصر.

كما ذكرنا في بداية هذا القسم، يتم استخدام قيم السمات Locationبواسطة موفر الهوية لتوجيه رسائل SAML، مما يقلل من احتمالية قيام موفر خدمة مارق بتدبير هجوم الوسيط .

تجميعات البيانات الوصفية

في الأمثلة السابقة، <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 إلى العنصر الأصل لتجنب تعريفات مساحة الاسم الزائدة.

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

انظر أيضاً

مراجع

المراجع الأساسية:

  1. ١ ٢ ٣ إس. كانتور وآخرون. التأكيدات والبروتوكولات للغة ترميز تأكيدات الأمان (SAML)  الإصدار ٢.٠ من منظمة OASIS - مجموعة التصويبات. مسودة عمل ٠٧، ٨ سبتمبر ٢٠١٥. معرف المستند sstc-saml-core-errata-2.0-wd-07 http://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf
  2. ١ ٢ ٣ ٤ ٥ ٦ ٧ إس. كانتور وآخرون. روابط لغة ترميز تأكيدات الأمان (SAML) الإصدار ٢.٠ من منظمة OASIS  - مجموعة تصحيحات. مسودة عمل ٠٦، ٨ سبتمبر ٢٠١٥. معرف المستند sstc-saml-bindings-errata-2.0-wd-06 https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata-2.0-wd-06.pdf
  3. ١ ٢ ٣ ٤ ٥ ٦ ٧ ج. هيوز وآخرون. ملفات تعريف لغة ترميز تأكيدات الأمان (SAML) الإصدار ٢.٠ من منظمة OASIS  - مجموعة تصحيحات. مسودة عمل ٠٧، ٨ سبتمبر ٢٠١٥. معرف المستند sstc-saml-profiles-errata-2.0-wd-07 https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf
  4. ١ ٢ ٣ ٤ ٥ إس. كانتور وآخرون. بيانات وصفية للغة ترميز تأكيدات الأمان (SAML)  الإصدار ٢.٠ من منظمة OASIS - مجموعة تصحيحات. مسودة عمل رقم ٥، ٨ سبتمبر ٢٠١٥. معرف المستند: sstc-saml-metadata-errata-2.0-wd-05 https://www.oasis-open.org/committees/download.php/56785/sstc-saml-metadata-errata-2.0-wd-05.pdf

المراجع الثانوية:

المراجع المهملة: