الصفحة الرئيسية>المتعلقة بالبرمجة>شفرة المصدر الأخرى
تنزيل

وكيل القسيمة

حل SSO لـ Nginx باستخدام وحدة auth_request. يمكن لـ Vouch Proxy حماية جميع مواقع الويب الخاصة بك مرة واحدة.

يدعم Vouch Proxy العديد من موفري تسجيل الدخول OAuth وOIDC ويمكنه فرض المصادقة على...

  • جوجل

  • جيثب

  • جيثب المؤسسة

  • IndieAuth

  • اوكتا

  • سلاك

  • ADFS

  • أزور م

  • علي بابا / عليون إيداس

  • أوس كوجنيتو

  • نشل

  • الفتنة

  • SecureAuth

  • جيتيا

  • عباءة المفاتيح

  • مكتبة خادم OAuth2 لـ PHP

  • مساعد المنزل

  • أوبنستاكس

  • أوري هيدرا

  • السحابة التالية

  • معظم موفري OpenID Connect (OIDC) الآخرين

يرجى إعلامنا عندما تقوم بنشر Vouch Proxy مع IdP أو المكتبة المفضلة لديك حتى نتمكن من تحديث القائمة.

إذا كان Vouch يعمل على نفس المضيف مثل وكيل Nginx العكسي، فيجب أن يكون وقت الاستجابة من نقطة النهاية /validate إلى Nginx أقل من 1 مللي ثانية .

جدول المحتويات

  • ما الذي يفعله وكيل القسيمة...

  • التثبيت والتكوين

    • وكيل القسيمة "في المسار"

    • تكوينات Nginx الإضافية

    • التكوين عبر المتغيرات البيئية

  • النصائح والحيل والتكوينات المتقدمة

    • النطاقات والمطالبات

  • يعمل من دوكر

  • دخول Kubernetes Nginx

  • التجميع من المصدر وتشغيل الملف الثنائي

  • / تسجيل الدخول و / إعادة توجيه نقطة النهاية

  • استكشاف الأخطاء وإصلاحها وطلبات الدعم والميزات (اقرأ هذا قبل إرسال مشكلة على GitHub)

    • أحصل على حلقة إعادة توجيه لا نهائية تعيدني إلى IdP الخاص بي (Google/Okta/GitHub/...)

    • حسنًا، لقد ألقيت نظرة على المشكلات وجربت بعض الأشياء باستخدام التكوينات الخاصة بي ولكنها ما زالت لا تعمل

    • المساهمة في قسيمة الوكيل

  • التفويض المتقدم باستخدام OpenResty

  • تدفق تسجيل الدخول والمصادقة باستخدام Google Oauth

ما يفعله وكيل القسيمة

يفرض Vouch Proxy (VP) على الزائرين تسجيل الدخول والمصادقة باستخدام IdP (مثل إحدى الخدمات المذكورة أعلاه) قبل السماح لهم بالوصول إلى موقع الويب.

Vouch Proxy يحمي مواقع الويب

يمكن أيضًا استخدام VP كحل لتسجيل الدخول الموحد (SSO) لحماية جميع تطبيقات الويب في نفس المجال.

يعد Vouch Proxy أحد حلول تسجيل الدخول الموحد

بعد أن يقوم الزائر بتسجيل الدخول، يسمح Vouch Proxy بالوصول إلى مواقع الويب المحمية لعدة ساعات. يتم فحص كل طلب بواسطة VP للتأكد من صحته.

يمكن لـ VP إرسال البريد الإلكتروني للزائر واسمه والمعلومات الأخرى التي يوفرها IdP (بما في ذلك رموز الوصول) إلى تطبيق الويب كرؤوس HTTP. يمكن استخدام VP ليحل محل إدارة مستخدم التطبيق بالكامل.

التثبيت والتكوين

يعتمد Vouch Proxy على القدرة على مشاركة ملف تعريف الارتباط بين خادم Vouch Proxy والتطبيق الذي يحميه. عادةً ما يتم ذلك عن طريق تشغيل Vouch على نطاق فرعي مثل vouch.yourdomain.com مع التطبيقات التي تعمل على app1.yourdomain.com و app2.yourdomain.com . المجال المحمي هو .yourdomain.com ويجب تعيين ملف تعريف الارتباط Vouch Proxy في هذا المجال عن طريق تعيين vouch.domains ليشمل yourdomain.com أو في بعض الأحيان عن طريق تعيين vouch.cookie.domain على yourdomain.com .

  • cp ./config/config.yml_example_$OAUTH_PROVIDER ./config/config.yml

  • قم بإنشاء بيانات اعتماد OAuth لـ Vouch Proxy على google أو github، وما إلى ذلك

    • تأكد من توجيه عنوان URL لرد الاتصال إلى نقطة نهاية Vouch Proxy /auth

  • تكوين نجينكس...

