کیا VPN SSO صارفین کو اندرونی ایپس میں خودکار طور پر سائن اِن کرتا ہے؟
ایک سائن اِن سرنگ اور اس کے پیچھے کی ایپس کو ڈھانپ سکتا ہے، لیکن صرف اُس وقت جب ہر ایپ کا اپنا اعتماد ہو۔ اسے جوڑنے اور جانچنے کی ترتیب یہ ہے۔
وہ VPN گیٹ وے جو شناختی فراہم کنندہ کے ذریعے تصدیق کرتا ہے صرف ایک بات ثابت کرتا ہے: فراہم کنندہ نے گیٹ وے کے سامنے ایک صارف کی ضمانت دی۔ یہ اُس صارف کو اندرونی نیٹ ورک کی ویکی، نگرانی کے ڈیش بورڈ یا build سرور کے لیے کوئی اسناد نہیں دیتا۔ وہ خدمات لوگوں کو اپنی فیڈریشن کے ذریعے سائن اِن کراتی ہیں اور اپنی اجازت لگاتی ہیں، اور سرنگ صرف یہ طے کرتی ہے کہ کون سے پیکٹ اُن تک پہنچ سکتے ہیں۔
تین سیشن، تین الگ فیصلے
حالتوں کو الگ رکھیں، کیونکہ ہر ایک اپنے شیڈول کے مطابق ختم ہوتی ہے۔ VPN سیشن گیٹ وے کی طرف سے شناخت کی قبولیت اور اُس کی دی گئی نیٹ ورک رسائی ہے۔ شناختی فراہم کنندہ کے پاس براؤزر سیشن وہ ہے جو براؤزر اُس فراہم کنندہ کے لیے ابھی تک رکھتا ہے اور اُس کی پالیسی کے مطابق دوبارہ استعمال کر سکتا ہے۔ ایپ سیشن اُس ایک خدمت کا ہے جس نے اپنی طرف بھیجے گئے جواب کی توثیق کی۔
ان حالتوں کو ملانا غلط سوال پیدا کرتا ہے، عام طور پر یہ پوچھا جاتا ہے کہ سرنگ صارف کو ہر جگہ سائن اِن کیوں نہیں کرتی۔ اسے دوبارہ لکھیں: کس ایپ کے پاس فیڈریشن اندراج نہیں، کون صارف کو مسترد کرتی ہے، اور کس میں راستہ نہیں۔ اندرونی نیٹ ورک کی ایپ کھولنے والی ایک ہی سائن اِن درخواست پھر بھی فراہم کنندہ کی طرف واپس جا سکتی ہے، کیونکہ دوسرا ری ڈائریکٹ مختلف سامعین کے لیے نئی اجازت کی درخواست ہے۔
گیٹ وے کو اپنی الگ ایپ کے طور پر جوڑیں
VPN کو فراہم کنندہ میں منظور شدہ ایپ کے طور پر رجسٹر کریں، اُس کے اپنے شناخت کنندہ، ری ڈائریکٹ URI اور صارف تفویض کے ساتھ۔ پھر طے کریں کہ وہ سائن اِن کون سی نیٹ ورک اجازتیں دیتا ہے، کیونکہ یہ VPN پالیسی ہے، فراہم کنندہ کی خصوصیت نہیں۔ جن صارفین کو صرف نگرانی کے ذیلی نیٹ ورک تک پہنچنا چاہیے اُنہیں مختلف گیٹ وے پالیسی ملتی ہے، مختلف پاس ورڈ نہیں۔
سرنگ کا تصدیقی جواب دوبارہ استعمال ہونے والی اسناد نہیں ہے۔ OIDC ID ٹوکن میں سامعین کا دعویٰ ہوتا ہے جو اُس کلائنٹ کا نام لیتا ہے جس کے لیے وہ جاری ہوئے، اور SAML bearer بیانات سامعین کو وصول کرنے والے سروس فراہم کنندہ تک محدود کرتے ہیں۔ پہلی خدمت کا جواب قبول کرنے والی دوسری خدمت غلط ترتیب دی گئی ہے، اور ٹوکن کو دوسری ایپ میں نقل کرنا انضمام نہیں۔
ہر اندرونی ایپ رجسٹر کریں، پھر براؤزر کا سیاق مقرر کریں
ہر خدمت کو معاون SAML یا OIDC اقدار درکار ہیں: جاری کنندہ، کلائنٹ شناخت کنندہ، کال بیک یا دعویٰ صارف کا URL، مطلوبہ دعوے اور تفویض۔ رسائی اُس کے اوپر آتی ہے، کیونکہ شناخت کی جانچ کبھی راستہ یا DNS جواب فراہم نہیں کرتی۔
- ایپ اندراج بنائیں اور تصدیق کریں کہ entity یا کلائنٹ ID اُس سے مطابقت رکھتی ہے جو ایپ بھیجتی ہے۔
- اسکیم اور پورٹ سمیت درست کال بیک URL رجسٹر کریں؛ معمولی غلطی صارف کی تصدیق کے بعد ناکام ہوتی ہے۔
- صارفین یا گروہ تفویض کریں، پھر تصدیق کریں کہ مطلوبہ دعوے جاری ہوتے ہیں۔
- نجی ایپ کے ساتھ ساتھ شناختی فراہم کنندہ کے endpoints کو بھی اجازت دیں، ورنہ ری ڈائریکٹ مکمل نہیں ہو سکتا۔
براؤزر کا سیاق طے کرتا ہے کہ موجودہ فراہم کنندہ سیشن دوبارہ استعمال ہوگا یا نہیں۔ سسٹم براؤزر کھولنے والا مقامی کلائنٹ وہ حالت شیئر کر سکتا ہے، جبکہ اپنے کوکی جار والا ایمبیڈڈ منظر عام طور پر نہیں کر سکتا۔ نیا براؤزر، نجی ونڈوز اور دوسرا پروفائل سب صفر سے شروع ہوتے ہیں، جو متوقع ہے، خراب SSO ترتیب نہیں۔
بہاؤ چلائیں اور پڑھیں کہ کہاں رکتا ہے
براؤزر کے نیٹ ورک پینل سے دوبارہ پیدا کریں اور ری ڈائریکٹ زنجیر دیکھیں۔ مفید سفر ایک وقت میں ایک چھلانگ کی پیروی کرتا ہے: گیٹ وے سے فراہم کنندہ تک، فراہم کنندہ سے کوڈ یا بیان کے ساتھ ایپ تک، ایپ سے فراہم کنندہ کے ٹوکن endpoint تک، ایپ سیشن جاری ہوتا ہے۔ جہاں زنجیر رکتی ہے وہ چھلانگ درست کرنے والے جزو کا نام دیتی ہے۔
کمانڈ لائن کی دو جانچیں عام شبہات دور کرتی ہیں، اور دونوں کو ایڈمن ہوسٹ سے چلانا محفوظ ہے:
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:)'جب میٹا ڈیٹا ایسے endpoints کی فہرست دیتا ہے جو آپ نے کبھی رجسٹر نہیں کیے، تو ایپ کسی دوسرے کرایہ دار یا جاری کنندہ کی طرف اشارہ کر رہی ہے۔ جب ایپ کو پہلی درخواست غیر متوقع ہوسٹ کو 302 جواب دیتی ہے، تو دیکھنے کی جگہ ایپ کی فیڈریشن ترتیب ہے، VPN پروفائل نہیں۔
کس نے مانگا یہ معلوم کر کے درخواستیں درست کریں
دوسری پاس ورڈ درخواست خودبخود نقص نہیں۔ ایپ زیادہ اعتماد کی سطح مانگ سکتی ہے، یا فراہم کنندہ زیادہ سے زیادہ سیشن عمر اور نیا چیلنج نافذ کر سکتا ہے. بہاؤ کو خاموش کرنے کے لیے وہ تقاضے ہٹانا جان بوجھ کر رکھے گئے کنٹرول کو کمزور کرتا ہے، اس لیے پالیسی بدلنے سے پہلے طے کریں کہ کس جزو نے مانگا۔
پھر طے کریں کہ کیا بہتر کرنا ہے۔ اگر درخواست ایپ کی طرف سے آتی ہے تو اُس کا فیڈریشن اندراج درست کریں۔ اگر پالیسی کے مطابق فراہم کنندہ کی طرف سے آتی ہے تو تقاضہ دستاویز کریں۔ اگر کامیاب سائن اِن کے بعد ایپ قابل رسائی نہیں، تو سرنگ کی روٹنگ مشتبہ ہے، کیونکہ شناخت اور پیکٹ کی ترسیل مختلف جگہوں پر ناکام ہوتی ہیں اور صارف کی نشست سے ایک جیسی لگتی ہیں۔