एक 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 ठेवू शकतो, आणि रजिस्ट्री स्पष्ट व्याप्ती असलेली टोकन वापरू शकते। प्रत्येकासाठी मालक, प्रेक्षक, व्याप्ती, समाप्ती आणि रद्द करण्याचा मार्ग नोंदवा, आणि विचारणा एकाच वेळी सर्वत्र नाही तर हव्या त्या ठिकाणी पडतील। ती नोंद लेखापरीक्षकाने कोणत्या प्रणाली अजूनही पासवर्डवर विश्वास ठेवतात असे विचारल्यावरचे उत्तरही आहे।