SAML

لغة ترميز تأكيدات الأمان ( SAML ، تُنطق سام -إل ، / ˈsæməl / ) ^{[ 1} ] هي معيار مفتوح لتبادل ^بيانات المصادقة والتفويض بين الأطراف، وتحديدًا بين موفر الهوية وموفر الخدمة . SAML هي لغة ترميز قائمة على XML لتأكيدات الأمان ( البيانات التي يستخدمها موفرو الخدمات لاتخاذ قرارات التحكم في الوصول). SAML هي أيضًا :

• مجموعة من رسائل البروتوكول المستندة إلى XML
• مجموعة من روابط رسائل البروتوكول
• مجموعة من الملفات الشخصية (باستخدام كل ما سبق)

من أهم استخدامات SAML تسجيل الدخول الموحد عبر متصفحات الويب . يُعدّ تسجيل الدخول الموحد سهلًا نسبيًا ضمن نطاق أمان واحد (باستخدام ملفات تعريف الارتباط ، على سبيل المثال)، لكن توسيع نطاقه ليشمل نطاقات أمان أخرى أكثر صعوبة، مما أدى إلى انتشار تقنيات احتكارية غير متوافقة. تم تحديد وتوحيد ملف تعريف SAML لتسجيل الدخول الموحد عبر متصفحات الويب لتعزيز التوافقية. ^{[ 2 ]} عمليًا، يُستخدم SAML لتسجيل الدخول الموحد بشكل شائع للمصادقة على برامج الأعمال السحابية. ^{[ 3 ]}

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

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

قبل إرسال تأكيد الهوية من موفر الهوية إلى موفر الخدمة، قد يطلب موفر الهوية بعض المعلومات من المستخدم (مثل اسم المستخدم وكلمة المرور) للتحقق من هويته. يحدد بروتوكول SAML محتوى التأكيد المُمرر من موفر الهوية إلى موفر الخدمة. في SAML، يمكن لموفر هوية واحد تقديم تأكيدات SAML إلى العديد من موفري الخدمة. وبالمثل، يمكن لموفر خدمة واحد الاعتماد على تأكيدات من العديد من موفري الهوية المستقلين والوثوق بها. ^{[ 5 ]}

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

تم تأسيس اللجنة الفنية لخدمات الأمن التابعة لمنظمة تطوير معايير المعلومات المهيكلة (OASIS) ، والتي اجتمعت لأول مرة في يناير 2001، بهدف "تحديد إطار عمل XML لتبادل معلومات المصادقة والتفويض". ^{[ 7 ]} تحقيقاً لهذه الغاية، تم تقديم الملكية الفكرية التالية إلى اللجنة الفنية لخدمات الأمن خلال الشهرين الأولين من ذلك العام:

• لغة ترميز خدمات الأمان (S2ML) من Netegrity
• ملف AuthXML من Securant
• مواصفات خدمة تأكيد الثقة XML (X-TASS) من VeriSign
• لغة ترميز تكنولوجيا المعلومات (ITML) من Jamcracker

وبناءً على هذه المساهمات الأولية، أعلنت منظمة OASIS في نوفمبر 2002 عن مواصفات لغة ترميز تأكيدات الأمان (SAML)  1.0 كمعيار من معايير OASIS. ^{[ 8 ]}

في غضون ذلك، اقترح تحالف ليبرتي ، وهو اتحاد كبير يضم شركات ومنظمات غير ربحية وهيئات حكومية، إضافةً إلى معيار SAML تُسمى إطار عمل اتحاد هوية ليبرتي (ID-FF). ^{[ 9 ]} وكما هو الحال مع سابقه SAML، اقترح ليبرتي ID-FF إطار عمل موحدًا، متعدد النطاقات، قائم على الويب، لتسجيل دخول موحد. إضافةً إلى ذلك، وصف ليبرتي دائرة ثقة حيث يُعتمد على كل نطاق مشارك لتوثيقه بدقة العمليات المستخدمة لتحديد هوية المستخدم، ونوع نظام المصادقة المستخدم، وأي سياسات مرتبطة ببيانات اعتماد المصادقة الناتجة. ويمكن لأعضاء دائرة الثقة الآخرين فحص هذه السياسات لتحديد مدى موثوقية هذه المعلومات. ^{[ 10 ]}