يفترض تكوين Nginx التالي ..

  • يتم تشغيل Nginx و vouch.yourdomain.com و protectedapp.yourdomain.com على نفس الخادم

  • يتم تقديم كلا النطاقين كـ https ولديهما شهادات صالحة (إذا لم يكن الأمر كذلك، قم بالتغيير listen 80 وتعيين vouch.cookie.secure إلى false )

 الخادم { استمع 443 SSL http2؛    server_name protectedapp.yourdomain.com;    الجذر /فار/www/html/;    ssl_certificate /etc/letsencrypt/live/protectedapp.yourdomain.com/fullchain.pem;    ssl_certificate_key /etc/letsencrypt/live/protectedapp.yourdomain.com/privkey.pem;    # إرسال جميع الطلبات إلى نقطة النهاية `/ التحقق من الصحة` للحصول على إذن auth_request /validate؛    location = /validate { # إعادة توجيه طلب /validate إلى Vouch Proxy proxy_pass http://127.0.0.1:9090/validate;      # تأكد من تمرير رأس المضيف الأصلي proxy_set_header Host $http_host;      # يعمل Vouch Proxy فقط على رؤوس الطلبات proxy_pass_request_body off;      proxy_set_header طول المحتوى ""؛      # قم بإضافة X-Vouch-User اختياريًا كما تم إرجاعه بواسطة Vouch Proxy مع الطلب auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user;      # أضف بشكل اختياري X-Vouch-IdP-Claims-* المطالبات المخصصة التي تتبعها # auth_request_set $auth_resp_x_vouch_idp_claims_groups $upstream_http_x_vouch_idp_claims_groups;      # auth_request_set $auth_resp_x_vouch_idp_claims_given_name $upstream_http_x_vouch_idp_claims_given_name;      # إضافة X-Vouch-IdP-AccessToken أو X-Vouch-IdP-IdToken اختياريًا # auth_request_set $auth_resp_x_vouch_idp_accesstoken $upstream_http_x_vouch_idp_accesstoken;      # auth_request_set $auth_resp_x_vouch_idp_idtoken $upstream_http_x_vouch_idp_idtoken;      # يتم استخدام قيم الإرجاع هذه بواسطة استدعاء @error401 auth_request_set $auth_resp_jwt $upstream_http_x_vouch_jwt;      auth_request_set $auth_resp_err $upstream_http_x_vouch_err;      auth_request_set $auth_resp_failcount $upstream_http_x_vouch_failcount;      # يمكن تشغيل Vouch Proxy خلف نفس وكيل Nginx العكسي # قد يحتاج إلى الامتثال لتسمية الخادم "المنبع" # proxy_pass http://vouch.yourdomain.com/validate;      # proxy_set_header المضيف $http_host;
    } # إذا أعاد التحقق من الصحة `401 غير مصرح به`، فقم بإعادة توجيه الطلب إلى error401block error_page 401 = @error401;    location @error401 { # إعادة التوجيه إلى Vouch Proxy لتسجيل الدخول return 302 https://vouch.yourdomain.com/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error=$ auth_resp_err;        # عادةً *تريد* إعادة التوجيه إلى Vouch الذي يعمل خلف نفس تكوين Nginx المحمي بواسطة https # ولكن للبدء، يمكنك فقط إعادة توجيه المستخدم النهائي إلى المنفذ الذي يعمل عليه الإيصال # return 302 http://vouch.yourdomain.com:9090/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error=$auth_resp_err;
    } location / { # إعادة توجيه الطلبات المصرح بها إلى خدمتك protectedapp.yourdomain.com proxy_pass http://127.0.0.1:8080;      # قد تحتاج إلى تعيين هذه المتغيرات في هذه الكتلة وفقًا لـ https://github.com/vouch/vouch-proxy/issues/26#issuecomment-425215810 # auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user # auth_request_set $auth_resp_x_vouch_idp_claims_groups $upstream_http_x_vouch_idp_claims_groups;      # auth_request_set $auth_resp_x_vouch_idp_claims_given_name $upstream_http_x_vouch_idp_claims_given_name;      # تعيين رأس المستخدم (عادةً بريد إلكتروني) proxy_set_header X-Vouch-User $auth_resp_x_vouch_user;      # قم بتمرير أي مطالبات مخصصة تقوم بتتبعها بشكل اختياري # proxy_set_header X-Vouch-IdP-Claims-Groups $auth_resp_x_vouch_idp_claims_groups;      # proxy_set_header X-Vouch-IdP-Claims-Given_Name $auth_resp_x_vouch_idp_claims_given_name;      # قم بتمرير رمز الوصول أو رمز التعريف اختياريًا # proxy_set_header X-Vouch-IdP-AccessToken $auth_resp_x_vouch_idp_accesstoken;      # proxy_set_header X-Vouch-IdP-IdToken $auth_resp_x_vouch_idp_idtoken;
    }
}

