> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.
# SAML للمبتدئين: متى ما زالت المؤسسات تحتاجه؟
- URL: https://arabroot.io/articles/شرح-saml-للمبتدئين/
- Published: 2026-10-25T19:11:24.000Z
- Updated: 2026-10-26T05:53:49.000Z
- Description: نشرح SAML بتجربة حقيقية نرى فيها الـ Assertion كما يحمله المتصفح، ثم نعدله ونسرقه ونؤخره لنرى كيف يرفضه التطبيق.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, الأمن السيبراني, الاستضافة الذاتية, SimpleSAMLphp
تشترك مؤسستك في خدمة سحابية جديدة، وفي صفحة إعداد الدخول الموحد تجد خياراً واحداً هو SAML، ويطلب منك المورد «ملف Metadata الخاص بمزود الهوية»، ويعطيك هو «Entity ID» و«ACS URL». وكما ذكرنا في [شرح الدخول الموحد SSO ومصطلحاته](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%88-%D8%A7%D9%84%D8%AF%D8%AE%D9%88%D9%84-%D8%A7%D9%84%D9%85%D9%88%D8%AD%D8%AF-sso-%D9%88%D8%A7%D9%84%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA/) فإن الدخول الموحد عبر الويب له لغتان اليوم: OpenID Connect الأحدث، وSAML الأقدم الذي ما زال يحكم جزءاً كبيراً من تطبيقات المؤسسات. وفي هذا المقال سوف نفهم SAML من الداخل، بتجربة حقيقية نرى فيها الرسالة التي يحملها المتصفح كما هي، ثم نعبث بها ونرى كيف يرفضها التطبيق.
وسوف نناقش في هذا المقال ما يلي:
- لماذا ما زالت المؤسسات تحتاج SAML في 2026، ومتى تختاره ومتى تختار OpenID Connect.
- المصطلحات التي تظهر في كل شاشة إعداد: Entity ID وMetadata وACS والـ Bindings وNameID.
- خطوات الدخول بالترتيب، من الطلب AuthnRequest إلى الرد SAMLResponse.
- تجربة عملية بمزود هوية صغير وتطبيق تجريبي على SimpleSAMLphp في Docker، مع الـ Assertion الحقيقي وتشريحه.
- أربعة أعطال نجربها عن قصد: رسالة معدلة، ورسالة مسروقة، ورسالة منتهية، ورسالة مكررة.
- ثغرات SAML المعروفة، وقائمة تحقق قبل أن تربط تطبيقاً حقيقياً.
## لماذا ما زالت المؤسسات تحتاج SAML؟
صدر SAML 2.0 من منظمة OASIS في مارس 2005، أي قبل OpenID Connect بتسع سنوات، وخلال هذه السنوات بنت عليه الشركات الكبيرة والجامعات والجهات الحكومية أنظمة الدخول الموحد كلها. لذلك ما زلت تجده في الأماكن التالية:
- **الخدمات السحابية للمؤسسات SaaS:** أغلبها يدعم SAML لأنه ما يطلبه قسم تقنية المعلومات في الشركات الكبيرة، وبعضها لا يدعم غيره. وفي [توثيق Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/add-application-portal-setup-sso?ref=arabroot.io) مثلاً يأتي SAML كأول طريقة لربط تطبيق خارجي بالدخول الموحد.
- **التطبيقات الداخلية القديمة:** أنظمة الموارد البشرية والمحاسبة والبوابات التي بنيت قبل 2015 تتكلم SAML فقط، واستبدالها مكلف.
- **الاتحادات Federations بين المؤسسات:** شبكات الجامعات البحثية مثلاً تتبادل ملفات Metadata لمئات المؤسسات، ويدخل الباحث بحساب جامعته إلى خدمات جامعة أخرى.
وقد يتساءل البعض: إذا كان OpenID Connect أحدث وأبسط، فلماذا لا نتخلى عن SAML؟ والإجابة أن القرار ليس بيدك غالباً، فالتطبيق هو الذي يحدد ما يدعمه. والقاعدة العملية بسيطة: إذا دعم التطبيق الاثنين فاختر OpenID Connect، والسبب أن مكتباته أبسط وأقل عرضة لأخطاء التحقق من XML كما سيأتي، وإذا لم يدعم إلا SAML فاستخدمه، فكل مزودي الهوية مفتوحي المصدر المعروفين مثل [authentik](https://docs.goauthentik.io/add-secure-apps/providers/saml/?ref=arabroot.io) و[Keycloak](https://www.keycloak.org/docs/latest/server%5Fadmin/index.html?ref=arabroot.io#con-saml-clients%5Fserver%5Fadministration%5Fguide) يعملون كمزود هوية SAML.
| | SAML 2.0 | OpenID Connect |
| -------------------------- | ---------------------------------------- | -------------------------------------------------- |
| صيغة الرسالة | XML موقع بمعيار XML Signature | JSON داخل JWT موقع |
| طريقة الوصول | المتصفح يحمل الرسالة كاملة في نموذج POST | المتصفح يحمل كوداً قصيراً، والتوكنات تطلب من الخلف |
| تطبيقات الجوال وواجهات API | غير مناسب | مصمم لها |
| حجم الرسالة في تجربتنا | 10877 بايت base64 | توكن JWT ببضع مئات من البايتات |
| أين تجده | تطبيقات المؤسسات والاتحادات الجامعية | التطبيقات الحديثة وأغلب الأدوات مفتوحة المصدر |
## المصطلحات التي سوف تجدها في كل شاشة إعداد
معيار SAML نفسه عدة وثائق، أهمها [SAML Core](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf?ref=arabroot.io) الذي يعرف الرسائل، و[SAML Bindings](https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf?ref=arabroot.io) الذي يعرف طريقة نقلها، و[SAML Profiles](https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf?ref=arabroot.io) الذي يعرف كيف تستخدم في الدخول عبر المتصفح. ومن هذه الوثائق تأتي المصطلحات التالية:
- **المعرف Entity ID:** اسم فريد لكل طرف، يكتب غالباً على شكل رابط مثل `https://wiki.example.com`، ولكنه مجرد اسم ولا يشترط أن يفتح في المتصفح. والتطبيق يعرف نفسه به في الطلب، والمزود يضعه في الرد كجمهور Audience.
- **ملف التعريف Metadata:** ملف XML يصف الطرف: معرفه، وعناوينه، وشهادة التوقيع Signing Certificate. وتبادل الملفين هو كل ما تحتاجه الثقة بين الطرفين.
- **عنوان استقبال الرد ACS:** اختصار Assertion Consumer Service، وهو العنوان في التطبيق الذي يستقبل الرد من المتصفح، والمزود يرسل إليه فقط العنوان المسجل عنده.
- **عنوان الدخول SSO Service:** العنوان في المزود الذي يستقبل طلب الدخول.
- **طرق النقل Bindings:** كيف تحمل الرسالة: `HTTP-Redirect` يضعها مضغوطة داخل الرابط، وهو مناسب للطلب الصغير، و`HTTP-POST` يضعها في نموذج HTML يرسل نفسه، وهو المستخدم للرد الكبير، و`HTTP-Artifact` يرسل مرجعاً قصيراً ويجلب الطرف الآخر الرسالة من الخلف، وهو نادر.
- **الطلب AuthnRequest والرد Response:** رسالة التطبيق التي يطلب بها الدخول، ورسالة المزود التي تحمل الـ Assertion.
- **الـ Assertion:** الجزء الموقع الذي يقول من المستخدم ومتى تحقق منه وما صفاته، وهو قلب SAML كله.
- **المعرف NameID وصيغته Format:** هوية المستخدم داخل الـ Assertion، وقد تكون البريد `emailAddress`، أو معرفاً ثابتاً لا يتغير `persistent`، أو معرفاً عشوائياً لكل دخول `transient`.
- **الصفات Attributes:** بقية المعلومات مثل الاسم والبريد والمجموعات، ويتفق الطرفان على أسمائها.
- **RelayState:** قيمة يرسلها التطبيق مع الطلب ويعيدها المزود كما هي، ويستخدمها التطبيق ليعيد المستخدم إلى الصفحة التي طلبها أولاً.
## خطوات الدخول بالترتيب
في الطريقة المعتادة يبدأ التطبيق الدخول SP-initiated، والصورة التالية تبين الخطوات كما حدثت في تجربتنا، ولاحظ أن التطبيق والمزود لا يتصلان ببعضهما مباشرة أبداً في هذا التدفق، فالمتصفح هو الذي يحمل الرسالتين:
الطلب صغير فيمر داخل الرابط، والرد كبير فيمر في نموذج POST
## تجربة عملية: مزود هوية وتطبيق على SimpleSAMLphp
سوف نستخدم [SimpleSAMLphp 2.5.3.1](https://github.com/simplesamlphp/simplesamlphp/releases/tag/v2.5.3.1?ref=arabroot.io) لأنه يعمل كمزود هوية وكتطبيق في نفس الوقت، وهو مشروع قديم ونشط بترخيص LGPL-2.1، وصدر منه في أغسطس 2026 الإصداران 2.5.3.1 و2.4.10\. وسوف نشغل منه نسختين في حاويتين منفصلتين: مزود هوية على المنفذ `18803` باسم `https://idp.example.com`، وتطبيقاً تجريبياً على المنفذ `18804` باسم `https://wiki.example.com`، وكل منهما احتاج في تجربتنا إلى قرابة 55 ميجابايت من الذاكرة. ولاحظ أن هذا الإعداد للتعلم فقط، فالتجربة تعمل عبر HTTP، وفي الإنتاج يجب أن يعمل الطرفان عبر HTTPS.
### الخطوة 1: الـ Image والمفاتيح
نحمل النسخة الكاملة من صفحة الإصدار، والتي تأتي ومعها مكتبات PHP، ونفكها في مجلد `dl`، ثم نبني Image فوق Image PHP الرسمية مع Apache بهذا الملف `Dockerfile`:
```dockerfile
FROM php:8.4.27-apache-trixie
COPY dl/simplesamlphp-2.5.3.1 /var/simplesamlphp
RUN printf '%s\n' 'SetEnv SIMPLESAMLPHP_CONFIG_DIR /var/simplesamlphp/config' 'Alias /simplesaml /var/simplesamlphp/public' '' ' Require all granted' '' > /etc/apache2/conf-enabled/simplesamlphp.conf \
&& mkdir -p /var/cache/simplesamlphp && chown -R www-data /var/simplesamlphp /var/cache/simplesamlphp
```
ثم نولد زوجاً من المفاتيح لكل طرف، فمفتاح المزود يوقع به الردود، ومفتاح التطبيق يوقع به طلباته إذا أردنا ذلك:
```bash
curl -sLO https://github.com/simplesamlphp/simplesamlphp/releases/download/v2.5.3.1/simplesamlphp-2.5.3.1-full.tar.gz
mkdir -p dl idp/{config,metadata,cert} sp/{config,metadata,cert,app}
tar xzf simplesamlphp-2.5.3.1-full.tar.gz -C dl
openssl req -x509 -newkey rsa:3072 -nodes -days 365 -subj "/CN=idp.example.com" -keyout idp/cert/server.pem -out idp/cert/server.crt
openssl req -x509 -newkey rsa:3072 -nodes -days 365 -subj "/CN=sp.example.com" -keyout sp/cert/server.pem -out sp/cert/server.crt
cp idp/cert/server.crt sp/cert/idp.crt
docker build -t saml-lab:2.5.3.1 .
```
لاحظ السطر الأخير قبل البناء: التطبيق يحصل على شهادة المزود العامة فقط `idp.crt`، ولا يرى مفتاحه الخاص أبداً، وهذه الشهادة هي ما سيتحقق به من كل رد.
### الخطوة 2: إعداد الطرفين
نسخنا ملف الإعداد الافتراضي `config.php.dist` من المشروع إلى `base.php` في مجلد الإعداد لكل طرف، ثم كتبنا `config.php` صغيراً يغير ما نحتاجه فقط. وهذا ملف المزود، والفرق في ملف التطبيق هو المنفذ `18804` وأسماء ملفات تعريف الارتباط بالبادئة `SP` بدلاً من `IDP`، والقيمة `false` في السطرين الأخيرين:
```php
['core:AdminPassword'],
'example-userpass' => [
'exampleauth:UserPass',
'users' => [
'sara:Sara-Lab-2026' => [
'uid' => ['sara'],
'mail' => ['sara@example.com'],
'displayName' => ['Sara Ali'],
'groups' => ['finance', 'wiki-editors'],
],
],
],
];
```
ثم نعرف المزود نفسه في `idp/metadata/saml20-idp-hosted.php`: معرفه ومفتاحه، ومن أين يتحقق من المستخدمين، وأن NameID هو البريد:
```php
'__DEFAULT__',
'privatekey' => 'server.pem',
'certificate' => 'server.crt',
'auth' => 'example-userpass',
'authproc' => [
10 => [
'class' => 'saml:AttributeNameID',
'identifyingAttribute' => 'mail',
'Format' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress',
],
],
];
```
ونسجل التطبيق عند المزود في `idp/metadata/saml20-sp-remote.php`، وهذا ما تفعله في أي مزود هوية عندما تضيف تطبيق SAML:
```php
[[
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
'Location' => 'http://localhost:18804/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp',
]],
'SingleLogoutService' => [[
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
'Location' => 'http://localhost:18804/simplesaml/module.php/saml/sp/saml2-logout.php/default-sp',
]],
'NameIDFormat' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress',
];
```
ومن جهة التطبيق نعرفه في `sp/config/authsources.php` مع معرف المزود الذي يثق به:
```php
['core:AdminPassword'],
'default-sp' => [
'saml:SP',
'entityID' => 'https://wiki.example.com',
'idp' => 'https://idp.example.com',
'privatekey' => 'server.pem',
'certificate' => 'server.crt',
'NameIDPolicy' => ['Format' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress', 'AllowCreate' => true],
],
];
```
ونسجل المزود عند التطبيق في `sp/metadata/saml20-idp-remote.php`، ولاحظ الشهادة `idp.crt`:
```php
[[
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
'Location' => 'http://localhost:18803/simplesaml/module.php/saml/idp/singleSignOnService',
]],
'SingleLogoutService' => [[
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
'Location' => 'http://localhost:18803/simplesaml/module.php/saml/idp/singleLogout',
]],
'certificate' => 'idp.crt',
];
```
وأخيراً صفحة التطبيق نفسها `sp/app/index.php`، وهي تطلب مستخدماً مسجلاً وتطبع ما وصلها عنه:
```php
requireAuth();
header('Content-Type: text/plain; charset=utf-8');
echo "Hello " . $as->getAttributes()['displayName'][0] . "\n";
echo "NameID: " . $as->getAuthData('saml:sp:NameID')->getValue() . "\n";
foreach ($as->getAttributes() as $k => $v) echo " $k = " . implode(', ', $v) . "\n";
```
في الإعداد أعلاه لاحظ التالي:
- عنوان ACS في `saml20-sp-remote.php` هو العنوان الوحيد الذي سيقبل المزود أن يرسل إليه الرد، فإذا جاءه طلب يطلب عنواناً آخر رفضه.
- التطبيق لا يحتاج إلى أي شيء عن المستخدمين، فكل ما يعرفه هو معرف المزود وعنوانه وشهادته.
- في الإنتاج لا تكتب هذه الملفات بيدك عادة، وإنما تعطي كل طرف رابط Metadata الطرف الآخر، والمزود في تجربتنا ينشر ملفه على `/simplesaml/module.php/saml/idp/metadata`.
### الخطوة 3: التشغيل
```bash
docker network create saml-lab
docker run -d --name saml-idp --network saml-lab -p 18803:80 \
-v "$PWD/idp/config:/var/simplesamlphp/config" -v "$PWD/idp/metadata:/var/simplesamlphp/metadata" -v "$PWD/idp/cert:/var/simplesamlphp/cert" \
saml-lab:2.5.3.1
docker run -d --name saml-sp --network saml-lab -p 18804:80 \
-v "$PWD/sp/config:/var/simplesamlphp/config" -v "$PWD/sp/metadata:/var/simplesamlphp/metadata" -v "$PWD/sp/cert:/var/simplesamlphp/cert" \
-v "$PWD/sp/app/index.php:/var/www/html/index.php" \
saml-lab:2.5.3.1
```
إذا فتحت `http://localhost:18804/` في المتصفح فسوف يحولك التطبيق إلى صفحة دخول المزود:
صفحة الدخول في المزود على المنفذ 18803، وكلمة المرور تكتب هنا وليس في التطبيق
⚠️
إذا ظهرت صفحة خطأ وفي السجل `Unable to create the "cache" directory (/var/cache/simplesamlphp/saml)` فالسبب أن المجلد غير موجود أو لا يملكه مستخدم Apache، وهو سبب السطر `mkdir -p /var/cache/simplesamlphp` في الـ Dockerfile. وإذا ظهر `Endpoint of type AssertionConsumerService is not an array` فالإصدار 2 يطلب أن يكون ACS مصفوفة فيها `Binding` و`Location` وليس نصاً.
### الخطوة 4: نمشي الدخول بأنفسنا مع curl
حتى نرى الرسائل نفسها نستخدم `curl` مكان المتصفح، مع ملف يحفظ ملفات تعريف الارتباط بين الطلبات. ونحتاج أولاً إلى سكربت صغير يفك رسائل SAML، وهو `decode.py`:
```python
# decode.py: print a SAML message readable. Redirect binding = deflate+base64+urlencode; POST binding = base64 only.
import sys, base64, zlib, urllib.parse, xml.dom.minidom
v = urllib.parse.unquote(sys.argv[1]) if '%' in sys.argv[1] else sys.argv[1]
raw = base64.b64decode(v)
try: raw = zlib.decompress(raw, -15)
except zlib.error: pass
print(xml.dom.minidom.parseString(raw).toprettyxml(indent=' ').split('\n', 1)[1].strip())
```
ثم نكتب الخطوات في `flow.sh`: نفتح التطبيق، ونتبع التحويل إلى المزود، ونرسل كلمة المرور، ونحفظ الرد:
```bash
#!/usr/bin/env bash
# One SP-initiated SAML login with curl as the browser. Prints each hop, saves request.xml and response.xml.
SP=http://localhost:18804; J=${JAR:-jar.txt}; rm -f $J
echo "== 1. open the wiki"
curl -s -c $J -b $J -D r1.txt -o /dev/null $SP/; grep -iE '^(HTTP|location)' r1.txt | cut -c1-120
LOC=$(grep -i '^location' r1.txt | cut -d' ' -f2 | tr -d '\r')
python -I decode.py "$(echo "$LOC" | sed 's/.*SAMLRequest=\([^&]*\).*/\1/')" > request.xml
echo "== 2. the IdP asks for a password"
curl -s -c $J -b $J -L -D r2.txt -o login.html "$LOC"; grep -iE '^(HTTP|location)' r2.txt | cut -c1-120
ACT=$(grep -o 'id="f" class="[^"]*" action="[^"]*"' login.html | sed 's/.*action="//;s/"$//;s/&/\&/g')
echo "== 3. sara logs in, the IdP answers with an auto-post form"
curl -s -c $J -b $J -L -o resp.html -w 'HTTP %{http_code}\n' --data-urlencode username=sara --data-urlencode password=Sara-Lab-2026 "$ACT"
grep -o ']*>' resp.html
grep -o 'name="SAMLResponse" value="[^"]*"' resp.html | sed 's/.*value="//;s/"$//' > samlresponse.b64
grep -o 'name="RelayState" value="[^"]*"' resp.html | sed 's/.*value="//;s/"$//' > relaystate.txt
echo "SAMLResponse: $(wc -c < samlresponse.b64) bytes of base64"
python -I decode.py "$(cat samlresponse.b64)" > response.xml
```
والخطوة الأخيرة هي ما يفعله نموذج HTML في المتصفح تلقائياً، أي إرسال الرد إلى ACS، ونضعها في `post.sh` لأننا سوف نستخدمها في تجارب الأعطال أيضاً:
```bash
#!/usr/bin/env bash
# post.sh : what the browser's auto-post form does
J=${JAR:-jar.txt}
curl -s -c $J -b $J -D p.txt -o p.html --data-urlencode "SAMLResponse=$(cat $1)" --data-urlencode "RelayState=$(cat relaystate.txt | sed 's/&/\&/g')" http://localhost:18804/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp
grep -iE '^(HTTP|location)' p.txt | cut -c1-120
```
ونشغل الخطوات ثم نفتح الصفحة:
```bash
bash flow.sh
bash post.sh samlresponse.b64
curl -s -c jar.txt -b jar.txt http://localhost:18804/
```
والمخرج سوف يكون كما يلي:
```text
== 1. open the wiki
HTTP/1.1 303 See Other
Location: http://localhost:18803/simplesaml/module.php/saml/idp/singleSignOnService?SAMLRequest=fVLJbgIxDP2VUe6zspSJAImC
== 2. the IdP asks for a password
HTTP/1.1 303 See Other
Location: http://localhost:18803/simplesaml/module.php/core/loginuserpass?AuthState=_7ceaa9974269d290f845308d180188f70bd
HTTP/1.1 200 OK
== 3. sara logs in, the IdP answers with an auto-post form
HTTP 200