بينما كانت شركة ليبرتي تُطوّر بروتوكول ID-FF، بدأت لجنة SSTC العمل على ترقية طفيفة لمعيار SAML.  وقد صادقت اللجنة على مواصفات SAML 1.1 الناتجة في سبتمبر 2003. ثم، في نوفمبر من العام نفسه، ساهمت ليبرتي ببروتوكول ID-FF  1.2 في منظمة OASIS ، مما مهّد الطريق للإصدار الرئيسي التالي من SAML. في مارس 2005،  أُعلن عن SAML 2.0 كمعيار من OASIS.  يُمثّل SAML 2.0 تقاربًا بين بروتوكول  ID-FF الخاص بليبرتي والامتدادات الخاصة التي ساهم بها مشروع Shibboleth ، بالإضافة إلى الإصدارات المبكرة من SAML نفسه. تدعم معظم تطبيقات SAML الإصدار 2.0، بينما لا يزال العديد منها يدعم الإصدار 1.1 للتوافق مع الإصدارات السابقة. بحلول يناير 2008، أصبح استخدام SAML  2.0 شائعًا في المؤسسات الحكومية والتعليم العالي والتجارية حول العالم. ^{[ 10 ]}

خضع بروتوكول SAML لمراجعة طفيفة ومراجعة رئيسية منذ الإصدار 1.0.

• تم اعتماد SAML  1.0 كمعيار من معايير OASIS في نوفمبر 2002
• تم اعتماد SAML 1.1 كمعيار من معايير OASIS في سبتمبر 2003
• أصبح SAML 2.0 معيارًا لمنظمة OASIS في مارس 2005

ساهم تحالف الحرية بإطار عمل اتحاد الهوية (ID-FF) الخاص به في لجنة العلوم والتكنولوجيا التابعة لمنظمة OASIS في سبتمبر 2003:

•  تم إصدار ID-FF 1.1 في أبريل 2003
• تم الانتهاء من إصدار ID-FF  1.2 في نوفمبر 2003

تتشابه النسختان 1.0 و1.1 من بروتوكول SAML رغم وجود اختلافات طفيفة بينهما، ^{[ 11 ]} إلا أن الاختلافات بين SAML  2.0 وSAML  1.1 جوهرية. فعلى الرغم من أن المعيارين يعالجان نفس حالة الاستخدام، إلا أن SAML  2.0 غير متوافق مع سابقه.

على الرغم من أن معيار ID-FF  1.2 قد تم تقديمه إلى منظمة OASIS كأساس لمعيار SAML  2.0، إلا أن هناك بعض الاختلافات المهمة بين SAML  2.0 و ID-FF  1.2. وعلى وجه الخصوص، فإن المواصفتين، على الرغم من أصولهما المشتركة، غير متوافقتين. ^{[ 10 ]}

تعتمد SAML على عدد من المعايير الحالية:

• لغة الترميز القابلة للتوسيع (XML): يتم التعبير عن معظم عمليات تبادل SAML بلهجة موحدة من XML، وهي أصل اسم SAML (لغة ترميز تأكيدات الأمان).
• مخطط XML (XSD): يتم تحديد تأكيدات وبروتوكولات SAML (جزئيًا) باستخدام مخطط XML.
• التوقيع الرقمي XML : يستخدم كل من SAML 1.1 و SAML 2.0 التوقيعات الرقمية (المستندة إلى معيار التوقيع الرقمي XML) للمصادقة وسلامة الرسائل.
• تشفير XML : باستخدام تشفير XML، يوفر SAML 2.0 عناصر لمعرفات الأسماء المشفرة، والسمات المشفرة، والتأكيدات المشفرة (  لا يمتلك SAML 1.1 إمكانيات التشفير). وقد وردت تقارير تفيد بوجود مخاوف أمنية خطيرة تتعلق بتشفير XML. ^{[ 12 ] [ 13 ]}
• بروتوكول نقل النص التشعبي (HTTP): يعتمد SAML بشكل كبير على HTTP كبروتوكول اتصالاته.
• بروتوكول الوصول إلى الكائنات البسيط (SOAP) : يحدد SAML استخدام SOAP، وتحديدًا SOAP 1.1. ^{[ 14 ]}

يُعرّف SAML التأكيدات والبروتوكولات والروابط والملفات التعريفية المستندة إلى XML. ويشير مصطلح SAML Core إلى الصيغة العامة ودلالات تأكيدات SAML، بالإضافة إلى البروتوكول المستخدم لطلب هذه التأكيدات ونقلها من كيان نظام إلى آخر. ويشير بروتوكول SAML إلى ما يتم نقله، وليس كيفية نقله (إذ تُحدد الأخيرة باختيار الرابط). لذا، يُعرّف SAML Core تأكيدات SAML "الأساسية" إلى جانب عناصر طلب واستجابة SAML.