إذا تم تكوين Vouch خلف نفس وكيل nginx العكسي (ربما حتى تتمكن من تكوين SSL)، فتأكد من تمرير رأس Host بشكل صحيح، وإلا فلن يمكن تعيين ملف تعريف الارتباط JWT في المجال

 الخادم { استمع 443 SSL http2؛    اسم الخادم vouch.yourdomain.com;    ssl_certificate /etc/letsencrypt/live/vouch.yourdomain.com/fullchain.pem;    ssl_certificate_key /etc/letsencrypt/live/vouch.yourdomain.com/privkey.pem;    الموقع / { proxy_pass http://127.0.0.1:9090;      # تأكد من تمرير رأس المضيف الأصلي proxy_set_header Host $http_host;
    }
}

وكيل القسيمة "في المسار"

اعتبارًا من v0.33.0 يمكن تقديم Vouch Proxy داخل موقع (مسار) Nginx عن طريق تكوين vouch.document_root: /vp_in_a_path

يؤدي هذا إلى تجنب الحاجة إلى إعداد مجال منفصل لـ Vouch Proxy مثل vouch.yourdomain.com . على سبيل المثال، سيتم تقديم تسجيل دخول VP من https://protectedapp.yourdomain.com/vp_in_a_path/login

 الخادم { استمع 443 SSL http2؛    server_name protectedapp.yourdomain.com;    ssl_certificate /etc/letsencrypt/live/protectedapp.yourdomain.com/fullchain.pem;    ssl_certificate_key /etc/letsencrypt/live/protectedapp.yourdomain.com/privkey.pem;    # يخدم هذا الموقع جميع نقاط نهاية Vouch Proxy كـ /vp_in_a_path/$uri # بما في ذلك /vp_in_a_path/validate، /vp_in_a_path/login، /vp_in_a_path/logout، /vp_in_a_path/auth، /vp_in_a_path/auth/$STATE، إلخ location /vp_in_a_path { proxy_pass http://127.0.0.1:9090; #لا يجب! ضع شرطة مائلة في النهاية proxy_set_header Host $http_host؛      proxy_pass_request_body معطل;      proxy_set_header طول المحتوى ""؛      # يتم استخدام قيم الإرجاع هذه بواسطة استدعاء @error401 auth_request_set $auth_resp_jwt $upstream_http_x_vouch_jwt;      auth_request_set $auth_resp_err $upstream_http_x_vouch_err;      auth_request_set $auth_resp_failcount $upstream_http_x_vouch_failcount;
    } # إذا قام /vp_in_a_path/validate بإرجاع `401 غير مصرح به`، فقم بإعادة توجيه الطلب إلى error401block error_page 401 = @error401;    location @error401 { # إعادة التوجيه إلى Vouch Proxy لتسجيل الدخول return 302 https://protectedapp.yourdomain.com/vp_in_a_path/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error =$auth_resp_err;
    } الموقع / { auth_request /vp_in_a_path/validate;      proxy_pass http://127.0.0.1:8080;      # راجع تكوين Nginx أعلاه للحصول على رؤوس إضافية يمكن ضبطها من Vouch Proxy
    }
}

تكوينات Nginx الإضافية

يمكن العثور على تكوينات Nginx الإضافية في دليل الأمثلة.

التكوين عبر المتغيرات البيئية

