SAML 1.1

لغة ترميز تأكيدات الأمان (SAML) هي معيار XML لتبادل بيانات المصادقة والتفويض بين نطاقات الأمان. SAML هي نتاج اللجنة الفنية لخدمات الأمان التابعة لمنظمة OASIS .

تم اعتماد معيار SAML  1.1 كمعيار من قِبل منظمة OASIS في سبتمبر 2003. وتُغطى الجوانب الأساسية لـ SAML 1.1 بالتفصيل في الوثيقتين الرسميتين SAMLCore ^{[ 1 ]} وSAMLBind ^{[ 2 ]} . إذا كنت جديدًا على SAML، فمن الأفضل أن تقرأ موضوع SAML التمهيدي أولًا، ثم وثيقة SAMLOverview ^{[ 3 ]} الصادرة عن OASIS.

قبل إصدار SAML  1.1، تم اعتماد SAML  1.0 كمعيار من قِبل منظمة OASIS في نوفمبر 2002. وقد خضع SAML لمراجعة ثانوية (الإصدار 1.1) ومراجعة رئيسية (الإصدار 2.0) منذ الإصدار 1.0، الذي يُعدّ بروتوكولًا بسيطًا نسبيًا.  إلا أن أهمية SAML 1.0 تتجاوز الجانب التاريخي، حيث اعتمدته مبادرة المصادقة الإلكترونية  الفيدرالية الأمريكية كتقنية أساسية لها.

 تتشابه النسختان 1.0 و1.1 من بروتوكول SAML. راجع SAMLDiff ^{[ 4 ]} للاطلاع على الفروقات المحددة بين المعيارين. تركز هذه المقالة على SAML  1.1 نظرًا لأهميته كمعيار أساسي تعتمد عليه العديد من المعايير والتطبيقات الأخرى.

تنبيه: يجب على المطورين والمنفذين الانتباه جيدًا إلى أن جميع أمثلة التعليمات البرمجية الواردة في هذه المقالة غير ملزمة، وهي لأغراض التوضيح فقط. يُرجى الرجوع إلى مواصفات OASIS SAML للاطلاع على المتطلبات الإلزامية.

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

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

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

<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" Issuer= "https://idp.example.org/saml" ... > <saml:Conditions NotBefore= "..." NotAfter= "..." /> <saml:AuthenticationStatement AuthenticationMethod= "..." AuthenticationInstant= "..." > <saml:Subject> ... </saml:Subject> </saml:AuthenticationStatement> <saml:AttributeStatement> <saml:Subject> ... </saml:Subject> <saml:Attribute AttributeName= "urn:mace:dir:attribute-def:eduPersonAffiliation" AttributeNamespace= "urn:mace:shibboleth:1.0:attributeNamespace:uri" < saml:AttributeValue> member </saml:AttributeValue> <saml:AttributeValue> student </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

غالباً ما يتم الحصول على السمات من دليل LDAP ، لذا فإن التمثيل المتسق للسمات عبر مجالات الأمان أمر بالغ الأهمية.

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

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

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

بروتوكول SAML هو بروتوكول بسيط يعتمد على طلب واستجابة. يقوم مُرسِل طلب SAML بإرسال Requestعنصر SAML إلى المُستقبِل:

<samlp:Request xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" RequestID= "aaf23196-1773-2113-474a-fe114412ab72" IssueInstant= "2006-07-17T22:26:40Z" > <!-- أدخل عناصر SAML الأخرى هنا --> </samlp:Request>

وبالمثل، يقوم مستجيب SAML بإرجاع عنصر SAML Responseإلى المُرسِل:

<samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "b07b804c-7c29-ea16-7300-4f3d6f7928ac" InResponseTo= "aaf23196-1773-2113-474a-fe114412ab72" IssueInstant= "2006-07-17T22:26:41Z" > <!-- أدخل عناصر SAML الأخرى هنا، بما في ذلك التأكيدات --> </samlp:Response>

يتم تفصيل الروابط والملفات التعريفية اللازمة للتأثير على تبادل الرسائل هذا في الأقسام التالية.

يُعرّف معيار SAML 1.1 رسميًا ربط  بروتوكول واحد فقط ، وهو ربط SAML SOAP. يجب أن يُطبّق أي تطبيق متوافق مع SAML 1.1 بروتوكول SAML عبر SOAP عبر HTTP (ربط بروتوكول متزامن). يُسمح باستخدام آليات نقل أخرى غير HTTP، شريطة مراعاة الجوانب المستقلة عن البروتوكول لربط SAML SOAP (انظر القسم 3.1.2 من SAMLBind ^{[ 2 ]} ).  

يعتمد ربط SAML  1.1 SOAP على الإصدار  1.1 من SOAP (الترقيم محض صدفة). يقوم طالب SAML بتغليف Requestعنصر SAML ضمن نص رسالة SOAP. وبالمثل، يُعيد مُستجيب SAML Responseعنصر SAML ضمن نص رسالة SOAP المُعادة. في حال حدوث خطأ، يُعيد المُستجيب رمز خطأ SOAP.

يجب تضمين أي ترميز SAML في نص SOAP.  لا يُحدد SAML 1.1 أي رؤوس SOAP خاصة بـ SAML. يحق للمُرسِل إدراج أي رؤوس SOAP يرغب بها (مع العلم أنه لا يُشترط إدراج أي منها).

تذكر أنه في بروتوكول SOAP  1.1، SOAPActionيجب تضمين ترويسة HTTP مع كل طلب HTTP (مع أن قيمتها قد تكون فارغة). يمكن لمرسل طلب SAML أن يُدخل القيمة التالية في SOAPActionالترويسة:

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

