फ़ेडरेटेड VPN लॉगिन के ब्राउज़र चरण में क्या होता है

आप Connect दबाते हैं और पासवर्ड बॉक्स की जगह VPN क्लाइंट आपका ब्राउज़र खोल देता है। यह हैंडऑफ़ उन लोगों को भ्रमित करता है जो सोचते हैं कि टनल खुद प्रमाणित होगा। ब्राउज़र कोई चक्कर नहीं है: वहीं पहचान प्रदाता व्यक्ति को वास्तव में प्रमाणित करता है, और क्लाइंट केवल परिणाम की प्रतीक्षा करता है।

एक साइन-इन को शुरू से अंत तक देखने पर पता चलता है कि हर विफलता किस चरण की है, और यही वह हिस्सा है जिसे ज़्यादातर रनबुक छोड़ देते हैं।

गेटवे कॉन्फ़िग से नहीं, क्लाइंट से शुरू करें

क्लाइंट एक अनुरोध बनाता है और सेवा-प्रदाता पहचानकर्ता तथा वापसी स्थान के साथ ब्राउज़र को पहचान प्रदाता के पास भेजता है। फिर आपके संगठन का IdP वह चलाता है जो कॉन्फ़िगर है: पासवर्ड, MFA, डिवाइस जाँच, सशर्त पहुँच। अगर ब्राउज़र के पास पहले से वैध सत्र है, तो दिखने वाला हिस्सा एक-दो सेकंड ले सकता है। यह संक्षिप्तता सत्र का पुन:उपयोग है, छोड़ी गई जाँच नहीं।

बाकी सब से पहले क्लाइंट के फ़ेडरेशन कॉन्फ़िग में दो मान पढ़ें: जिस IdP मेटाडेटा या URL पर वह भरोसा करता है, और जिस कॉलबैक पते की उसे अपेक्षा है। वहाँ असंगति किसी भी पासवर्ड के टाइप होने से पहले विफल हो जाती है।

पहचान प्रदाता को क्या लौटाना चाहिए

IdP हस्ताक्षरित SAML प्रतिक्रिया देता है जिसमें एक दावा होता है: विषय कौन है, किसने जारी किया, किसके लिए है और कितने समय तक वैध है। ये फ़ील्ड ही अनुबंध हैं। जारीकर्ता, दर्शक, प्राप्तकर्ता और वैधता विंडो—सभी को सेवा की अपेक्षा से मेल खाना चाहिए।

सही IdP द्वारा हस्ताक्षरित लेकिन किसी और दर्शक को संबोधित प्रतिक्रिया फिर भी अवैध है। यही जाँच लोग तब छोड़ देते हैं जब वे प्रयोगशाला से उत्पादन में मेटाडेटा कॉपी करते हैं।

VPN सेवा आप पर भरोसा करने से पहले क्या सत्यापित करती है

सेवा विश्वसनीय प्रमाणपत्र के विरुद्ध हस्ताक्षर सत्यापित करती है, जारीकर्ता, दर्शक और प्राप्तकर्ता जाँचती है, और फिर समय की शर्तें आँकती है। उसके बाद ही वह दावे को उपयोगकर्ता या समूह से मैप करती है और VPN प्राधिकरण नीति लागू करती है। यहाँ प्रमाणीकरण और प्राधिकरण अलग चरण हैं, और मेल खाते समूह के बिना वैध दावा ऐसा सत्र देता है जो जुड़ता है और कहीं नहीं पहुँचता।

दावा प्रमाणीकरण सामग्री है, पासवर्ड नहीं। इसे किसी और क्लाइंट में चिपकाना, या बाद के पुन:कनेक्शन के लिए रखना समर्थित लॉगिन नहीं है।

दो आयु जो अलग-अलग समाप्त होती हैं

IdP पर ब्राउज़र सत्र और गेटवे पर VPN सत्र अलग-अलग घड़ियों पर समाप्त होते हैं। IdP से साइन आउट करने से स्थापित टनल ज़रूरी नहीं टूटे, और टनल डिस्कनेक्ट करने से आप ब्राउज़र से साइन आउट नहीं होते।

AWS Client VPN दस्तावेज़ करता है कि उसका फ़ेडरेटेड प्रवाह SAML एकल लॉगआउट का समर्थन नहीं करता, जो इस अंतराल का ठोस उदाहरण है। समरूपता मानने के बजाय अपनी सेवा जाँचें।

इसीलिए पुन:कनेक्शन 09:00 और 15:00 पर अलग व्यवहार करता है। यह IdP सत्र का चुपचाप पुन:उपयोग कर सकता है, फिर से MFA माँग सकता है, या विफल हो सकता है क्योंकि एंडपॉइंट सत्र की अवधि समाप्त हो गई जबकि ब्राउज़र सत्र की नहीं। AWS फ़ेडरेशन वर्कफ़्लो अपनी क्लाइंट और प्रतिक्रिया आवश्यकताएँ बताता है, और अन्य सेवाएँ अलग हैंडऑफ़ उपयोग करती हैं।

जब ब्राउज़र चरण विफल हो, तो इन्हें इस क्रम में जाँचें

ब्राउज़र से बाहर की ओर काम करें, क्योंकि त्रुटि संदेश आमतौर पर पहली नहीं, आखिरी छलांग का नाम लेता है।

अगर पेज कभी लोड नहीं होता, तो क्लाइंट का IdP URL या उसका रास्ता गलत है। अगर IdP अनुरोध अस्वीकार करता है, तो सेवा-प्रदाता पहचानकर्ता या कॉलबैक उसके कॉन्फ़िग से मेल नहीं खाते। अगर ब्राउज़र सफलता दिखाता है और क्लाइंट फिर भी विफल होता है, तो प्रतिक्रिया गलत जगह पहुँची या दर्शक और समय सत्यापन में विफल रही। और अगर टनल बिना पहुँच के उठता है, तो दावा स्वीकार हुआ पर समूह मैपिंग नहीं।

अपेक्षित पेज, कॉलबैक और समूह मैपिंग एक ही दस्तावेज़ में रखें। तब टूटे VPN लॉगिन की रिपोर्ट करने वाला उपयोगकर्ता बता सकता है कि उसने इन चार में से क्या देखा, और उत्तर आधा लिखा हुआ होता है।