फेडरेटेड VPN लगइनको ब्राउजर चरणमा के हुन्छ

तपाईं कनेक्ट थिच्नुहुन्छ, र पासवर्ड बक्सको सट्टा VPN क्लाइन्टले तपाईंको ब्राउजर खोल्छ। यो हस्तान्तरणले टनेल आफैं प्रमाणित हुन्छ भन्ने अपेक्षा राख्ने मानिसहरूलाई अन्योलमा पार्छ। ब्राउजर कुनै घुम्ती बाटो होइन: आइडेन्टिटी प्रोभाइडरले वास्तवमा व्यक्तिलाई प्रमाणित गर्ने ठाउँ त्यहीँ हो, र क्लाइन्ट केवल नतिजाको प्रतीक्षा गरिरहेको हुन्छ।

एउटा साइन-इन सुरुदेखि अन्त्यसम्म पछ्याउँदा प्रत्येक त्रुटि कहाँ पर्छ भन्ने देखिन्छ, र धेरैजसो रनबुकले छोड्ने भाग त्यही हो।

गेटवे कन्फिगबाट होइन, क्लाइन्टबाट सुरु गर्नुहोस्

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

अरू केही गर्नुअघि क्लाइन्टको फेडरेसन कन्फिगमा दुई मान पढ्नुहोस्: यसले विश्वास गर्ने IdP मेटाडाटा वा URL, र यसले अपेक्षा गर्ने कलब्याक ठेगाना। त्यहाँ बेमेल भयो भने कुनै पासवर्ड टाइप हुनुअघि नै असफल हुन्छ।

आइडेन्टिटी प्रोभाइडरले के फर्काउनुपर्छ

IdP ले assertion भएको हस्ताक्षरित SAML प्रतिक्रियासँग जवाफ दिन्छ: विषय को हो, यो कसले जारी गर्यो, यो कसका लागि हो, र यो कति समय मान्य रहन्छ। ती फिल्डहरू नै सम्झौता हुन्। 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 सोध्न सक्छ, वा ब्राउजर सत्र सकिएको नभई एन्डपोइन्ट सत्रको अवधि सकिएकाले असफल हुन सक्छ। AWS फेडरेसन कार्यप्रवाह ले आफ्नै क्लाइन्ट र प्रतिक्रिया आवश्यकताहरू वर्णन गर्छ, र अरू सेवाहरूले फरक हस्तान्तरण प्रयोग गर्छन्।

ब्राउजर चरण असफल भएमा यी क्रममा जाँच्नुहोस्

ब्राउजरबाट बाहिरतिर काम गर्नुहोस्, किनकि त्रुटि सन्देशले सामान्यतया पहिलो होइन, अन्तिम हपको नाम दिन्छ।

यदि पृष्ठ कहिल्यै लोड हुँदैन भने क्लाइन्टको IdP URL वा त्यससम्मको बाटो गलत छ। यदि IdP ले अनुरोध अस्वीकार गर्छ भने सेवा-प्रदायक पहिचान वा कलब्याक त्यसको कन्फिगसँग मिल्दैन। यदि ब्राउजरले सफलता देखाउँछ र क्लाइन्ट अझै असफल हुन्छ भने प्रतिक्रिया गलत ठाउँमा पुग्यो वा audience र समय प्रमाणीकरणमा असफल भयो। र यदि टनेल पहुँचबिना उठ्छ भने assertion स्वीकारियो तर समूह म्यापिङ भएन।

अपेक्षित पृष्ठ, कलब्याक र समूह म्यापिङ एउटै कागजातमा राख्नुहोस्। त्यसपछि बिग्रिएको VPN लगइन रिपोर्ट गर्ने प्रयोगकर्ताले ती चारमध्ये कुन देखे भन्न सक्छ, र जवाफ आधा लेखिएको हुन्छ।