ومع ذلك، لا ينبغي أن يعتمد مستجيب SAML على هذه القيمة.

لا يلزم وجود اتصال آمن لطلبات واستجابات SAML، ولكن في تلك الحالات التي تتطلب سلامة الرسائل وسريتها ، يلزم استخدام HTTP عبر SSL  3.0 أو TLS 1.0 مع شهادة من جانب الخادم. 

قد يُعيد مُستجيب SAML استجابة "403 ممنوع" عند رفضه الاستجابة لطلب SAML. يجب على المُستجيب إعادة استجابة "500 خطأ داخلي في الخادم" في حالة حدوث خطأ في SOAP (مع تضمين عنصر خطأ SOAP). وإلا، فسيتم إعادة استجابة "200 موافق"، حتى في حالة وجود خطأ في معالجة SAML. ستتضمن هذه الاستجابة Statusعنصر SAML في نص SOAP.

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

1. ملف تعريف المتصفح/POST
2. ملف تعريف المتصفح/العنصر

يعتمد ملف تعريف المتصفح/POST على عملية "دفع" تُمرر تأكيد تسجيل الدخول الموحد (SSO) كقيمة عبر المتصفح باستخدام بروتوكول HTTP POST. نقول إن موفر الهوية "يدفع" التأكيد إلى موفر الخدمة.

يستخدم ملف تعريف المتصفح/العنصر آلية "السحب". يقوم ملف التعريف أساسًا بتمرير تأكيد تسجيل الدخول الموحد من موفر الهوية إلى موفر الخدمة عن طريق المرجع (عبر المتصفح باستخدام إعادة توجيه HTTP)، والذي يتم إلغاء مرجعيته لاحقًا عبر تبادل قناة خلفية (أي أن موفر الخدمة "يسحب" التأكيد من موفر الهوية باستخدام SAML عبر SOAP عبر HTTP).

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

 يبدأ كلا ملفي تعريف SAML 1.1 من خدمة نقل البيانات بين المواقع ، والتي يديرها موفر الهوية. لا يحدد معيار SAML 1.1 كيفية وصول المستخدم إلى خدمة نقل البيانات في المقام الأول. راجع القسمين  4.1 و4.2 من SAMLOverview ^{[ 3 ]}  للاطلاع على السيناريوهات المحتملة. عمليًا، يُعاد توجيه العميل الذي يحاول الوصول إلى مورد مؤمّن لدى موفر الخدمة إلى خدمة نقل البيانات بين المواقع لدى موفر الهوية، ولكن SAML 1.1 لا يحدد التسلسل الدقيق للخطوات اللازمة لإتمام ذلك . (راجع القسم  4.3 من SAMLOverview ^{[ 3 ]} للاطلاع على بعض الأفكار العامة في هذا السياق). يتناول معيار SAML  2.0 هذا السيناريو بالتفصيل.

بعد زيارة خدمة نقل البيانات بين المواقع، يتم تحويل المستخدم إلى خدمة تأكيد المستهلك لدى مزود الخدمة. وتختلف آلية هذا التحويل باختلاف الملف التعريفي المستخدم. ففي حالة ملف تعريف المتصفح/البيانات، يتم استخدام إعادة توجيه؛ أما في حالة ملف تعريف المتصفح/طلب POST، فيُرسل العميل طلب POST (سواءً بتدخل المستخدم أو بدونه).

لتسريع عملية المعالجة بواسطة خدمة مستهلك التأكيدات، تم تحديد عنواني URL منفصلين:

1. عنوان URL لمستهلك التأكيد (ملف تعريف المتصفح/POST)
2. عنوان URL الخاص بمستلم البيانات (ملف تعريف المتصفح/البيانات)

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

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

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

طلب GET إلى /TransferService?TARGET=target HTTP / 1.1 Host : idp.example.org

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

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

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

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

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

طلب GET إلى /TransferService?TARGET=target HTTP / 1.1 Host : idp.example.org

HTTP / 1.1 302 تم العثور على الموقع : https://sp.example.com/ACS/Artifact?TARGET=target&SAMLart=artifact

https://sp.example.com/ACS/Artifact ?TARGET= target &SAMLart= artifact

طلب GET إلى /ACS/Artifact?TARGET=target&SAMLart=artifact HTTP / 1.1 Host : sp.example.com

POST /ArtifactResolutionService HTTP/1.1 المضيف: idp.example.org نوع المحتوى: نص/xml طول المحتوى: nnn SOAPAction: http://www.oasis-open.org/committees/security <SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header/> <SOAP-ENV:Body> <samlp:Request xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" RequestID= "_192.168.16.51.1024506224022" IssueInstant= "2002-06-19T17:03:44.022Z" > <samlp:AssertionArtifact> artifact </samlp:AssertionArtifact> </samlp:Request> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

HTTP/1.1 200 OK نوع المحتوى: نص/xml Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header/> <SOAP-ENV:Body> <samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "_P1YaA+Q/wSM/t/8E3R8rNhcpPTM=" InResponseTo= "_192.168.16.51.1024506224022" IssueInstant= "2002-06-19T17:05:37.795Z" > <samlp:Status> <samlp:StatusCode Value= "samlp:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" AssertionID= "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer= "https://idp.example.org/saml" IssueInstant= "2002-06-19T17:05:37.795Z" > <saml:Conditions NotBefore= "2002-06-19T17:00:37.795Z" NotOnOrAfter= "2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement AuthenticationMethod= "urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant= "2002-06-19T17:05:17.706Z" > <saml:Subject> <saml:NameIdentifier Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > user@idp.example.org </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:artifact </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

• SAML
• SAML 2.0
• المنتجات والخدمات القائمة على بروتوكول SAML