هل يسجّل VPN SSO دخول المستخدمين إلى التطبيقات الداخلية تلقائيًا؟

بوابة VPN التي تتحقق من الهوية عبر مزوّد هوية تثبت أمرًا واحدًا: أن المزوّد ضمن المستخدم أمام البوابة. وهي لا تمنح ذلك المستخدم بيانات اعتماد لويكي الشبكة الداخلية أو لوحة المراقبة أو خادم البناء. فهذه الخدمات تسجّل دخول الأشخاص عبر اتحادها الخاص وتطبّق تفويضها الخاص، ولا يقرّر النفق إلا أي الحزم يمكنها الوصول إليها.

ثلاث جلسات، ثلاثة قرارات منفصلة

أبقِ الحالات منفصلة، لأن كل واحدة تنتهي وفق جدولها الخاص. جلسة VPN هي قبول البوابة لهوية ما، إضافة إلى الوصول الشبكي الذي منحته. جلسة المتصفح لدى مزوّد الهوية هي ما يحتفظ به المتصفح لذلك المزوّد وقد يعيد استخدامه وفق سياسته. أما جلسة التطبيق فتخص خدمة واحدة تحقّقت من استجابة موجّهة إليها.

الخلط بين هذه الحالات ينتج السؤال الخاطئ، الذي يُصاغ عادةً كسؤال عن سبب عدم تسجيل النفق دخول المستخدم في كل مكان. أعد صياغته: أي تطبيق لا يملك قيد اتحاد، وأي تطبيق يرفض المستخدم، وأي تطبيق تنقصه مسار. مطالبة تسجيل دخول واحدة تفتح تطبيق الشبكة الداخلية قد ترتد رغم ذلك إلى المزوّد، لأن إعادة التوجيه الثانية طلب تفويض جديد لجمهور مختلف.

اربط البوابة كتطبيق خاص بها

سجّل VPN كتطبيق معتمد لدى المزوّد، بمعرّفه الخاص وعنوان URI لإعادة التوجيه وتعيين المستخدمين. ثم قرّر أي تفويضات شبكية يمنحها ذلك الدخول، لأن هذا سياسة VPN وليس ميزة في المزوّد. المستخدمون الذين يجب أن يصلوا إلى شبكة المراقبة الفرعية فقط يحصلون على سياسة بوابة مختلفة، لا على كلمة مرور مختلفة.

استجابة المصادقة الخاصة بالنفق ليست بيانات اعتماد قابلة لإعادة الاستخدام. فحاملات هوية OIDC تتضمن مطالبة جمهور تسمّي العميل الذي صُدرت من أجله، وتقيّد تأكيدات SAML الحاملة الجمهورَ بمزوّد الخدمة المتلقي. والخدمة الثانية التي تقبل استجابة الخدمة الأولى تكون مهيأة بشكل خاطئ، ونسخ رمز إلى تطبيق آخر ليس تكاملًا.

سجّل كل تطبيق داخلي، ثم اضبط سياق المتصفح

تحتاج كل خدمة إلى قيم SAML أو OIDC المدعومة: المصدر، ومعرّف العميل، وعنوان URL للاستدعاء الراجع أو لمستهلك التأكيد، والمطالبات المطلوبة والتعيين. وتأتي قابلية الوصول فوق ذلك، لأن فحوص الهوية لا توفّر أبدًا مسارًا ولا إجابة DNS.

1. أنشئ قيد التطبيق وتأكّد من أن معرّف الكيان أو العميل يطابق ما يرسله التطبيق.
2. سجّل عنوان URL الدقيق للاستدعاء الراجع بما في ذلك المخطط والمنفذ؛ فالخطأ الطفيف يفشل بعد مصادقة المستخدم.
3. عيّن المستخدمين أو المجموعات، ثم تأكّد من إطلاق المطالبات المطلوبة.
4. اسمح بنقاط نهاية مزوّد الهوية إلى جانب التطبيق الخاص، وإلا فلن تكتمل إعادة التوجيه.

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

شغّل التدفق واقرأ أين يتوقف

أعد إنتاج المشكلة باستخدام لوحة الشبكة في المتصفح وراقب سلسلة إعادة التوجيه. المرور المفيد يتبع خطوة واحدة في كل مرة: من البوابة إلى المزوّد، ومن المزوّد عائدًا إلى التطبيق برمز أو تأكيد، ومن التطبيق إلى نقطة نهاية الرمز لدى المزوّد، ثم إصدار جلسة التطبيق. والخطوة التي تتوقف عندها السلسلة تسمّي المكوّن الذي يجب إصلاحه.

فحصان من سطر الأوامر يحسمان الشكوك المعتادة، وكلاهما آمن للتنفيذ من مضيف إداري:

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

عندما تسرد البيانات الوصفية نقاط نهاية لم تسجّلها قط، يكون التطبيق يشير إلى مستأجر أو مصدر مختلف. وعندما يُجيب أول طلب إلى التطبيق بالرمز 302 نحو مضيف غير متوقّع، فإن تكوين الاتحاد في التطبيق هو موضع البحث، لا ملف تعريف VPN.

أصلح المطالبات بالعثور على من طلبها

مطالبة كلمة المرور الثانية ليست عيبًا تلقائيًا. فقد يطلب التطبيق مستوى تأكيد أعلى، أو قد يفرض المزوّد حدًّا أقصى لعمر الجلسة وتحديًا جديدًا. إن إزالة تلك المتطلبات لجعل التدفق أهدأ تضعف ضابطًا مقصودًا، لذا تحقّق من المكوّن الذي طلبها قبل تغيير السياسة.

ثم قرّر ما يجب تحسينه. إذا جاءت المطالبة من التطبيق، فأصلح قيد الاتحاد الخاص به. وإذا جاءت من المزوّد بحكم السياسة، فوثّق المتطلب. وإذا كان التطبيق غير قابل للوصول بعد تسجيل دخول ناجح، فمسار النفق هو المشتبه به، لأن الهوية وتوصيل الحزم يفشلان في مواضع مختلفة ويبدوان متشابهين من مقعد المستخدم.