لماذا بوابة مصادقة على مستوى الوكيل العكسي
كل أداة مُستضافة ذاتياً تضيفها إلى خادم VPS الخاص بك هي سطح هجوم جديد. بعضها يملك مصادقة متينة (Gitea، Nextcloud)، وبعضها الآخر مُصمّم لشبكات موثوقة (Prometheus، Dockge، لوحات التحكم الداخلية) ويأتي دون أي مصادقة على الإطلاق. إضافة تحقّق باسم مستخدم وكلمة مرور لكل تطبيق على حدة يستغرق وقتاً، ويخلق تبايناً، ويترك لك مع ذلك إدارة عشرات مخازن بيانات الاعتماد المنفصلة.
يحلّ Authelia هذا على مستوى البنية التحتية. تهيّئه مرة واحدة — بقواعد مثل «أي شخص يصل إلى *.internal.yourdomain.com يجب أن يُكمل المصادقة الثنائية» — ويفرض وكيلك العكسي تلك القواعد على كل طلب قبل أن يصل إلى التطبيق. التطبيقات نفسها لا تحتاج إلى أي تغييرات.
ما الذي يمنحك إياه Authelia المُستضاف ذاتياً
- مصادقة ثنائية لأي تطبيق: TOTP (Google Authenticator، Ente Auth، Aegis)، وWebAuthn/Passkeys (Touch ID، Face ID، YubiKey)، ودفع Duo — تُهيّأ مرة واحدة، وتُفرض في كل مكان.
- مزوّد OpenID Connect (OIDC): هيّئ Authelia بوصفه مزوّد الهوية لـ Gitea وNextcloud وMattermost وأي تطبيق متوافق مع OIDC. تسجيل دخول واحد لكل تطبيقاتك.
- تحكّم دقيق في الوصول: عرّف سياسات لكل نطاق أو نطاق فرعي أو مسار URL أو شبكة IP أو مجموعة مستخدمين — سماح، أو رفض، أو عامل واحد، أو عاملين.
- غير مرتبط بوكيل عكسي بعينه: تكامل بالنسخ واللصق مع Nginx وCaddy وTraefik وHAProxy وEnvoy عبر توجيه
forward_authواحد. - أقل من 30 MB من الذاكرة في وضع الخمول — أضِفه إلى أي خادم VPS قائم دون التأثير على أحمال العمل الجارية.
- خلفية مستخدمين قائمة على ملف أو على LDAP — ابدأ ببساطة، ووسّع لاحقاً.
المتطلبات
خادم VPS بمعالج افتراضي واحد على الأقل و512 MB من الذاكرة (يُوصى بـ 1 GB) يعمل بنظام Ubuntu 22.04 أو Debian 12، مع تثبيت Docker وDocker Compose v2. اسم نطاق يشير إلى خادم VPS مطلوب — يجب أن تكون ملفات تعريف الارتباط للجلسات في Authelia واستدعاءات OIDC مرتبطة بـ FQDN صحيح، وHTTPS عبر Let's Encrypt إلزامي. إذا كان خادم VPS الخاص بك يشغّل بالفعل Caddy أو Nginx كوكيل عكسي، فإن Authelia يندمج بجانبه.
انشر Authelia باستخدام Docker Compose
اكتب ملف Compose
أنشئ /opt/authelia/compose.yaml. الحُزمة عبارة عن خدمتين: authelia/authelia:4.39.20 وredis:7-alpine. يخزّن Authelia بيانات الجلسة في Redis وحالة التطبيق (قاعدة بيانات SQLite، سجل الإشعارات) في حجم Docker مُسمّى مُحمّل عند /data. يوفّر ربطان (bind mounts) من ./ ملف التهيئة وقاعدة بيانات المستخدمين — يُولّدهما مهمة التوفير في ServOrbit.
أنشئ configuration.yml
يقرأ Authelia تهيئته من /config/configuration.yml (مُحمّل بالربط من المضيف). تضبط التهيئة الدنيا عنوان الخادم (tcp://:9091)، وخلفية مصادقة الملف (/config/users.yml)، ونطاق الجلسة وسرّها، ومسار تخزين SQLite، ومضيف جلسة Redis، وقواعد التحكم في الوصول. ابدأ بـ default_policy: deny وأضِف قواعد one_factor لنطاقاتك.
أنشئ قاعدة بيانات المستخدمين
تقرأ خلفية الملف في Authelia من ملف YAML يضم أسماء المستخدمين، وكلمات المرور المُجزّأة بـ bcrypt، والبريد الإلكتروني، والمجموعات. ولّد تجزئة لكلمة مرور المسؤول عبر: docker run --rm authelia/authelia:4.39.20 authelia crypto hash generate bcrypt. الصِق المخرجات في users.yml. في ServOrbit، تكتب مهمة التوفير هذا الملف تلقائياً بكلمة مرور مُولّدة تُعرض في مخرجات المهمة.
شغّل الحُزمة وتحقّق
شغّل docker compose up -d في /opt/authelia. تحقّق من أن كلتا الحاويتين سليمتان عبر docker compose ps. يعرّض Authelia نقطة نهاية للصحة عند GET /api/health — ينبغي أن يُعيد curl -s http://localhost:9091/api/health القيمة {"status":"OK"}. تصبح بوابة تسجيل الدخول بعدها متاحة عند https://auth.yourdomain.com بمجرد تهيئة وكيلك العكسي.
أضِف توجيه forward_auth إلى وكيلك
بالنسبة لـ Caddy، أضِف forward_auth authelia:9091 إلى كتل المواقع التي تريد حمايتها، مع الإشارة إلى اسم خدمة حاوية Authelia إذا كانتا على شبكة Docker نفسها. بالنسبة لـ Nginx، أضِف auth_request /authelia; وكتلة الموقع المقابلة. يتضمّن توثيق Authelia مقتطفات دقيقة للنسخ واللصق لكل وكيل رئيسي. أعِد تحميل تهيئة وكيلك — يتطلّب الآن كل تطبيق محمي تسجيل دخول عبر Authelia.
سجّل جهاز المصادقة الثنائية الخاص بك
سجّل الدخول إلى بوابة Authelia عند https://auth.yourdomain.com ببيانات اعتماد المسؤول. سيُطلب منك تسجيل عامل ثانٍ. افتح تطبيق TOTP الخاص بك (Google Authenticator أو Ente Auth أو Aegis)، وامسح رمز QR، وأكّد. لمفاتيح المرور (WebAuthn)، انقر «Security Key or Passkey» واتبع تعليمات متصفحك — تعمل جميعها: Face ID وTouch ID وYubiKey. تتطلّب عمليات الدخول المستقبلية كلمة مرورك بالإضافة إلى العامل المُسجّل.
أول تسجيل دخول
افتح عنوان بوابتك: يطلب Authelia اسم مستخدم وكلمة مرور. أدخل اسم المستخدم admin وكلمة المرور التي سُلّمت إليك (تجدها في قسم التطبيقات بمساحة العميل)، ثم سجّل فورًا تطبيق المصادقة (TOTP) أو مفتاح المرور الخاص بك — فهذا العامل الثاني هو ما سيحمي لاحقًا كل ما تضعه خلف هذه البوابة.
استخدم Authelia بوصفه مزوّد OIDC للدخول الموحّد الحقيقي
بمجرد تشغيل Authelia، يمكنك تسجيل تطبيقاتك الأخرى المُستضافة ذاتياً كعملاء OIDC. في configuration.yml، أضِف كتلة identity_providers.oidc تُدرج معرّف العميل والسرّ وعناوين إعادة التوجيه لكل تطبيق. ثم هيّئ التطبيق (Gitea، Nextcloud، Grafana…) لاستخدام Authelia بوصفه مزوّد OIDC الخاص به. يصادِق المستخدمون مرة واحدة عند auth.yourdomain.com ويُوجَّهون بصمت إلى كل تطبيق متصل بـ OIDC — دون مطالبات دخول منفصلة، وبجلسة واحدة لكامل منظومتك.
قواعد التحكم في الوصول
قسم التحكم في الوصول في Authelia هو حيث تعرّف مَن يمكنه الوصول إلى ماذا. تُقيَّم القواعد من الأعلى إلى الأسفل؛ والمطابقة الأولى تفوز. قد تتجاوز تهيئة إنتاج دنيا تطبيقاتك الموجّهة للعامة، وتتطلّب عاملاً واحداً للأدوات الداخلية العامة، وتفرض عاملين لأي شيء حسّاس (لوحات المسؤول، مديري الأسرار، قواعد البيانات). استخدم حقل groups في users.yml للتمييز بين المسؤولين والمستخدمين العاديين وتطبيق سياسات أكثر صرامة على أعضاء مجموعة المسؤولين.
