لماذا بوابة مصادقة في الوكيل العكسي
بدون بوابة مركزية، تُدير كل خدمة تسجيل الدخول الخاص بها: Grafana لها قاعدة مستخدمين، Nextcloud لها قاعدتها، Portainer لها قاعدتها. النتيجة: كلمات مرور مختلفة في كل مكان، لا MFA متسق، وسطح هجوم متعدد. تحل Authelia هذه المشكلة بالتوضع في مسار HTTP: يُرسل وكيلك العكسي كل طلب إليها قبل إعادة توجيهه، وتقرر Authelia — بناءً على الهوية والمجموعة والمسار المطلوب ومستوى MFA المطلوب — إذا كان يجب السماح بالطلب. لا يرى التطبيق المحمي إلا طلباً مصادقاً مع ترويسات هوية مُضافة.
ما تمنحك إياه Authelia المستضافة ذاتياً
- مصادقة مركزية لجميع خدماتك دون تعديل كودها
- MFA أصلي: TOTP (Google Authenticator، Aegis)، WebAuthn/مفاتيح مرور (مفاتيح مادية، Touch ID، Windows Hello)، Duo
- موفر OIDC في الإنتاج منذ v4.34: تفويض المصادقة من تطبيقاتك المتوافقة مع OIDC إلى Authelia
- تحكم دقيق في الوصول حسب النطاق، المسار، مجموعة المستخدمين، ومستوى المصادقة
- تكامل أصلي مع Traefik (forwardAuth) وNginx (auth_request) وCaddy (forward_auth)
- دعم LDAP/Active Directory لإدارة الفرق، متوافق مع LLDAP
- ملف ثنائي Go واحد (~30 ميغابايت)، صورة Docker خفيفة، استهلاك ذاكرة منخفض
- سجلات JSON منظمة ومقاييس Prometheus للمراقبة
المتطلبات المسبقة
قبل نشر Authelia، تحقق من جاهزية بيئتك. تحتاج إلى VPS يعمل بـ Linux مع Docker وDocker Compose مثبتَين، وكيل عكسي موجود (Traefik v2/v3 أو Nginx)، اسم نطاق مع شهادة TLS صالحة (Let's Encrypt موصى به)، ونسخة Redis يمكن لـ Authelia الوصول إليها لتخزين الجلسات (إلزامي في الإنتاج). لتخزين المستخدمين، يمكنك البدء بملف YAML محلي أو ربط خادم LDAP مثل LLDAP. تحتاج Authelia أيضاً إلى مفتاح JWT، مفتاح تشفير الجلسة، وسر OIDC إذا فعّلت هذا الوضع: أنشئها بـ openssl rand -hex 32.
نشر Authelia مع Docker Compose
إنشاء هيكل الدلائل
أنشئ
/opt/authelia/config/لملفات الإعداد و/opt/authelia/data/لتخزين SQLite والمفاتيح. عيّن الأذونات المناسبة:mkdir -p /opt/authelia/{config,data} && chown -R 1000:1000 /opt/authelia.كتابة ملف configuration.yml
أنشئ
/opt/authelia/config/configuration.yml. حددdefault_redirection_url،jwt_secret،session.secret،storage.encryption_key، وعيّن خلفية المصادقة (ملف أو LDAP)، Redis للجلسات، وسياسة الوصول الافتراضية (denyموصى به).إنشاء ملف users_database.yml (خلفية الملف)
للبدء السريع، أنشئ
/opt/authelia/config/users_database.ymlبمستخدميك. يجب تجزئة كلمات المرور بـ Argon2id:docker run --rm authelia/authelia:latest authelia crypto hash generate argon2 --password 'كلمةمرورك'. انسخ التجزئة المولّدة في الملف.إعداد Redis للجلسات
أضف Redis إلى
docker-compose.yml. فيconfiguration.yml، عيّنsession.redis.host: redisوsession.redis.port: 6379. Redis ضروري لاستمرار الجلسات بعد إعادة تشغيل Authelia.كتابة docker-compose.yml
عرّف خدمات
autheliaوredis، وإذا كنت تستخدم Traefik أضف التسميات المناسبة. ثبّت/opt/authelia/configللقراءة فقط و/opt/authelia/dataللقراءة والكتابة. اكشف المنفذ 9091 داخلياً فقط، لا تكشفه للإنترنت مباشرة.إعداد Traefik مع forwardAuth
أنشئ وسيطاً في Traefik يشير إلى
http://authelia:9091/api/authz/forward-auth. طبّق هذا الوسيط على موجّهات الخدمات المراد حمايتها. بالنسبة لـ Nginx، استخدمauth_request /autheliaمع توجيهاتproxy_passالمناسبة.إعداد نطاق الجلسة
في
configuration.yml، عيّنsession.domainإلى نطاقك الجذر (مثلmynomain.com) ليتشارك الكوكي بين النطاقات الفرعية. هذا هو السبب الأكثر شيوعاً لحلقات التحويل اللانهائية.التشغيل والتحقق
شغّل بـ
docker compose up -d. راجع السجلات:docker compose logs -f authelia. ادخل إلىhttps://auth.mynomain.comلرؤية بوابة تسجيل الدخول. اختبر بالدخول إلى خدمة محمية: يجب أن تُعاد توجيهك إلى البوابة ثم تُرسل إلى الخدمة بعد المصادقة.تفعيل موفر OIDC (اختياري)
منذ v4.34، موفر OIDC جاهز للإنتاج. أضف قسم
identity_providers.oidcإلى إعداداتك مع عملاءك (Nextcloud، Grafana، Gitea...). كل عميل لهid،secret(مُجزّأ بـ Argon2id)، وredirect_urisالمصرح بها.
استخدام Authelia كموفر OIDC لـ SSO حقيقي
يحوّل وضع موفر OIDC Authelia إلى SSO حقيقي: يسجل المستخدم الدخول مرة واحدة على بوابة Authelia، وجميع التطبيقات المُعدّة كعملاء OIDC تسترجع الهوية دون طلب كلمة مرور مرة أخرى. Nextcloud وGrafana وGitea وPortainer وOutline... كلها تدعم OIDC. عيّن نطاق groups لنقل مجموعات Authelia إلى التطبيقات العميلة لإدارة الأدوار.
قواعد التحكم في الوصول: أمثلة عملية
قسم access_control هو قلب منطق Authelia. منذ v4.37، أُعيد تصميم السياسات. وصول عام بدون مصادقة: {domain: 'status.mynomain.com', policy: bypass}. وصول MFA قوي مقتصر على المديرين: {domain: 'portainer.mynomain.com', subject: 'group:admins', policy: two_factor}. مسار API بدون مصادقة (webhooks): {domain: 'n8n.mynomain.com', resources: ['^/webhook/.*'], policy: bypass}. باقي N8N بـ MFA بسيط: {domain: 'n8n.mynomain.com', policy: one_factor}. default_policy: deny يضمن حظر كل ما لم يُذكر صراحة. ترتيب القواعد مهم: تُطبّق أول قاعدة مطابقة.
MFA: TOTP، WebAuthn/مفاتيح المرور، وDuo
تدعم Authelia ثلاث طرق للعامل الثاني، لكل منها مزاياها.
TOTP (كلمة المرور لمرة واحدة المبنية على الوقت) هي الطريقة الأكثر عالمية: يمسح المستخدم رمز QR بتطبيق كـ Aegis (أندرويد) أو Raivo (iOS). رمز مكوّن من 6 أرقام يتغير كل 30 ثانية. بسيطة النشر، متوافقة مع جميع الأجهزة، لكنها عرضة للتصيد الاحتيالي.
WebAuthn/مفاتيح المرور هي الطريقة الأكثر متانة، مدعومة أصلياً في Authelia منذ v4.36. يسجّل المستخدم مفتاحاً مادياً (YubiKey، Nitrokey) أو محقق نظام الأساس (Touch ID على macOS، Windows Hello، Face ID على iOS). تشفير المفتاح العام يجعل التصيد الاحتيالي مستحيلاً: المفتاح الخاص لا يغادر الجهاز أبداً. Authelia تُنفّذ مواصفات WebAuthn Level 2 الكاملة، بما يشمل مفاتيح المرور المتزامنة عبر iCloud Keychain أو Google Password Manager.
Duo تُفوّض العامل الثاني إلى خدمة Duo Security السحابية: دفع موبايل، رسالة نصية، أو مكالمة هاتفية. مناسب للفرق التي تستخدم Duo بالفعل.
للمعظم من البنى المستضافة ذاتياً، الجمع الموصى به هو TOTP كطريقة أساسية وWebAuthn كطريقة مفضلة للمستخدمين الذين لديهم YubiKey أو جهاز Apple/Windows حديث.
الانتقال إلى LLDAP: إدارة الفرق
خلفية الملف (users_database.yml) مناسبة لمستخدم واحد أو عائلة صغيرة، لكنها تصبح صعبة الإدارة مع أكثر من 5-10 مستخدمين. LLDAP تطبيق LDAP خفيف مكتوب بـ Rust مع واجهة ويب بسيطة، يتكامل بشكل مثالي مع Authelia.
انشر LLDAP بإضافة خدمته إلى docker-compose.yml مع المتغيرات LLDAP_JWT_SECRET وLLDAP_LDAP_BASE_DN. أنشئ مجموعاتك في واجهة LLDAP (admins، users، devops...)، ثم عدّل configuration.yml للتبديل من خلفية file إلى خلفية ldap.
انتبه لتغيير v4.35 الجذري: كان اسم الحقل authentification_backend (بخطأ إملائي) قبل v4.35 وصُحّح إلى authentication_backend. تحقق من إعداداتك إذا كنت تنقل من إصدار سابق.
تحديث Authelia: تجنب التغييرات الجذرية
تتبع Authelia إصدارات دلالية صارمة وتوثّق تغييراتها الجذرية لكل إصدار — اقرأ سجل التغييرات من إصدارك الحالي قبل أي ترقية.
v4.34: موفر OIDC يصل إلى مرحلة الإنتاج. إذا كنت تستخدمه في الوضع التجريبي، تحقق من تغييرات الأسماء في الخيارات.
v4.35: تصحيح الخطأ المطبعي authentification_backend ← authentication_backend. أي إعداد يستخدم الاسم القديم يمنع الإطلاق مع خطأ تحقق من الإعداد.
v4.37: إعادة تصميم سياسات access_control — راجع سجل التغييرات الرسمي قبل الترقية من v4.36 أو أقدم.
v4.38.x (الإصدار الحالي): استقرار، بدون تغييرات جذرية كبيرة منذ v4.37.
إجراء الترقية الموصى به: (1) اقرأ سجل التغييرات؛ (2) احتفظ بنسخة احتياطية من /opt/authelia/config/ و/opt/authelia/data/؛ (3) اختبر الإعداد الجديد بـ docker run --rm -v /opt/authelia/config:/config authelia/authelia:4.38.x authelia validate-config قبل إعادة التشغيل؛ (4) حدّث الوسم في docker-compose.yml وأعد التشغيل.
المراقبة: السجلات ومقاييس Prometheus
تكشف Authelia مقاييسها لـ Prometheus على /metrics (المنفذ الافتراضي 9959). فعّلها في configuration.yml بإضافة telemetry.metrics.enabled: true وtelemetry.metrics.address: 'tcp://0.0.0.0:9959'. لا تكشف هذا المنفذ للعموم: اجعله متاحاً فقط لخط المراقبة الداخلي (Prometheus/Grafana).
المقاييس الرئيسية للرصد: authelia_authn_requests_total (إجمالي محاولات التوثيق مصنّفةً بالنجاح والفشل)، وauthelia_authn_duration_seconds (زمن الاستجابة)، إضافةً إلى مقاييس Redis لمراقبة صحة الجلسات. للسجلات، يدعم Authelia الصيغة المنظمة JSON (log.format: json) المثالية للاستيعاب في Loki أو نظام SIEM. استخدم log.level: info في الإنتاج (تجنب debug الذي يسجّل ترويسات كاملة). سجلات التوثيق تتضمن عنوان IP المصدر، واسم المستخدم، والخدمة المستهدفة، والنتيجة — قيّمة لاكتشاف هجمات القوة الغاشمة مبكراً.
Authelia مقابل Authentik: أيهما تختار؟
مرّر الجدول أفقيًا
| المعيار | Authelia | Authentik |
|---|---|---|
| حجم Docker | ~30 ميغابايت (ثنائي Go) | ~1.5 غيغابايت (Python/Django + worker) |
| الحد الأدنى للذاكرة | ~50 ميغابايت | ~512 ميغابايت موصى به |
| موفر OIDC | نعم، منذ v4.34 | نعم، ناضج وغني |
| موفر SAML | لا | نعم |
| واجهة الإدارة | إعداد YAML فقط | واجهة ويب كاملة |
| وكيل التطبيقات | لا | نعم (أنفاق Authentik) |
| توفير SCIM | لا | نعم |
| حالة الاستخدام المثالية | بنية خفيفة، وكيل عكسي بحت، إعداد كـ كود | IAM كامل، SSO مؤسسي، احتياجات SAML/SCIM |
استكشاف الأخطاء الشائعة وإصلاحها
حلقة تحويل لانهائية. يُعاد توجيه المستخدم في حلقة بين الخدمة وبوابة Authelia. السبب الأكثر شيوعاً: session.domain لا يتطابق مع نطاق الخدمة. تحقق أيضاً من تطبيق forwardAuth middleware وأن default_redirection_url يشير إلى عنوان URL صالح.
عدم تطابق النطاق للكوكي. يجب أن يكون session.domain هو النطاق الأب المشترك (mysite.com)، وليس نطاقاً فرعياً. تحقق في أدوات المطورين (Application > Cookies) أن authelia_session يحمل النطاق الصحيح.
Redis غير متاح. تعمل Authelia لكن الجلسات لا تستمر. تحقق أن حاوية Redis على الشبكة ذاتها في Docker وأن host يتطابق مع اسم الخدمة (وليس localhost).
إعداد غير صالح عند البدء. منذ v4.35، يُتحقق من المخطط بصرامة. استخدم authelia validate-config قبل أي إعادة تشغيل. الأخطاء الأكثر شيوعاً: الخطأ المطبعي authentification_backend، مسافة بادئة YAML خاطئة، أو client_secret يجب تجزئته بـ Argon2id منذ v4.37.
عدم طرح المصادقة الثنائية رغم قواعد two_factor. تأكد أن المستخدم قد سجّل عاملاً ثانياً في ملفه الشخصي. بدون جهاز MFA مسجّل، قد تطبّق Authelia خياراً احتياطياً لـ one_factor بحسب إعداد default_2fa_method.
نصيحة أخيرة: ابدأ بسيطاً وتطور تدريجياً
انشر أولاً Authelia مع خلفية الملف، قاعدة two_factor واحدة لخدماتك الأكثر تعرضاً، وTOTP كطريقة MFA. بمجرد الاستقرار، انتقل إلى LLDAP لإدارة الفرق، فعّل موفر OIDC لـ SSO، ثم أضف WebAuthn للمستخدمين الذين لديهم مفتاح مادي أو جهاز يدعم مفاتيح المرور. هذا التدرج يمنعك من تصحيح عدة مكوّنات جديدة في آنٍ واحد.