إليك الحد الأدنى من الإعداد باستخدام OAuth من Google...

 VOUCH_DOMAINS=yourdomain.com
   OAUTH_PROVIDER=google
   OAUTH_CLIENT_ID=1234
   OAUTH_CLIENT_SECRET=secretsecret
   OAUTH_CALLBACK_URL=https://vouch.yourdomain.com/auth
   ./vouch-proxy

تم توثيق أسماء المتغيرات البيئية في config/config.yml_example

يجب أن تكون جميع القوائم ذات القيم المتعددة مفصولة بفواصل: VOUCH_DOMAINS="yourdomain.com,yourotherdomain.com"

يمكن استخدام المتغير VOUCH_CONFIG لتعيين موقع بديل لملف التكوين. يمكن استخدام VOUCH_ROOT لتعيين دليل جذر بديل لـ Vouch Proxy للبحث عن ملفات الدعم.

النصائح والحيل والتكوينات المتقدمة

تم توثيق كافة عناصر تكوين Vouch Proxy في config/config.yml_example

  • التخزين المؤقت لـ Vouch Proxy /validate الاستجابة في Nginx

  • التعامل مع طلبات OPTIONS عند حماية واجهة برمجة التطبيقات (API) باستخدام Vouch Proxy

  • التحقق من الصحة بواسطة فريق GitHub أو GitHub Org

  • تشغيل VP على Raspberry Pi باستخدام صورة Docker المستندة إلى ARM

  • بنية Kubernetes بعد الدخول

  • قم بتعيين HTTP_PROXY لترحيل طلبات Vouch Proxy IdP من خلال خادم وكيل صادر

  • الوكيل العكسي لخدمات Google Cloud Run

  • تمكين TLS الأصلي في Vouch Proxy

  • دعم فري بي إس دي

  • بدء تشغيل systemd لـ Vouch Proxy

  • استخدام Node.js بدلاً من Nginx لتوجيه الطلبات

  • تطوير تطبيق صفحة واحدة (SPA) أثناء استهلاك واجهة برمجة التطبيقات المحمية بواسطة VP

  • قم بدمج Vouch Proxy في تطبيق من جانب الخادم لـ User Authn وAuthz

  • قم بالتصفية حسب عنوان IP قبل التحقق من صحة VP باستخدام satisfy any;

يرجى مساعدتنا في توسيع هذه القائمة.

النطاقات والمطالبات

باستخدام Vouch Proxy، يمكنك طلب scopes مختلفة (قياسية ومخصصة) للحصول على مزيد من المعلومات حول المستخدم أو الوصول إلى واجهات برمجة التطبيقات الخاصة بالموفر. داخليًا، يقوم Vouch Proxy بإطلاق طلبات إلى user_info_url بعد المصادقة الناجحة. يتم استخراج claims المطلوبة من استجابة الموفر وتخزينها في ملف تعريف الارتباط VP.

️ ستتم إضافة مطالبات ورموز إضافية إلى ملف تعريف الارتباط VP ويمكن أن يصبح حجمه كبيرًا

قد يتم تقسيم ملف تعريف الارتباط VP إلى عدة ملفات تعريف ارتباط لتتوافق مع حدود حجم ملفات تعريف الارتباط للمتصفح. ولكن إذا كنت في حاجة إليها، كنت في حاجة إليها. تتطلب ملفات تعريف الارتباط والعناوين الكبيرة تكوين Nginx باستخدام مخازن مؤقتة أكبر. راجع Large_client_header_buffers وproxy_buffer_size لمزيد من المعلومات.

