एक OTP Wi-Fi, VPN और रजिस्ट्री को क्यों नहीं ढक सकता

सिंगल साइन-ऑन एक पहचान और कम संकेतों का वादा करता है, और वह वादा तीसरे प्रोटोकॉल पर टूट जाता है। जाल यह मान लेना है कि एक सफल प्रमाणीकरण ऐसा टोकन बनाता है जिसे हर दूसरा प्रोटोकॉल प्रस्तुत कर सके। Wi-Fi प्रवेश, VPN प्रवेश और एक कंटेनर रजिस्ट्री — तीनों अलग विनिमय चलाते हैं, अलग दर्शकों और जीवनकालों के साथ। खाता साझा करना निर्देशिका का निर्णय है; क्रेडेंशियल साझा करना प्रोटोकॉल का निर्णय है, और प्रोटोकॉल शायद ही सहमत होते हैं।

तीन विनिमय, तीन मालिक

एंटरप्राइज़ Wi-Fi 802.1X के भीतर EAP विधि चलाता है, जिसे आम तौर पर RADIUS सेवा समाप्त करती है और जिसका उपयोगकर्ता या डिवाइस पर अपना दृष्टिकोण होता है। VPN गेटवे अपने ही समर्थित प्रवाह से प्रमाणित करता है और फिर अपने ही पुनः-प्रमाणीकरण टाइमर वाला सत्र रखता है। रजिस्ट्री एक अप्रमाणित अनुरोध का उत्तर ऐसी चुनौती से देती है जो टोकन सेवा, दर्शक और दायरा बताती है, और क्लाइंट अपना क्रेडेंशियल एक अल्पकालिक टोकन से बदलता है।

ये एक सत्र के तीन दृश्य नहीं हैं। हर एक का अपना सत्यापनकर्ता, अपना जीवनकाल और अपना निरसन पथ है, इसीलिए निर्देशिका में पासवर्ड बदलने पर एक चलता रह सकता है और दूसरा टूट सकता है। इन्हें तीन एकीकरण मानें जो संयोग से एक उपयोगकर्ता निर्देशिका साझा करते हैं।

ब्राउज़र SSO क्या ले जाता है और क्या नहीं

पहचान प्रदाता पर ब्राउज़र सत्र वास्तव में उपयोगी है: जो एप्लिकेशन वहाँ रीडायरेक्ट करते हैं, उन्हें उपयोगकर्ता द्वारा पहले ही पूरा किया गया लॉगिन विरासत में मिलता है। यह इसलिए काम करता है क्योंकि वे एप्लिकेशन वही रीडायरेक्ट और टोकन प्रोटोकॉल बोलते हैं और वही दर्शक स्वीकार करते हैं। EAP बोलने वाले अनुरोधकर्ता के पास अनुसरण करने को कोई रीडायरेक्ट नहीं है, और रजिस्ट्री चुनौती पाने वाला Docker क्लाइंट OIDC पहचान टोकन नहीं माँगता। पहचान प्रदाता केवल उन प्रोटोकॉल की जमानत दे सकता है जिनके लिए उसे बनाया गया है।

लॉग में विफलता देखना आसान है, बस जानना होगा कि कहाँ देखना है। पहचान प्रदाता सफल लॉगिन की सूचना देता है जबकि Wi-Fi जुड़ाव अब भी विफल होता है, या रजिस्ट्री उस टोकन विनिमय के बाद 401 लौटाती है जिसे ब्राउज़र ने कभी नहीं देखा। दो सफलताएँ और एक विफलता विरोधाभास नहीं हैं; वे तीन अलग प्रमाणीकरण हैं।

जहाँ प्रमाणपत्र दोहराया गया कोड बदल देता है

प्रबंधित डिवाइसों के लिए, प्रमाणपत्र-आधारित EAP पहचान हटाए बिना मानवीय चरण हटा देता है: डिवाइस प्रमाणपत्र प्रस्तुत करता है, RADIUS सेवा उसे जारी करने वाली प्राधिकरण के सामने जाँचती है, और निरसन उसी प्राधिकरण में होता है, किसी साझा रहस्य में नहीं। कीमत जीवनचक्र का काम है, क्योंकि प्रमाणपत्र समाप्त होते हैं और उससे पहले नवीनीकृत करने पड़ते हैं।

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

docker login registry.example.com

रखरखाव लागत की तुलना करें, संकेतों की संख्या की नहीं

साझा क्रेडेंशियल सस्ता दिखता है क्योंकि काम विफल होने तक अदृश्य रहता है। इसके बजाय गिनें कि एक वर्ष में हर विकल्प कितना खर्च करता है: नामांकन, नवीनीकरण, निरसन, लीक का प्रभाव-दायरा और जब कोई जाता है तब छुई जाने वाली प्रणालियों की संख्या। प्रमाणपत्रों का बेड़ा बनाने में अधिक और पैमाने पर चलाने में कम खर्च करता है; नकल किया गया कोड शुरू करने में कुछ नहीं और सुलझाने में सब कुछ खर्च करता है।

फिर हर चरण के लिए अलग चुनें, वैश्विक रूप से नहीं। Wi-Fi प्रमाणपत्रों की ओर जा सकता है, VPN MFA के साथ समर्थित SSO रख सकता है, और रजिस्ट्री स्पष्ट दायरों वाले टोकन उपयोग कर सकती है। हर एक के लिए मालिक, दर्शक, दायरा, समाप्ति और निरसन पथ दर्ज करें, और संकेत वहीं पड़ेंगे जहाँ चाहिए, एक साथ हर जगह नहीं। वही रिकॉर्ड तब भी उत्तर है जब कोई लेखा परीक्षक पूछे कि कौन-सी प्रणालियाँ अब भी पासवर्ड पर भरोसा करती हैं।