يحدد ربط SAML كيفية ربط طلبات واستجابات SAML ببروتوكولات المراسلة أو الاتصالات القياسية. ومن أهم أنواع الربط (المتزامن) ربط SAML SOAP.

ملف تعريف SAML هو تجسيد ملموس لحالة استخدام محددة باستخدام مجموعة معينة من التأكيدات والبروتوكولات والروابط.

<saml:Assertion ...> .. </saml:Assertion>

البروتوكولات

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

يُعدّ الاستعلام أهم أنواع طلبات بروتوكول SAML . يقوم مزود الخدمة بإرسال استعلام مباشرةً إلى مزود الهوية عبر قناة اتصال خلفية آمنة. ولذلك، ترتبط رسائل الاستعلام عادةً ببروتوكول SOAP.

وبناءً على الأنواع الثلاثة من العبارات، توجد ثلاثة أنواع من استعلامات SAML:

1. استعلام المصادقة
2. استعلام عن السمات
3. استعلام قرار التفويض

ينتج عن استعلام السمة استجابة SAML تحتوي على تأكيد، والذي بدوره يحتوي على بيان السمة. راجع موضوع SAML 2.0 للاطلاع على مثال لاستعلام/استجابة السمة .

باستثناء الاستعلامات، لا يحدد SAML 1.1 أي بروتوكولات أخرى.

يُوسّع SAML  2.0 مفهوم البروتوكول بشكلٍ كبير. تُشرح البروتوكولات التالية بالتفصيل في SAML  2.0 Core:

• بروتوكول الاستعلام والطلب الخاص بالتأكيد
• بروتوكول طلب المصادقة
• بروتوكول حل المشكلات
• بروتوكول إدارة مُعرّف الاسم
• بروتوكول تسجيل الخروج الفردي
• بروتوكول تعيين مُعرّف الاسم

معظم هذه البروتوكولات جديدة في SAML 2.0 .

روابط

ربط SAML هو عبارة عن ربط رسالة بروتوكول SAML بتنسيقات المراسلة القياسية و/أو بروتوكولات الاتصال. على سبيل المثال، يحدد ربط SAML SOAP كيفية تغليف رسالة SAML في غلاف SOAP، والذي يرتبط بدوره برسالة HTTP.

يُحدد معيار SAML  1.1 ربطًا واحدًا فقط، وهو ربط SAML SOAP. بالإضافة إلى SOAP، يتضمن معيار SAML  1.1 لتسجيل الدخول الموحد عبر متصفح الويب ضمنيًا روابط HTTP POST وHTTP Redirect وHTTP Artifact. مع ذلك، لم يتم تعريف هذه الروابط بشكل صريح، وإنما تُستخدم فقط بالتزامن مع  معيار SAML 1.1 لتسجيل الدخول الموحد عبر متصفح الويب. لم يكتمل مفهوم الربط بشكل كامل إلا في معيار SAML  2.0.

يفصل SAML  2.0 مفهوم الربط تمامًا عن الملف التعريفي الأساسي. في الواقع، يتضمن SAML  2.0 مواصفات ربط جديدة كليًا تُعرّف الروابط المستقلة التالية:

• ربط SAML SOAP (مبني على SOAP  1.1)
• ربط الصابون العكسي (PAOS)
• ربط إعادة توجيه HTTP (GET)
• ربط HTTP POST
• ربط عناصر HTTP
• ربط SAML URI

توفر عملية إعادة التنظيم هذه مرونة هائلة: على سبيل المثال، يمكن لمقدم الخدمة الاختيار من بين أربعة روابط (إعادة توجيه HTTP، و HTTP POST ونوعين من HTTP Artifact)، بينما يمتلك موفر الهوية ثلاثة خيارات للربط (HTTP POST بالإضافة إلى شكلين من HTTP Artifact)، ليصبح المجموع اثني عشر نشرًا ممكنًا لملف تعريف SAML  2.0 Web Browser SSO.

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

1. اطلب المورد المستهدف من موفر الخدمة (SAML  2.0 فقط)

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

https://sp.example.com/myresource

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

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

