किन एउटा OTP ले Wi-Fi, VPN र रजिस्ट्री ढाक्न सक्दैन
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 राख्न सक्छ, र रजिस्ट्रीले स्पष्ट दायरा भएका टोकन प्रयोग गर्न सक्छ। प्रत्येकका लागि मालिक, दर्शक, दायरा, समाप्ति र रद्द गर्ने मार्ग अभिलेख गर्नुहोस्, र सोधपुछ एकैचोटि सबैतिर होइन, चाहिएको ठाउँमा पर्नेछ। त्यो अभिलेख लेखापरीक्षकले कुन प्रणाली अझै पासवर्डमा भरोसा गर्छन् भनी सोध्दा दिने उत्तर पनि हो।