scopes الإعداد claims في Vouch Proxy باستخدام Nginx

  1. قم بتكوين Vouch Proxy لـ Nginx وIdP الخاص بك كالمعتاد (راجع: التثبيت والتكوين)

  2. قم بتعيين scope الضرورية في قسم oauth في vouch-proxy config.yml (مثال للتكوين)

    1. قم بتعيين idtoken: X-Vouch-IdP-IdToken في قسم headers في config.yml الخاص بـ vouch-proxy

    2. قم بتسجيل الدخول واستدعاء نقطة النهاية /validate في متصفح حديث

    3. تحقق من رأس الاستجابة لرأس X-Vouch-IdP-IdToken

    4. انسخ قيمة الرأس في مصحح الأخطاء على https://jwt.io/ وتأكد من أن المطالبات الضرورية جزء من jwt

    5. إذا لم تكن كذلك، فستحتاج إلى ضبط scopes في قسم oauth في config.yml أو إعادة تكوين موفر oauth الخاص بك

  3. قم بتعيين claims الضرورية في قسم header في vouch-proxy config.yml

    1. قم بتسجيل الدخول واستدعاء نقطة النهاية /validate في متصفح حديث

    2. تحقق من رؤوس الاستجابة لرؤوس النموذج X-Vouch-IdP-Claims-<ClaimName>

    3. إذا لم تكن هناك، فامسح ملفات تعريف الارتباط وبيانات المتصفح المخزنة مؤقتًا

    4. ؟ إذا لم تكن موجودة بعد ولكنها موجودة في jwt (خاصة المطالبات المخصصة) فقد يكون هناك خطأ

    5. قم بإزالة idtoken: X-Vouch-IdP-IdToken من قسم headers في config.yml الخاص بـ vouch-proxy إذا لم تكن بحاجة إليه

  4. استخدم auth_request_set بعد auth_request داخل الموقع المحمي في server.conf nginx.conf

  5. استهلك المطالبة (مثال لتكوين nginx)

يعمل من دوكر

 تشغيل عامل الميناء -د
     -ص 9090:9090
     --name vouch-proxy
     -v ${PWD}/config:/config
     quay.io/vouch/vouch-proxy

أو

 تشغيل عامل الميناء -د
     -ص 9090:9090
     --name vouch-proxy
     -e VOUCH_DOMAINS=yourdomain.com
     -e OAUTH_PROVIDER=google
     -e OAUTH_CLIENT_ID=1234
     -e OAUTH_CLIENT_SECRET=secretsecret
     -e OAUTH_CALLBACK_URL=https://vouch.yourdomain.com/auth
     quay.io/vouch/vouch-proxy

اعتبارًا من v0.36.0 يتم تشغيل عملية الإرساء في الحاوية vouch مستخدم مع UID 999 وGID 999. قد تحتاج إلى تعيين أذونات /config/config.yml و /config/secret لتتوافق مع إمكانية قراءتها بواسطة هذا المستخدم، أو استخدم docker run --user $UID:$GID ... أو ربما أنشئ حاوية عامل الإرساء من المصدر واستخدم ARGs المتاحة لـ UID وGID.

تتوفر إصدارات الحاوية التلقائية لكل إصدار Vouch Proxy من quay.io. كل إصدار ينتج ..

حاوية ثنائية بسيطة تم إنشاؤها من Dockerfile

  • quay.io/vouch/vouch-proxy:latest

  • quay.io/vouch/vouch-proxy:xyz مثل quay.io/vouch/vouch-proxy:0.28.0

حاوية قائمة على alpine مبنية من Dockerfile.alpine

  • quay.io/vouch/vouch-proxy:alpine-latest

  • quay.io/vouch/vouch-proxy:alpine-xyz

تتوفر صور arm Vouch Proxy على Docker Hub

  • voucher/vouch-proxy:latest-arm

دخول Kubernetes Nginx

إذا كنت تستخدم kubernetes مع nginx-ingress، فيمكنك تكوين الدخول الخاص بك باستخدام التعليقات التوضيحية التالية (لاحظ اقتباس التعليق التوضيحي auth-signin ):

    nginx.ingress.kubernetes.io/auth-signin: "https://vouch.yourdomain.com/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error=$ auth_resp_err"
    nginx.ingress.kubernetes.io/auth-url: https://vouch.yourdomain.com/validate
    nginx.ingress.kubernetes.io/auth-response-headers: X-Vouch-User
    nginx.ingress.kubernetes.io/auth-snippet: |      # يتم استخدام قيم الإرجاع هذه بواسطة استدعاء @error401
      auth_request_set $auth_resp_jwt $upstream_http_x_vouch_jwt;
      auth_request_set $auth_resp_err $upstream_http_x_vouch_err;
      auth_request_set $auth_resp_failcount $upstream_http_x_vouch_failcount;      # عند استضافة VP خارجيًا على k8s تأكد من صلاحية شهادة SSL لتجنب مخاطر MITM # proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;      # proxy_ssl_session_reuse on;      # proxy_ssl_verify_عمق 2;      # proxy_ssl_verify on;

تتم صيانة مخططات Helm بواسطة punkle وmartina-if وhalkeye وهي متاحة على https://github.com/vouch/helm-charts

التجميع من المصدر وتشغيل الملف الثنائي

  ./do.sh goget
  ./do.sh بناء
  ./vouch-proxy

