فیڈریٹڈ VPN لاگ اِن کے براؤزر مرحلے میں کیا ہوتا ہے

آپ Connect دباتے ہیں، اور پاس ورڈ باکس کے بجائے VPN کلائنٹ آپ کا براؤزر کھول دیتا ہے۔ یہ حوالگی اُن لوگوں کو الجھن میں ڈالتی ہے جو توقع رکھتے ہیں کہ ٹنل خود تصدیق کرے گا۔ براؤزر کوئی چکر نہیں: شناختی فراہم کنندہ اصل میں وہیں شخص کی تصدیق کرتا ہے، اور کلائنٹ صرف نتیجے کا انتظار کر رہا ہوتا ہے۔

ایک سائن اِن کو شروع سے آخر تک چلانا دکھاتا ہے کہ ہر ناکامی کا تعلق کہاں ہے، اور زیادہ تر رن بکس اسی حصے کو چھوڑ دیتے ہیں۔

گیٹ وے کنفیگ سے نہیں، کلائنٹ سے شروع کریں

کلائنٹ ایک درخواست بناتا ہے اور براؤزر کو شناختی فراہم کنندہ کے پاس بھیجتا ہے سروس پرووائیڈر شناخت اور واپسی کے مقام کے ساتھ۔ پھر آپ کی تنظیم کا IdP وہی چلاتا ہے جو اُس کے لیے کنفیگر ہے: پاس ورڈ، MFA، ڈیوائس چیک، مشروط رسائی۔ اگر براؤزر کے پاس پہلے سے درست سیشن ہو تو نظر آنے والا حصہ ایک یا دو سیکنڈ لے سکتا ہے۔ یہ اختصار سیشن کا دوبارہ استعمال ہے، چھوڑا گیا چیک نہیں۔

ہر چیز سے پہلے کلائنٹ کی فیڈریشن کنفیگ میں دو قدریں پڑھیں: وہ IdP میٹاڈیٹا یا URL جس پر یہ بھروسا کرتا ہے، اور وہ کال بیک پتہ جس کی توقع رکھتا ہے۔ وہاں عدم مطابقت ہو تو کوئی پاس ورڈ لکھے جانے سے پہلے ہی ناکام ہو جاتا ہے۔

شناختی فراہم کنندہ کو کیا واپس کرنا چاہیے

IdP ایک دستخط شدہ SAML جواب دیتا ہے جس میں assertion ہوتا ہے: موضوع کون ہے، کس نے جاری کیا، کس کے لیے ہے، اور کتنی دیر درست رہتا ہے۔ وہی فیلڈز معاہدہ ہیں۔ Issuer، audience، recipient اور درستگی کی مدت سبھی کو سروس کی توقع سے میل کھانا چاہیے۔

درست IdP کا دستخط شدہ لیکن مختلف audience سے مخاطب جواب پھر بھی غلط ہے۔ لیب اور پروڈکشن کے درمیان میٹاڈیٹا کاپی کرتے وقت لوگ یہی چیک چھوڑتے ہیں۔

VPN سروس آپ پر بھروسا کرنے سے پہلے کیا جانچتی ہے

سروس قابلِ بھروسا سرٹیفکیٹ کے خلاف دستخط کی تصدیق کرتی ہے، issuer، audience اور recipient جانچتی ہے، پھر وقت کی شرائط کا جائزہ لیتی ہے۔ اسی کے بعد ہی یہ assertion کو صارف یا گروپ پر نقش کرتی ہے اور VPN اجازت کی پالیسی لاگو کرتی ہے۔ یہاں تصدیق اور اجازت الگ مراحل ہیں، اور میل کھاتے گروپ کے بغیر درست assertion ایسا سیشن بناتا ہے جو جڑتا ہے مگر کہیں نہیں پہنچتا۔

Assertion تصدیق کا مواد ہے، پاس ورڈ نہیں۔ اسے کسی دوسرے کلائنٹ میں چپکانا، یا بعد میں دوبارہ جڑنے کے لیے رکھنا، معاون لاگ اِن نہیں ہے۔

دو عمریں جو الگ الگ ختم ہوتی ہیں

IdP پر براؤزر سیشن اور گیٹ وے پر VPN سیشن مختلف گھڑیوں پر ختم ہوتے ہیں۔ IdP سے سائن آؤٹ کرنا قائم شدہ ٹنل کو لازماً ختم نہیں کرتا، اور ٹنل منقطع کرنا آپ کو براؤزر سے سائن آؤٹ نہیں کرتا۔

AWS Client VPN دستاویز کرتا ہے کہ اس کا فیڈریٹڈ بہاؤ SAML single logout کی حمایت نہیں کرتا، جو اس خلا کی ایک ٹھوس مثال ہے۔ ہم آہنگی فرض کرنے کے بجائے اپنی سروس جانچیں۔

اسی لیے دوبارہ جڑنا 09:00 اور 15:00 پر مختلف رویہ رکھتا ہے۔ یہ IdP سیشن خاموشی سے دوبارہ استعمال کر سکتا ہے، پھر MFA مانگ سکتا ہے، یا ناکام ہو سکتا ہے کیونکہ endpoint سیشن کی مدت ختم ہو گئی جبکہ براؤزر سیشن کی نہیں۔ AWS فیڈریشن ورک فلو اپنی کلائنٹ اور جواب کی شرائط بیان کرتا ہے، اور دیگر سروسز مختلف حوالگیاں استعمال کرتی ہیں۔

جب براؤزر مرحلہ ناکام ہو تو یہ ترتیب سے جانچیں

براؤزر سے باہر کی طرف کام کریں، کیونکہ خرابی کا پیغام عام طور پر پہلی کے بجائے آخری چھلانگ کا نام لیتا ہے۔

اگر صفحہ کبھی لوڈ نہ ہو تو کلائنٹ کا IdP URL یا اس تک راستہ غلط ہے۔ اگر IdP درخواست مسترد کرے تو سروس پرووائیڈر شناخت یا کال بیک اس کی کنفیگ سے میل نہیں کھاتا۔ اگر براؤزر کامیابی دکھائے اور کلائنٹ پھر بھی ناکام ہو تو جواب غلط جگہ پہنچا یا audience اور وقت کی تصدیق میں ناکام ہوا۔ اور اگر ٹنل بغیر رسائی کے اٹھے تو assertion قبول ہوا مگر گروپ میپنگ نہیں۔

متوقع صفحہ، کال بیک اور گروپ میپنگ ایک ہی دستاویز میں رکھیں۔ پھر خراب VPN لاگ اِن کی رپورٹ کرنے والا صارف بتا سکتا ہے کہ اُن چاروں میں سے کیا دیکھا، اور جواب آدھا لکھا ہوا ہوتا ہے۔