Keycloak v26.7.4 — لماذا تُغيّر 6 ثغرات في أسبوع واحد المشهد
صدرت ملاحظات الإصدار 26.7.4 في 16 سبتمبر 2026، بعد أسبوع واحد من الإصدار 26.7.3 الذي كان قد أغلق بدوره عدة ثغرات. هذا الإيقاع يكشف عن دين تقني هيكلي في سطح تعرّض Keycloak: يدعم المشروع عشرات البروتوكولات (OIDC، SAML، LDAP، Kerberos)، وواجهة إدارة كاملة، ومحرّك سمات من جانب الخادم. كل طبقة تحمل سطح شبكة خاصاً بها.
أشد الثغرتين خطورةً (CVE-2026-79651، CVSS 7.5، وCVE-2026-18212، CVSS 7.5) رمزيتان للمشكلة: تتيحان لمهاجم غير مصادَق استنزاف ذاكرة عملية Keycloak بضرب نقاط نهاية متاحة للعموم — صفحة تسجيل الدخول ونقاط نهاية SAML — دون الحاجة إلى أي حساب. على خادم VPS بذاكرة 2 إلى 4 غيغابايت مشتركة بين عدة خدمات، يمكن لمثل هذا الناقل إسقاط المجموعة الكاملة.
مؤشر آخر: الإصدار 26.7.1 الذي صدر قبل أسابيع قليلة كان قد أدخل بدوره ثغرات أمنية تُصلحها 26.7.4 جزئياً (CVE-2026-74909 موثّقة صراحةً بوصفها «إصلاحاً غير مكتمل» للإصدار 26.7.1). دورتا تصحيح في أقل من شهر على إصدارات ثانوية متتالية تدل على أن الكود السطحي تحت ضغط.
ما الذي كان بإمكان كل ثغرة السماح به — ملخص غير تقني
- CVE-2026-79651 (CVSS 7.5 — عالية): يقبل Keycloak وسوم locale عشوائية على نقاط نهاية السمات دون حدٍّ أو تحقق. يُرسل المهاجم locale فريدة في حلقة من الشبكة العامة؛ كل طلب يُخصّص ذاكرة لا تُحرَّر أبداً. النتيجة: تعطل العملية بسبب نفاد الذاكرة، دون الحاجة إلى أي بيانات اعتماد.
- CVE-2026-18212 (CVSS 7.5 — عالية): تُسرّب مساعدات SAML Redirect DEFLATE حالة مكتبة zlib الأصلية. يكفي طلب SAML مشوّه لتشغيل تلف في الذاكرة قد يؤدي إلى تعطل الخادم أو تسريب بيانات الجلسة.
- CVE-2026-74909 (CVSS 8.1 — عالية): يتجاوز الفاصلة المنقوطة المُرمَّزة بالنسبة المئوية (
%3B) تنظيف معاملات matrix في PathMatcher. يستطيع المهاجم الوصول إلى مورد محمي بسياسة أكثر صرامة باستخدام النموذج الأقل تقييداً للمسار نفسه. - CVE-2026-90997 (CVSS 7.4 — عالية): على عمليات النشر التي تستخدم MySQL أو MariaDB، يجعل عدد الصفوف الافتراضي الذي يُعيده محرك التخزين بوابات مكافحة إعادة التشغيل غير فعّالة. يمكن إعادة استخدام بيانات اعتماد مصادقة مستعملة سابقاً.
- CVE-2026-17526 (CVSS 7.2 — عالية): يستطيع دور
impersonationانتحال هوية مسؤول realm. يمكن لمشغّل بصلاحيات محدودة رفع صلاحياته إلى الإدارة الكاملة لـrealm. - CVE-2026-19607 (CVSS 5.3 — متوسطة): يؤدي تصادم اسم مستخدم في تدفق فيدرالية الهوية (broker) إلى إقفال حساب المستخدم الشرعي. يُطرد المستخدم الشرعي من حسابه دون أي تصرف منه.
Keycloak مقابل Authelia مقابل ZITADEL — الاختيار حسب سياق VPS الخاص بك
مرّر الجدول أفقيًا
| المعيار | Keycloak 26.7.4 | Authelia 4.x | ZITADEL 2.x |
|---|---|---|---|
| ذاكرة الوصول العشوائي في وضع الخمول | 512 ميغابايت – 1 غيغابايت (JVM) | أقل من 30 ميغابايت (Go) | 150 – 300 ميغابايت (Go + CockroachDB أو PostgreSQL) |
| اللغة / بيئة التشغيل | Java (JVM) | Go — ملف تنفيذي واحد | Go — ملف تنفيذي واحد |
| الترخيص | Apache 2.0 | Apache 2.0 | Apache 2.0 (الجوهر) |
| البروتوكولات | OIDC، SAML، LDAP، Kerberos، WebAuthn | OIDC، مصادقة ثنائية (TOTP، WebAuthn) | OIDC، OAuth2، SAML، LDAP، WebAuthn |
| واجهة الإدارة | كاملة — realms، clients، تدفقات | YAML فقط | لوحة تحكم ويب + API gRPC/REST |
| الأنسب لـ | أكثر من 20 تطبيق، فيدرالية LDAP، SAML للمؤسسات | أقل من 10 تطبيقات، مصادقة proxy، فريق تقني | أقل من 20 تطبيق، فريق تطوير، API-first |
| قابلية الصيانة على VPS | ثقيلة: JVM، تكوين XML، ترحيلات | خفيفة: ملف YAML واحد، ملف تنفيذي واحد | متوسطة: قاعدة بيانات مطلوبة، لكن API واضحة |
| سطح الثغرات (تاريخياً) | مرتفع: 6 ثغرات في v26.7.4 وحده | منخفض: أقل من 5 ثغرات منذ 2022 | منخفض إلى متوسط: مشروع أحدث |
Authelia — SSO خفيف لأقل من 10 تطبيقات
Authelia خادم مصادقة وتفويض مكتوب بلغة Go. يعرض نقطة نهاية لتحقق HTTP يستطيع reverse proxy الخاص بك (nginx، Traefik، Caddy) الاستعلام عنها لحماية التطبيقات دون الحاجة إلى تطبيق OIDC نفسه. يدعم أيضاً تدفق OIDC الكامل للتطبيقات التي تطلبه.
بصمة الذاكرة هي ميزته التشغيلية الرئيسية: في وضع الخمول، يستهلك Authelia بين 20 و30 ميغابايت من ذاكرة الوصول العشوائي وفقاً للقياسات المنشورة في مشكلات GitHub للمشروع (نقاشات #5939 و#6048). على خادم VPS بـ2 غيغابايت مشتركة بين Nextcloud وخادم بريد وreverse proxy، هذا لا يُذكر مقارنةً بالحد الأدنى لـJVM الخاص بـKeycloak البالغ 512 ميغابايت.
التكوين تصريحي بالكامل (YAML). لا توجد واجهة رسومية للإدارة — ميزة أمنياً (لا نقطة نهاية للإدارة قابلة للكشف) وعيب للفرق غير التقنية. لمطوّر منفرد أو فريق صغير يدير تطبيقاته الخاصة على VPS، كثيراً ما يكون Authelia هو الخيار الصحيح.
الهجرة من Keycloak إلى Authelia — تصدير OIDC، التكوين، الاختبارات
تصدير تكوين OIDC من Keycloak
في لوحة تحكم Keycloak، انتقل إلى Realm Settings → Export. ضع علامة على «Export clients» و«Export groups». نزّل ملف JSON الناتج — يحتوي على عملاء OIDC الخاصين بك مع عناوين URL للإعادة ونطاقاتهم. يُستخدم هذا الملف مرجعاً لإعادة تكوين كل تطبيق في Authelia؛ لا يُستورد مباشرةً.
تثبيت Authelia باستخدام Docker Compose
أنشئ ملف
docker-compose.ymlبسيطاً:services:authelia:image: authelia/authelia:latestvolumes:- ./config:/configports:- 9091:9091restart: unless-stoppedأنشئ مجلد
config/وضع فيهconfiguration.yml. يوفر الوثائق الرسمية هيكلاً كاملاً علىhttps://www.authelia.com/configuration/prologue/introduction/.تكوين عملاء OIDC في Authelia
لكل تطبيق منقول من Keycloak، أضف مدخلاً تحت
identity_providers.oidc.clientsفيconfiguration.yml:identity_providers:oidc:clients:- id: my-appsecret: '$pbkdf2-sha512$...'redirect_uris:- https://my-app.example.com/oauth/callbackscopes: [openid, email, profile]ولّد السر باستخدام
authelia crypto hash generate pbkdf2 --variant sha512. استخدم ملف JSON المُصدَّر من Keycloak للعثور على عناوين URI لإعادة التوجيه لكل عميل.تكوين reverse proxy للاستعلام من Authelia
يعمل Authelia كوسيط تحقق. في nginx، أضف كتلة
auth_request:location /authelia {internal;proxy_pass http://authelia:9091/api/authz/forward-auth;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}location / {auth_request /authelia;proxy_pass http://my-app:3000;}للتطبيقات التي تستخدم OIDC أصلياً، وجّه المُصدر إلى
https://auth.your-domain.com.اختبار كل تطبيق قبل قطع الاتصال بـKeycloak
لكل تطبيق منقول، تحقق من ثلاثة تدفقات: تسجيل الدخول الأول (التحويل إلى Authelia → المصادقة → العودة إلى التطبيق)، وتسجيل الخروج (إلغاء صلاحية ملف تعريف الارتباط وجلسة التطبيق)، والعامل الثاني إن كان مُفعَّلاً. لا تقطع الاتصال بـKeycloak إلا بعد التحقق من صحة جميع التدفقات لجميع التطبيقات. أبقِ حاوية Keycloak موقوفة لا محذوفة لمدة 30 يوماً.
ZITADEL — IdP أول بالـAPI لفرق التطوير
ZITADEL هو مزوّد هوية مكتوب بلغة Go، مُرخَّص بموجب Apache 2.0، تُصدره الشركة السويسرية ZITADEL Cloud. مستودعه الرسمي هو github.com/zitadel/zitadel. بينما صُمِّم Authelia كوسيط proxy، ZITADEL هو IdP كامل المزايا بواجهة برمجية gRPC/REST من الدرجة الأولى — مبني للمؤسسات التي تبني التطبيقات لا مجرد حمايتها.
بصمة الذاكرة أعلى من Authelia لأن ZITADEL يتطلب قاعدة بيانات (PostgreSQL أو CockroachDB)، لكنها تبقى في نطاق 150-300 ميغابايت في ظل الحمل الطبيعي — أقل بكثير من حد JVM الأدنى لـKeycloak البالغ 512 ميغابايت. يدعم المشروع OIDC وOAuth2 وSAML 2.0 وLDAP للقراءة فقط وWebAuthn.
ZITADEL مناسب بشكل خاص لفرق التطوير التي تبني تطبيقات SaaS وتحتاج إلى إدارة المؤسسات والمستخدمين برمجياً عبر API، دون الحاجة إلى واجهة رسومية لكل عملية. لوحة التحكم متوفرة لكن API هو المسار الرئيسي.
الهجرة من Keycloak إلى ZITADEL — إجراء على VPS
نشر ZITADEL باستخدام Docker Compose
يوفر ZITADEL ملف
docker-compose.ymlرسمياً في مستودع GitHub الخاص به (مجلدe2e/). يتطلب التكوين الأدنى PostgreSQL (أو CockroachDB) ومفتاحZITADEL_MASTERKEYمكوّن من 32 حرفاً:ZITADEL_MASTERKEY=$(openssl rand -base64 32)راجع الوثائق الرسمية على
https://zitadel.com/docs/self-hosting/deploy/composeللملف الكامل والمتغيرات البيئية المطلوبة.إنشاء تطبيقات OIDC في ZITADEL
في لوحة تحكم ZITADEL (
https://your-instance:8080)، أنشئ منظمة ثم مشروعاً. داخل هذا المشروع، أنشئ تطبيقاً من نوع «Web» أو «User Agent» حسب حالة استخدامك.يُنشئ ZITADEL معرّف عميل وسراً. كوّن عناوين Redirect URI باستخدام ملف JSON المُصدَّر من Keycloak كمرجع. نقطة نهاية الاكتشاف متاحة على
https://your-instance:8080/.well-known/openid-configuration.ترحيل المستخدمين من Keycloak
يمكن لـKeycloak تصدير المستخدمين من realm كـJSON عبر لوحة التحكم (Realm Settings → Export → ضع علامة على «Export users»). كلمات المرور المُجزَّأة لا يمكن استيرادها مباشرةً في ZITADEL — تختلف خوارزميات التجزئة.
نهجان: (1) استيراد بيانات المستخدمين عبر API ZITADEL مع إجبار إعادة تعيين كلمة المرور عند تسجيل الدخول الأول، أو (2) ترحيل تدريجي عبر تسجيل الدخول الاجتماعي/OIDC (يستهلك ZITADEL Keycloak كـIdP خارجي أثناء الانتقال). النهج (2) يتجنب مطالبة جميع المستخدمين بإعادة تعيين كلمة المرور في نفس اليوم.
تحديث تطبيقاتك للإشارة إلى ZITADEL
حدّث متغيرات البيئة لكل تطبيق:
OIDC_ISSUER=https://your-instance:8080OIDC_CLIENT_ID=<zitadel-client-id>OIDC_CLIENT_SECRET=<zitadel-client-secret>تسمح نقطة نهاية الاكتشاف لمعظم مكتبات OIDC بالتكوين الذاتي. اختبر كل تطبيق بحساب اختبار قبل تبديل حركة مرور الإنتاج.
التحقق من صحة تدفقات SSO وتعطيل Keycloak
تحقق من تسجيل الدخول وتسجيل الخروج وتحديث الرمز المميز والعامل الثاني على كل تطبيق. في ZITADEL، تتيح لك علامة تبويب «Sessions» في لوحة التحكم رؤية الجلسات النشطة في الوقت الفعلي وإلغاءها عند الحاجة.
أبقِ حاوية Keycloak موقوفة لا محذوفة لمدة 30 يوماً. احذفها بعد انتهاء فترة الاحتفاظ.
الإبقاء على Keycloak يعمل بالتوازي — استراتيجية التحويل النظيف
الاعتراض الكلاسيكي على ترحيل IdP صحيح: جميع تطبيقاتك تشترك في مزوّد هوية واحد. إذا فشل الترحيل في منتصف الطريق، لا أحد يستطيع تسجيل الدخول.
الاستراتيجية الموصى بها هي الإبقاء على Keycloak يعمل طوال مدة الترحيل وتحويل التطبيقات واحداً تلو الآخر. تُيسّر عدة آليات ذلك:
DNS لكل تطبيق: يُشير كل تطبيق إلى IdP عبر متغير بيئي. غيّر OIDC_ISSUER لتطبيق واحد في كل مرة، اختبره، ثم انتقل إلى التالي. يستمر Keycloak في خدمة التطبيقات غير المنقولة بعد.
جلسات مستقلة: يُنشئ OIDC جلسات تطبيق مستقلة. لا يُلغي تطبيق منقول إلى Authelia أو ZITADEL الجلسات النشطة للتطبيقات التي لا تزال على Keycloak.
أفق 30 يوماً: تستغرق معظم عمليات ترحيل أقل من 10 تطبيقات من يومين إلى خمسة أيام من العمل التقني. خطّط لأسبوع، تحقق لمدة 30 يوماً، ثم اقطع الاتصال. الأمر docker compose stop keycloak قابل للعكس في 30 ثانية.
الأخطاء الشائعة أثناء ترحيل SSO
أربعة مخاطر تتكرر باستمرار في عمليات الترحيل من Keycloak إلى البدائل الخفيفة.
نسيان عناوين URI لإعادة التوجيه: يتحقق Keycloak من عناوين redirect URI بدقة تامة بشكل افتراضي. Authelia وZITADEL يفعلان الشيء ذاته. إذا أرسل تطبيقك https://app.example.com/callback لكن تكوين IdP يُعلن https://app.example.com/oauth/callback، تفشل المصادقة بخطأ redirect_uri_mismatch. تحقق من كل عنوان URI في ملف JSON المُصدَّر من Keycloak.
النطاقات والمطالبات ليست متطابقة: يمكن تكوين Keycloak لإعادة مطالبات مخصصة (أدوار، سمات المستخدم) تستهلكها تطبيقاتك. يُعيد Authelia بشكل افتراضي openid وprofile وemail فقط. إذا اعتمد تطبيقك على مطالبة roles أو groups، تحقق من قدرة IdP المستهدف على إنتاجها قبل قطع الاتصال بـKeycloak.
جلسة IdP وجلسة التطبيق منفصلتان: لا يؤدي تسجيل الخروج من IdP تلقائياً إلى تسجيل الخروج من التطبيق إذا لم يُطبّق back-channel logout. قد يظل المستخدمون مسجّلين دخولهم في التطبيق بعد تسجيل خروجهم من IdP. اختبر تدفق تسجيل الخروج الكامل صراحةً.
انجراف الساعة يُلغي صلاحية الرموز: تتمتع رموز OIDC بنافذة صلاحية قصيرة (عادةً 5 إلى 15 دقيقة). إذا انجرفت ساعة VPS الخاص بك بأكثر من بضع عشرات من الثواني، تنتهي صلاحية الرموز قبل استخدامها. تحقق من أن chrony أو systemd-timesyncd نشط على VPS الخاص بك باستخدام timedatectl status.
بعد الترحيل — اختبار المصادقة لكل تطبيق
ترحيل SSO لم يكتمل عندما يعمل أول تسجيل دخول. إليك قائمة التحقق الأدنى التي يجب تطبيقها على كل تطبيق.
تسجيل الدخول الأول: افتح جلسة تصفح خاصة (لا ملفات تعريف ارتباط موجودة) وسجّل دخولك. يجب أن تعمل إعادة التوجيه إلى IdP، وتنجح المصادقة، وتهبط العودة إلى التطبيق على الصفحة الصحيحة.
رمز التحديث: انتظر انتهاء صلاحية رمز الوصول وتحقق من أن التطبيق يُحدّث الرمز بصمت دون إجبار إعادة تسجيل الدخول.
تسجيل الخروج: سجّل الخروج من التطبيق وتحقق من إلغاء صلاحية الجلسة على جانب IdP (Authelia: ملف تعريف ارتباط authelia_session غائب؛ ZITADEL: الجلسة غائبة من لوحة التحكم). حاول الوصول إلى مورد محمي بعد تسجيل الخروج — يجب أن تُحوَّل إلى صفحة تسجيل الدخول.
العامل الثاني: إذا كان المصادقة الثنائية مُفعَّلة، اختبر TOTP وWebAuthn بشكل منفصل. جلسات WebAuthn مرتبطة بالنطاق — الترحيل المتزامن للنطاق سيُلغي صلاحية جميع مفاتيح المرور الموجودة.
الوصول غير المصرح به: حاول الوصول إلى مورد محمي دون رمز صالح وتحقق من أن الاستجابة هي 401 أو إعادة توجيه إلى IdP، وليست 500 أو صفحة تطبيق بدون بيانات.