اعتبارًا من v0.29.0 تم دمج جميع القوالب والأصول الثابتة والإعدادات الافتراضية للتكوين في .defaults.yml في الملف الثنائي الثابت باستخدام توجيهات go:embed.

/ تسجيل الدخول و / تسجيل الخروج إعادة توجيه نقطة النهاية

اعتبارًا من v0.11.0 تم إجراء فحوصات إضافية لتقليل سطح الهجوم لإعادة توجيه عنوان URL.

/تسجيل الدخول?url=POST_LOGIN_URL

عنوان URL الذي تم تمريره...

  • يجب أن يبدأ إما بـ http أو https

  • يجب أن يكون هناك مجال متداخل مع أي مجال في قائمة vouch.domains أو vouch.cookie.domain (إذا تم تكوين أي منهما)

  • لا يمكن أن تحتوي على معلمة تتضمن عنوان URL لمنع هجمات تسلسل عناوين URL

/تسجيل الخروج?url=NEXT_URL

تقبل نقطة نهاية Vouch Proxy /logout معلمة url في سلسلة الاستعلام والتي يمكن استخدامها لإعادة توجيه المستخدم 302 إلى نقطة revocation_endpoint الخاصة بموفر OAuth الأصلي/IDP/OIDC

    https://vouch.oursites.com/logout?url=https://oauth2.googleapis.com/revoc

يجب أن يكون عنوان url هذا موجودًا في ملف التكوين الموجود في القائمة vouch.post_logout_redirect_uris

 # لمنع هجمات إعادة التوجيه، يجب تحديد جميع عناوين URL المعاد توجيهها إلى /logout# ويجب تمرير عنوان URL إلى Vouch Proxy كـ https://vouch.yourdomain.com/logout?url=${ONE OF THE URLS BELOW}post_logout_redirect_uris : # صفحة تسجيل الدخول للتطبيقات الخاصة بك
  - https://yourdomain.com/login # تسجيل خروج IdPs الخاص بك enpoint # من https://accounts.google.com/.well-known/openid-configuration
  - https://oauth2.googleapis.com/revoc # قد تكون متصلاً بمعرف الهوية (IdP) الخاص بك
  - https://myorg.okta.com/oauth2/123serverid/v1/logout?post_logout_redirect_uri=http://myapp.yourdomain.com/login

لاحظ أنه من المحتمل أن يحمل موفِّر الهوية (IdP) الخاص بك قائمة post_logout_redirect_uri المنفصلة الخاصة به.

موارد الخروج ..

  • جوجل

  • اوكتا

  • مصادقة0

استكشاف الأخطاء وإصلاحها وطلبات الدعم والميزات (اقرأ هذا قبل إرسال مشكلة على GitHub)

قد يكون الحصول على النجوم للمحاذاة بين Nginx وVouch Proxy وIdP أمرًا صعبًا. نريد مساعدتك على النهوض والتشغيل في أسرع وقت ممكن. المشكلة الأكثر شيوعاً هي ..

أحصل على حلقة إعادة توجيه لا نهائية تعيدني إلى IdP الخاص بي (Google/Okta/GitHub/...)

تأكد من تشغيل Vouch Proxy وتطبيقاتك على مجال مشترك يمكنه مشاركة ملفات تعريف الارتباط. على سبيل المثال، يمكن لـ vouch.yourdomain.com و app.yourdomain.com مشاركة ملفات تعريف الارتباط على النطاق .yourdomain.com . (لن ينجح الأمر إذا كنت تحاول استخدام vouch.yourdomain.org و app.yourdomain.net .)

قد تحتاج إلى تحديد المجال الذي يجب تعيين ملف تعريف الارتباط عليه بشكل صريح. يمكنك القيام بذلك في ملف التكوين عن طريق تحديد الخيار:

 vouch: cookie: # فرض مجال ملف تعريف الارتباط لتعيين المجال: yourdomain.com

