VPN SSO वापरकर्त्यांना अंतर्गत ॲप्समध्ये आपोआप साइन इन करते का?

ओळख प्रदात्याद्वारे प्रमाणीकरण करणारा VPN गेटवे एकच गोष्ट सिद्ध करतो: प्रदात्याने गेटवेसमोर एका वापरकर्त्याची हमी दिली. तो त्या वापरकर्त्याला इंट्रानेट विकी, देखरेख डॅशबोर्ड किंवा बिल्ड सर्व्हरसाठी कोणतेही क्रेडेन्शियल देत नाही. त्या सेवा लोकांना स्वतःच्या फेडरेशनद्वारे साइन इन करवतात आणि स्वतःचे अधिकृतता लागू करतात, आणि बोगदा फक्त कोणते पॅकेट त्यांच्यापर्यंत पोहोचू शकतात हे ठरवतो.

तीन सत्रे, तीन स्वतंत्र निर्णय

स्थिती वेगळ्या ठेवा, कारण प्रत्येक स्वतःच्या वेळापत्रकानुसार संपते. VPN सत्र म्हणजे गेटवेने ओळख स्वीकारणे आणि त्याने दिलेला नेटवर्क प्रवेश. ओळख प्रदात्याकडील ब्राउझर सत्र म्हणजे ब्राउझर त्या प्रदात्यासाठी अजूनही ठेवत असलेले आणि त्याच्या धोरणानुसार पुन्हा वापरू शकणारे. ॲप सत्र हे स्वतःला पाठवलेल्या प्रतिसादाची पडताळणी करणाऱ्या एका सेवेचे असते.

या स्थितींना गोंधळवल्याने चुकीचा प्रश्न तयार होतो, सहसा बोगदा वापरकर्त्याला सर्वत्र साइन इन का करत नाही असे विचारले जाते. तो पुन्हा लिहा: कोणत्या ॲपकडे फेडरेशन नोंद नाही, कोणते वापरकर्त्याला नाकारते, आणि कोणत्या मार्ग नाही. इंट्रानेट ॲप उघडणारी एकच साइन-इन सूचना तरीही प्रदात्याकडे परत जाऊ शकते, कारण दुसरे रीडायरेक्ट वेगळ्या प्रेक्षकांसाठी नवीन अधिकृतता विनंती आहे.

गेटवे त्याच्या स्वतःच्या ॲप म्हणून जोडा

VPN ला प्रदात्यामध्ये मंजूर ॲप म्हणून नोंदवा, त्याच्या स्वतःच्या ओळखकर्त्यासह, रीडायरेक्ट URI आणि वापरकर्ता वाटपासह. नंतर ती लॉगिन कोणते नेटवर्क अधिकृतता देते हे ठरवा, कारण ते VPN धोरण आहे, प्रदात्याचे वैशिष्ट्य नाही. फक्त देखरेख उपजाळापर्यंत पोहोचायचे असलेल्या वापरकर्त्यांना वेगळे गेटवे धोरण मिळते, वेगळा पासवर्ड नाही.

बोगद्याचा प्रमाणीकरण प्रतिसाद पुन्हा वापरता येणारे क्रेडेन्शियल नाही. OIDC ID टोकनमध्ये प्रेक्षक दावा असतो जो ते ज्या क्लायंटसाठी जारी झाले त्याचे नाव सांगतो, आणि SAML बेअरर विधाने प्रेक्षकांना प्राप्तकर्ता सेवा प्रदात्यापर्यंत मर्यादित करतात. पहिल्या सेवेचा प्रतिसाद स्वीकारणारी दुसरी सेवा चुकीची संरचित आहे, आणि टोकन दुसऱ्या ॲपमध्ये कॉपी करणे हे एकत्रीकरण नाही.

प्रत्येक अंतर्गत ॲप नोंदवा, नंतर ब्राउझर संदर्भ सेट करा

प्रत्येक सेवेला समर्थित SAML किंवा OIDC मूल्ये आवश्यक आहेत: जारीकर्ता, क्लायंट ओळखकर्ता, कॉलबॅक किंवा विधान-ग्राहक URL, आवश्यक दावे आणि वाटप. पोहोच त्यावर येते, कारण ओळख तपासण्या कधीही मार्ग किंवा DNS उत्तर देत नाहीत.

1. ॲप नोंद तयार करा आणि एंटिटी किंवा क्लायंट ID ॲप पाठवत असलेल्याशी जुळतो हे तपासा.
2. स्कीम आणि पोर्टसह अचूक कॉलबॅक URL नोंदवा; थोडीशी चूक वापरकर्त्याच्या प्रमाणीकरणानंतर अयशस्वी होते.
3. वापरकर्ते किंवा गट वाटप करा, नंतर आवश्यक दावे जारी होतात हे तपासा.
4. खासगी ॲपसोबत ओळख प्रदात्याचे एंडपॉइंट्सही अनुमत करा, अन्यथा रीडायरेक्ट पूर्ण होऊ शकत नाही.

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

कोणी मागितले ते शोधून सूचना दुरुस्त करा

दुसरी पासवर्ड सूचना आपोआप दोष नाही. ॲप उच्च आश्वासन पातळी मागू शकते, किंवा प्रदाता कमाल सत्र वय आणि नवीन आव्हान लादू शकतो. प्रवाह शांत करण्यासाठी त्या आवश्यकता काढून टाकणे जाणीवपूर्वक ठेवलेले नियंत्रण कमकुवत करते, म्हणून धोरण बदलण्यापूर्वी कोणत्या घटकाने मागितले ते निश्चित करा.

नंतर काय सुधारायचे ते ठरवा. सूचना ॲपकडून आली तर त्याची फेडरेशन नोंद दुरुस्त करा. धोरणानुसार प्रदात्याकडून आली तर आवश्यकता नोंदवा. यशस्वी साइन-इननंतर ॲप पोहोचेपर्यंत नसेल, तर बोगद्याचे राउटिंग संशयास्पद आहे, कारण ओळख आणि पॅकेट वितरण वेगवेगळ्या ठिकाणी अयशस्वी होतात आणि वापरकर्त्याच्या जागेवरून सारखेच दिसतात.