يقوم مزود الخدمة بتحديد موفر الهوية المفضل للمستخدم (بوسائل غير محددة) ويعيد توجيه وكيل المستخدم إلى خدمة تسجيل الدخول الموحد (SSO) لدى موفر الهوية:

https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request

قيمة المعلمة SAMLRequest(المشار إليها بالعنصر النائب requestأعلاه) هي ترميز Base64 لعنصر مضغوط<samlp:AuthnRequest> .

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

يُرسل برنامج المستخدم طلب GET إلى خدمة تسجيل الدخول الموحد (SSO) على عنوان URL المُحدد في الخطوة  2. تقوم خدمة تسجيل الدخول الموحد بمعالجة الطلب AuthnRequest(المُرسل عبر SAMLRequestمُعامل الاستعلام في عنوان URL) وتُجري فحصًا أمنيًا. إذا لم يكن لدى المستخدم سياق أمان صالح، يقوم مُزود الهوية بتحديد هوية المستخدم (التفاصيل محذوفة).

4. الرد باستخدام نموذج XHTML

تقوم خدمة تسجيل الدخول الموحد (SSO) بالتحقق من صحة الطلب وتستجيب بمستند يحتوي على نموذج XHTML:

< form method = "post" action = "https://sp.example.com/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLResponse" value = "response" /> ... < input type = "submit" value = " إرسال" / > </form>

قيمة العنصر SAMLResponse(المشار إليها بالعنصر النائب responseأعلاه) هي ترميز base64 للعنصر <samlp:Response>.

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

SAMLResponseيُرسل برنامج المستخدم طلب POST إلى خدمة مُستهلك التأكيدات لدى مُزوّد ​​الخدمة. تُؤخذ قيمة المُعامل من نموذج XHTML في الخطوة 4.

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

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

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

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

https://sp.example.com/myresource

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

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

في SAML 1.1، يبدأ التدفق بطلب إلى خدمة نقل المواقع بين المواقع الخاصة بمزود الهوية في الخطوة 3.

في مثال التدفق الموضح أعلاه، جميع عمليات التبادل الموضحة هي عمليات تبادل مباشرة ، أي أن وكيل مستخدم HTTP (المتصفح) يتواصل مع كيان SAML في كل خطوة. وبالتحديد، لا توجد عمليات تبادل غير مباشرة أو اتصالات مباشرة بين مزود الخدمة ومزود الهوية. تؤدي عمليات التبادل المباشرة إلى تدفقات بروتوكول بسيطة حيث يتم تمرير جميع الرسائل بالقيمة باستخدام ربط HTTP بسيط (GET أو POST). في الواقع، يُطلق على التدفق الموضح في القسم السابق أحيانًا اسم ملف تعريف تسجيل الدخول الموحد (SSO) لمتصفح الويب الخفيف .

بدلاً من ذلك، ولزيادة الأمان أو الخصوصية، يمكن تمرير الرسائل بالمرجع . على سبيل المثال، قد يُقدّم مُزوّد ​​الهوية مرجعًا لتأكيد SAML (يُسمى عنصرًا ) بدلاً من إرسال التأكيد مباشرةً عبر وكيل المستخدم. بعد ذلك، يطلب مُزوّد ​​الخدمة التأكيد الفعلي عبر قناة خلفية. يُحدد هذا التبادل عبر القناة الخلفية كتبادل رسائل SOAP (SAML عبر SOAP عبر HTTP). عمومًا، يُجرى أي تبادل SAML عبر قناة خلفية آمنة كتبادل رسائل SOAP.

في قناة الاتصال الخلفية، يحدد بروتوكول SAML استخدام بروتوكول SOAP  1.1. مع ذلك، فإن استخدام SOAP كآلية ربط اختياري. سيختار أي تطبيق SAML محدد أي روابط مناسبة.

• SAML 2.0
• بيانات تعريف SAML
• المنتجات والخدمات القائمة على بروتوكول SAML
• إدارة الهوية
• أنظمة إدارة الهوية
• الهوية الموحدة
• بطاقة معلومات
• اتحاد WS
• OAuth
• OpenID Connect

• اللجنة الفنية لخدمات الأمن في منظمة أواسيس
• صفحات الغلاف: لغة ترميز تأكيدات الأمان (SAML)
• كيفية دراسة وتعلم SAML
• تبسيط مفهوم SAML
• أول موفر هوية SAML 2.0 عام
• دانيال بلوم (2003). الهوية الموحدة تكتسب زخماً . شركة IDG Network World Inc.، ص  42.