إذا كنت لا تزال تواجه مشكلة، فجرّب ما يلي:

  • قم بتشغيل vouch.testing: true . سيؤدي هذا إلى إبطاء الحلقة.

  • قم بتعيين vouch.logLevel: debug .

  • يجب أن تتم محاذاة رأس Host: في طلب http و oauth.callback_url و vouch.domains التي تم تكوينها بحيث يمكن وضع ملف تعريف الارتباط الذي يحمل JWT بشكل صحيح في المتصفح ثم إعادته عند كل طلب

  • فهو يساعد على التفكير مثل ملف تعريف الارتباط .

    • يتم تعيين ملف تعريف الارتباط في المجال. إذا كان لديك siteA.yourdomain.com و siteB.yourdomain.com محميين بواسطة Vouch Proxy، فأنت تريد تعيين ملف تعريف الارتباط Vouch Proxy على .yourdomain.com

    • إذا قمت بالمصادقة على vouch.yourdomain.com فلن يتمكن dev.anythingelse.com من رؤية ملف تعريف الارتباط

    • إلا إذا كنت تستخدم https، فيجب عليك تعيين vouch.cookie.secure: false

    • ملفات تعريف الارتباط متاحة لجميع منافذ المجال

  • يرجى الاطلاع على المشكلات التي تم إغلاقها والتي تشير إلى إعادة التوجيه

حسنًا، لقد ألقيت نظرة على المشكلات وجربت بعض الأشياء باستخدام التكوينات الخاصة بي ولكنها ما زالت لا تعمل

يرجى تقديم قضية جديدة على النحو التالي..

تلدر:

  • تعيين vouch.testing: true

  • قم بتعيين vouch.logLevel: debug

  • قم بإجراء رحلتين كاملتين ذهابًا وإيابًا لـ ./vouch-proxy لالتقاط المخرجات..

    • بدء تشغيل نائب الرئيس

    • /validate

    • /login - حتى لو كان الخطأ هنا

    • /auth

    • /validate - التقاط كل شيء

  • ضع كل سجلاتك وتكويناتك في gist .

  • ./do.sh bug_report هو صديقك

لكن اقرأ هذا على أي حال لأننا سنطلب منك قراءته إذا لم تتبع هذه التعليمات. :)

  • قم بتشغيل vouch.testing: true وقم بتعيين vouch.logLevel: debug .

  • استخدم Gist أو خدمة لصق أخرى مثل hasteb.in. لا تضع سجلاتك وتهيئها في مشكلة GITHUB . يعد استخدام خدمة اللصق أمرًا مهمًا لأنها ستحافظ على التباعد وستوفر أرقام الأسطر والتنسيق. نحن نبحث عن الإبر في أكوام القش من خلال إعدادات تحتوي على عدة أجزاء متحركة، وهذه الميزات تساعد بشكل كبير. خدمات اللصق توفر وقتك ووقتنا وتساعدنا على مساعدتك بسرعة. من المرجح أن تحصل على دعم جيد منا في الوقت المناسب باتباع هذه النصيحة.

  • قم بتشغيل ./do.sh bug_report secretdomain.com secretpass [anothersecret..] والذي سيؤدي إلى إنشاء نسخة منقحة من التكوين الخاص بك وسجلات إزالة كل من هذه السلاسل

    • واتبع التعليمات الموجودة في النهاية لتنقيح تكوين Nginx الخاص بك

  • كل هؤلاء يدخلون في الجوهر

  • ثم افتح إصدارًا جديدًا في هذا المستودع

يمكن إنشاء تقرير خطأ من بيئة عامل إرساء باستخدام quay.io/vouch/vouch-proxy:alpine image... 

docker run --name vouch_proxy -v $PWD/config:/config -v $PWD/certs:/certs -it --rm --entrypoint /do.sh quay.io/vouch/vouch-proxy:alpine bug_report yourdomain.com anotherdomain.com someothersecret

المساهمة

نحن نحب أن يكون لك المساهمة! يرجى الرجوع إلى إرشادات المساهمة لدينا للحصول على التفاصيل.

التفويض المتقدم باستخدام OpenResty

OpenResty® عبارة عن منصة ويب متكاملة تدمج نواة Nginx القياسية، LuaJIT، والعديد من مكتبات Lua المكتوبة بعناية، والكثير من وحدات Nginx عالية الجودة التابعة لجهات خارجية، ومعظم تبعياتها الخارجية.

يمكنك استبدال nginx بـ OpenResty بسهولة إلى حد ما.

باستخدام OpenResty وLua، من الممكن تقديم تفويض مخصص ومتقدم لأي عنوان أو سند مطالبات يتم تمريره.

يتوفر OpenResty والتكوينات لمجموعة متنوعة من السيناريوهات في دليل الأمثلة.

