क्या VPN SSO उपयोगकर्ताओं को आंतरिक ऐप्स में अपने आप साइन इन कर देता है?
एक साइन-इन टनल और उसके पीछे के ऐप्स को कवर कर सकता है, लेकिन केवल तब जब हर ऐप का अपना भरोसा हो। इसे जोड़ने और जाँचने का क्रम यह है।
पहचान प्रदाता के ज़रिये प्रमाणीकरण करने वाला VPN गेटवे केवल एक बात सिद्ध करता है: प्रदाता ने गेटवे के सामने किसी उपयोगकर्ता की ज़मानत दी है। यह उस उपयोगकर्ता को इंट्रानेट विकी, मॉनिटरिंग डैशबोर्ड या बिल्ड सर्वर के लिए कोई क्रेडेंशियल नहीं देता। वे सेवाएँ लोगों को अपने फ़ेडरेशन से साइन इन कराती हैं और अपना प्राधिकरण लागू करती हैं, और टनल केवल यह तय करता है कि कौन-से पैकेट उन तक पहुँच सकते हैं।
तीन सत्र, तीन अलग निर्णय
स्थितियों को अलग रखें, क्योंकि हर एक अपने समय-चक्र पर समाप्त होती है। VPN सत्र गेटवे द्वारा पहचान की स्वीकृति और उसके द्वारा दिया गया नेटवर्क एक्सेस है। पहचान प्रदाता का ब्राउज़र सत्र वह है जो ब्राउज़र उस प्रदाता के लिए अब भी रखता है और अपनी नीति के तहत दोबारा उपयोग कर सकता है। ऐप सत्र उस एक सेवा का है जिसने अपने पास भेजी गई प्रतिक्रिया को सत्यापित किया है।
इन स्थितियों को मिलाने से गलत सवाल बनता है, आम तौर पर यह कहकर कि टनल उपयोगकर्ता को हर जगह साइन इन क्यों नहीं करता। इसे दोबारा लिखें: किस ऐप में फ़ेडरेशन प्रविष्टि नहीं है, कौन उपयोगकर्ता को अस्वीकार करता है, और किसमें मार्ग नहीं है। इंट्रानेट ऐप खोलने वाला एक ही साइन-इन संकेत फिर भी प्रदाता की ओर लौट सकता है, क्योंकि दूसरा रीडायरेक्ट अलग दर्शकों के लिए नया प्राधिकरण अनुरोध है।
गेटवे को उसके अपने ऐप के रूप में जोड़ें
VPN को प्रदाता में स्वीकृत ऐप के रूप में पंजीकृत करें, उसके अपने पहचानकर्ता, रीडायरेक्ट URI और उपयोगकर्ता आवंटन के साथ। फिर तय करें कि वह लॉगिन कौन-से नेटवर्क प्राधिकरण देता है, क्योंकि यह VPN नीति है, प्रदाता की सुविधा नहीं। जिन्हें केवल मॉनिटरिंग सबनेट तक पहुँचना चाहिए, उन्हें अलग गेटवे नीति मिलती है, अलग पासवर्ड नहीं।
टनल की प्रमाणीकरण प्रतिक्रिया दोबारा उपयोग योग्य क्रेडेंशियल नहीं है। OIDC ID टोकन में दर्शक दावा होता है जो उस क्लाइंट का नाम बताता है जिसके लिए वे जारी हुए, और SAML बियरर अभिकथन दर्शक को प्राप्तकर्ता सेवा प्रदाता तक सीमित करते हैं। पहली सेवा की प्रतिक्रिया स्वीकार करने वाली दूसरी सेवा गलत कॉन्फ़िगर है, और टोकन को दूसरे ऐप में कॉपी करना एकीकरण नहीं है।
हर आंतरिक ऐप पंजीकृत करें, फिर ब्राउज़र संदर्भ सेट करें
हर सेवा को समर्थित SAML या OIDC मान चाहिए: जारीकर्ता, क्लाइंट पहचानकर्ता, कॉलबैक या अभिकथन-उपभोक्ता URL, आवश्यक दावे और आवंटन। पहुँच इसके ऊपर आती है, क्योंकि पहचान जाँच कभी मार्ग या DNS उत्तर नहीं देती।
- ऐप प्रविष्टि बनाएँ और पुष्टि करें कि एंटिटी या क्लाइंट ID वही है जो ऐप भेजता है।
- स्कीम और पोर्ट सहित सटीक कॉलबैक URL पंजीकृत करें; थोड़ी भी चूक उपयोगकर्ता के प्रमाणीकरण के बाद विफल हो जाती है।
- उपयोगकर्ताओं या समूहों को आवंटित करें, फिर पुष्टि करें कि आवश्यक दावे जारी होते हैं।
- निजी ऐप के साथ-साथ पहचान प्रदाता के एंडपॉइंट भी अनुमत करें, वरना रीडायरेक्ट पूरा नहीं हो सकता।
ब्राउज़र संदर्भ तय करता है कि मौजूदा प्रदाता सत्र दोबारा उपयोग होगा या नहीं। सिस्टम ब्राउज़र खोलने वाला नेटिव क्लाइंट वह स्थिति साझा कर सकता है, जबकि अपने कुकी जार वाला एम्बेडेड व्यू आम तौर पर नहीं कर सकता। नया ब्राउज़र, निजी विंडो और दूसरी प्रोफ़ाइल शून्य से शुरू होते हैं, जो अपेक्षित है, टूटा हुआ 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 प्रोफ़ाइल नहीं।
किसने माँगा यह जानकर संकेत ठीक करें
दूसरा पासवर्ड संकेत अपने आप कोई दोष नहीं है। ऐप ऊँचा आश्वासन स्तर माँग सकता है, या प्रदाता सत्र की अधिकतम आयु और नई चुनौती लागू कर सकता है. फ़्लो को शांत बनाने के लिए उन आवश्यकताओं को हटाना जानबूझकर रखे गए नियंत्रण को कमज़ोर करता है, इसलिए नीति बदलने से पहले तय करें कि किस घटक ने माँगा।
फिर तय करें कि क्या सुधारना है। अगर संकेत ऐप से आता है, तो उसकी फ़ेडरेशन प्रविष्टि ठीक करें। अगर नीति के अनुसार प्रदाता से आता है, तो आवश्यकता दर्ज करें। अगर सफल साइन-इन के बाद ऐप पहुँच से बाहर है, तो टनल का रूटिंग संदिग्ध है, क्योंकि पहचान और पैकेट वितरण अलग-अलग जगहों पर विफल होते हैं और उपयोगकर्ता की सीट से एक जैसे दिखते हैं।