के 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 प्रोफाइल होइन।
कसले माग्यो भनेर पत्ता लगाएर सङ्केतहरू सुधार्नुहोस्
दोस्रो पासवर्ड सङ्केत आफैंमा दोष होइन। एपले उच्च आश्वासन स्तर माग्न सक्छ, वा प्रदायकले अधिकतम सत्र उमेर र नयाँ चुनौती लागू गर्न सक्छ. प्रवाह शान्त बनाउन ती आवश्यकताहरू हटाउनु जानाजान राखिएको नियन्त्रण कमजोर गर्छ, त्यसैले नीति बदल्नुअघि कुन घटकले माग्यो निश्चित गर्नुहोस्।
त्यसपछि के सुधार्ने निर्णय गर्नुहोस्। सङ्केत एपबाट आएको भए त्यसको महासंघ प्रविष्टि सुधार्नुहोस्। नीतिअनुसार प्रदायकबाट आएको भए आवश्यकता अभिलेख गर्नुहोस्। सफल साइन-इनपछि एप पहुँचभन्दा बाहिर भए, टनेलको राउटिङ शङ्कास्पद छ, किनकि पहिचान र प्याकेट वितरण फरक ठाउँमा असफल हुन्छन् र प्रयोगकर्ताको सिटबाट उस्तै देखिन्छन्।