تدفق تسجيل الدخول والمصادقة باستخدام Google Oauth

  • يزور بوب https://private.oursites.com

  • الوكيل العكسي Nginx...

    • إذا /validate الإرجاعات ...

    • قم بالرد على بوب بإعادة التوجيه 302 إلى https://vouch.oursites.com/login?url=https://private.oursites.com

    • 200 حسنًا، ثم يسمح النجاح لبوب بالمرور

    • 401 غير مصرح به إذن

    • يتلقى طلب Private.oursites.com من بوب

    • يستخدم وحدة auth_request التي تم تكوينها للمسار /validate

    • تم تكوين /validate لطلبات proxy_pass إلى خدمة المصادقة على https://vouch.oursites.com/validate

  • وكيل القسيمة https://vouch.oursites.com/validate

    • إرجاع 401 NotAuthorized إلى Nginx (الذي يعيد توجيه الطلب لتسجيل الدخول)

    • يُرجع 200 OK إلى Nginx، مما سيسمح بالوصول (لم يلاحظ بوب شيئًا)

    • يتلقى طلب Private.oursites.com من بوب عبر Nginx proxy_pass

    • يبحث عن ملف تعريف الارتباط المسمى "oursitesSSO" الذي يحتوي على JWT

    • إذا تم العثور على ملف تعريف الارتباط، وكان JWT صالحًا

    • إذا لم يتم العثور على ملف تعريف الارتباط، أو أن JWT غير صالح

  • تتم إعادة توجيه بوب أولاً لفترة وجيزة إلى https://vouch.oursites.com/login?url=https://private.oursites.com

    • يقوم بمسح ملف تعريف الارتباط المسمى "oursitesSSO" إذا كان موجودًا

    • ينشئ nonce ويخزنه في متغير الجلسة STATE $

    • يخزن عنوان URL https://private.oursites.com من سلسلة الاستعلام في متغير الجلسة $requestedURL

    • الرد على Bob من خلال إعادة التوجيه 302 إلى نموذج تسجيل الدخول OAuth الخاص بـ Google، بما في ذلك $STATE nonce

  • يقوم بوب بتسجيل الدخول إلى حساب Google الخاص به باستخدام Oauth

    • بعد تسجيل الدخول الناجح

    • تستجيب Google لبوب بإعادة التوجيه 302 إلى https://vouch.oursites.com/auth?state=$STATE

  • تتم إعادة توجيه بوب إلى https://vouch.oursites.com/auth?state=$STATE

    • قم بإصدار JWT في شكل ملف تعريف ارتباط باسم "oursitesSSO"

    • استرداد متغير الجلسة $requestedURL وإعادة توجيه 302 مرة أخرى إلى https://private.oursites.com

    • إذا كان $STATE nonce من عنوان url يطابق متغير الجلسة "state"

    • تقديم طلب "الطرف الثالث" من Google (خادم إلى خادم) لتبادل رمز OAuth لمعلومات مستخدم Bob بما في ذلك عنوان البريد الإلكتروني [email protected]

    • إذا كان عنوان البريد الإلكتروني يطابق النطاقoursites.com (فهو كذلك)

لاحظ أنه باستثناء بعض عمليات إعادة التوجيه غير الضارة، يرى بوب فقط https://private.oursites.com وشاشة تسجيل الدخول إلى Google في متصفحه. على الرغم من أن Vouch يتفاعل مع متصفح Bob عدة مرات، إلا أن ذلك يهدف فقط إلى تعيين ملفات تعريف الارتباط، وإذا كانت عمليات إعادة التوجيه 302 تعمل بشكل صحيح، فسوف يقوم Bob بتسجيل الدخول بسرعة.

بمجرد تعيين JWT، سيتم السماح لـ Bob بجميع المواقع الأخرى التي تم تكوينها لاستخدام https://vouch.oursites.com/validate من وحدة auth_request Nginx.

في المرة التالية التي تتم فيها إعادة توجيه Bob إلى Google لتسجيل الدخول، نظرًا لأنه قد سمح بالفعل بتطبيق Vouch Proxy OAuth، تقوم Google بإعادة توجيهه على الفور وتعيين ملف تعريف الارتباط وإرساله في طريقه المرح. في بعض المتصفحات مثل Chrome، قد لا يلاحظ بوب أنه قام بتسجيل الدخول باستخدام Vouch Proxy.

يوسع
معلومات إضافية
تطبيقات ذات صلة
نوصي لك
أخبار ذات صلة الكل