आप शायद पहले से ही इसका सामना कर रहे हैं। कर्मचारी Microsoft 365 में साइन इन करते हैं, फिर एक बुकिंग टूल में, फिर HR में, फिर एक लाइन-ऑफ-बिजनेस ऐप में, फिर कॉर्पोरेट WiFi में, अक्सर हर एक के लिए एक अलग तरीके का उपयोग करते हैं। एक होटल समूह के पास मुख्य कार्यालय में प्रणालियों का एक सेट होता है और संपत्ति पर दूसरा सेट होता है। एक अस्पताल में क्लिनिकल ऐप्स, साझा वर्कस्टेशन और खंडित (सेगमेंटेड) वायरलेस एक्सेस होती है। एक रिटेल ऑपरेटर के पास स्टोर, टैबलेट, POS और बैक-ऑफिस डैशबोर्ड के बीच काम करने वाले कर्मचारी होते हैं।
वह मिश्रण तेजी से घर्षण पैदा करता है। उपयोगकर्ता पासवर्ड भूल जाते हैं, IT टीमें खातों को रीसेट करती हैं, और साझा WiFi क्रेडेंशियल हटाए जाने के बहुत बाद तक बने रहते हैं। इसका परिणाम केवल झुंझलाहट नहीं है। यह इस बात पर कमजोर नियंत्रण है कि कौन, किस डिवाइस से, और कितने समय के लिए क्या एक्सेस कर सकता है।
यही वह जगह है जहाँ सिंगल साइन-ऑन, या SSO, उपयोगी हो जाता है। यदि आप खोज रहे हैं कि सिंगल साइन ऑन क्या है, तो संक्षिप्त उत्तर सरल है: यह उपयोगकर्ता को एक बार प्रमाणित करने की अनुमति देता है और फिर बार-बार क्रेडेंशियल दर्ज किए बिना कई स्वीकृत सिस्टम तक पहुँचने की अनुमति देता है। अधिक उपयोगी उत्तर परिचालन से संबंधित है। SSO IT को ऐप्स तक पहुँच के लिए एक पहचान परत (आइडेंटिटी लेयर) प्रदान करता है, और सही डिज़ाइन में, यह इस बात का भी समर्थन कर सकता है कि लोग और डिवाइस सुरक्षित नेटवर्क से कैसे जुड़ते हैं।
पासवर्ड के झंझट का अंत
अधिकांश एंटरप्राइज़ वातावरण जानबूझकर अव्यवस्थित नहीं बने। वे इसी तरह विकसित हुए। एक क्लाउड ऐप से पाँच बन गए। एक ऑफ़िस से कई साइट्स बन गईं। IT के लिए एक वायरलेस नेटवर्क स्टाफ, मेहमानों, कॉन्ट्रैक्टर्स और डिवाइसेस के लिए अलग-अलग SSIDs में बदल गया।
इस तरह से पासवर्ड का फैलाव शुरू होता है। किसी भी वास्तविक काम को शुरू करने से पहले एक स्टाफ सदस्य को ईमेल, HR, शेड्यूलिंग, फ़ाइल एक्सेस, आंतरिक डैशबोर्ड और नेटवर्क एक्सेस की आवश्यकता हो सकती है। IBM, SSO को एक ऐसी योजना के रूप में वर्णित करता है जहां उपयोगकर्ता एक क्रेडेंशियल के सेट के साथ एक बार लॉग इन करते हैं और उसी सेशन के दौरान कई एप्लिकेशन्स तक पहुंचते हैं, जो सर्विस प्रोवाइडर्स और एक आइडेंटिटी प्रोवाइडर के बीच विश्वास संबंध द्वारा सक्षम होता है। IBM का single sign-on का अवलोकन यूके के संगठनों की आवश्यकता के साथ निकटता से मेल खाता है क्योंकि क्लाउड अपनाने और रिमोट वर्क में तेजी आई है।
पासवर्ड का फैलाव संचालन को कैसे प्रभावित करता है
जब हर एप्लिकेशन अपना खुद का लॉगिन मांगता है, तो उपयोगकर्ता शॉर्टकट अपनाने लगते हैं। वे पासवर्ड का दोबारा उपयोग करते हैं। वे उन्हें ब्राउज़र में सहेजते हैं। वे सहकर्मियों से "स्टाफ WiFi पासवर्ड" पूछते हैं क्योंकि यह IT का इंतजार करने से तेज़ है।
एक एंटरप्राइज़ IT मैनेजर के लिए, नियंत्रण सबसे महत्वपूर्ण चिंता है। अलग-अलग लॉगिन एक्सेस के अलग-अलग द्वीप बनाते हैं, और उन द्वीपों को नियंत्रित करना तब कठिन हो जाता है जब लोग भूमिकाएं बदलते हैं, व्यवसाय छोड़ते हैं, या कई स्थानों पर काम करते हैं।
पासवर्ड की अव्यवस्था शायद ही कभी कोई एक बड़ी विफलता होती है। यह आमतौर पर सौ छोटे एक्सेस निर्णय होते हैं जिन्हें कोई भी लगातार प्रबंधित नहीं कर पाता है।
SSO तस्वीर को क्यों बदल देता है
SSO उपयोगकर्ताओं द्वारा प्रबंधित किए जाने वाले पासवर्ड की संख्या को कम करता है, जिससे लॉगिन अनुभव में सुधार होता है और केंद्रीय नीति और MFA के साथ जोड़े जाने पर मजबूत सुरक्षा मिलती है। यह वितरित संगठनों की वास्तविकता के भी अनुकूल है जहां कर्मचारियों को ईमेल, HR, बुकिंग टूल, POS, आंतरिक ऐप्स और साइट सेवाओं में एक ही लॉगिन की आवश्यकता होती है।
वही तर्क अब नेटवर्क एक्सेस को भी आकार दे रहा है। यदि आप पहले से ही एप्लिकेशन्स के लिए आइडेंटिटी-आधारित एक्सेस की ओर बढ़ रहे हैं, तो पासवर्डलेस WiFi को उसी डिज़ाइन दृष्टिकोण के हिस्से के रूप में देखना समझदारी है, न कि एक अलग समस्या के रूप में।
कोर SSO अवधारणा को समझना
SSO प्रमाणीकरण को प्रत्येक व्यक्तिगत एप्लिकेशन से दूर ले जाता है और इसे एक विश्वसनीय पहचान प्रणाली पर रखता है। उपयोगकर्ता एक बार साइन इन करता है, उस पहचान को सत्यापित किया जाता है, और कनेक्टेड सेवाएं दूसरे पासवर्ड की मांग करने के बजाय उस परिणाम को स्वीकार करती हैं।
यह सुनने में सरल लगता है, लेकिन इसका मूल्य आर्किटेक्चरल है। आप यह बदल रहे हैं कि विश्वास कहाँ निवास करता है।
प्रत्येक SSO फ्लो में शामिल तीन पक्ष
प्रत्येक SSO डिज़ाइन में तीन भागीदार होते हैं, और प्रत्येक का काम अलग होता है:
- उपयोगकर्ता किसी एप्लिकेशन, सेवा, या नेटवर्क संसाधन तक पहुँच चाहता है।
- आइडेंटिटी प्रोवाइडर या IdP पहचान की पुष्टि करता है और साइन-इन पॉलिसी लागू करता है। UK के संगठनों में आम उदाहरणों में Microsoft Entra ID और Okta शामिल हैं।
- सर्विस प्रोवाइडर या SP वह सिस्टम है जिस तक उपयोगकर्ता पहुँचने का प्रयास कर रहा है, जैसे Salesforce, एक बुकिंग प्लेटफॉर्म, एक इंट्रानेट, या कोई अन्य व्यावसायिक सिस्टम।
जिस बिंदु पर अक्सर भ्रम होता है वह है विश्वास। एप्लिकेशन को स्वयं पासवर्ड एकत्र करने और जांचने की आवश्यकता नहीं होती है। यह उस काम को सही तरीके से करने के लिए IdP पर निर्भर करता है, और फिर परिणाम स्वीकार करता है।
विश्वास संबंध का वास्तव में क्या अर्थ है
Auth0 एंटरप्राइज के संदर्भ में SSO को स्पष्ट रूप से समझाता है: IdP उपयोगकर्ता को एक बार प्रमाणित करता है, फिर एक सेशन आर्टिफैक्ट या टोकन जारी करता है जिसे विश्वसनीय सर्विस प्रोवाइडर्स बाद में एक्सेस के लिए सत्यापित करते हैं। व्यवहार में, उपयोगकर्ता को IdP पर रीडायरेक्ट किया जाता है, वहां प्रमाणित किया जाता है, और बार-बार क्रेडेंशियल संकेतों के बिना प्रत्येक ऐप पर वापस भेज दिया जाता है। Auth0 की how single sign-on works की गाइड SaaS और आंतरिक प्रणालियों में Microsoft Entra ID का उपयोग करने वाले यूके के वातावरण में विशेष रूप से प्रासंगिक है।
इसे समझने का एक व्यावहारिक तरीका यह है:
- एक यूजर एप्लिकेशन खोलता है।
- एप्लिकेशन जांचता है कि क्या किसी विश्वसनीय IdP ने उस यूजर को पहले ही प्रमाणित कर दिया है।
- यदि कोई सक्रिय सेशन मौजूद नहीं है, तो यूजर IdP के साथ साइन इन करता है।
- IdP पहचान की पुष्टि करता है और प्रमाण वापस करता है जिसे एप्लिकेशन सत्यापित कर सकता है।
- अन्य जुड़े हुए सिस्टम सेशन के दौरान उसी प्रमाण को स्वीकार कर सकते हैं।
व्यावहारिक नियम: SSO हर सिस्टम को एक प्लेटफॉर्म में नहीं बदलता है। यह कई सिस्टम को पहचान सत्यापित करने के लिए एक स्थान देता है।
वेब ऐप्स के बाहर यह क्यों मायने रखता है
यह वह जगह भी है जहाँ SSO केवल SaaS सुविधा से कहीं अधिक बन जाता है। एक बार पहचान केंद्रीकृत हो जाने के बाद, उसी मॉडल का उपयोग केवल ब्राउज़र सेशन से अधिक के लिए किया जा सकता है। यह यह भी आकार दे सकता है कि आप आंतरिक सेवाओं तक पहुंच को कैसे नियंत्रित करते हैं और, सही डिज़ाइन में, उपयोगकर्ता कॉर्पोरेट वायरलेस नेटवर्क में कैसे शामिल होते हैं।
यह IT ऑपरेशन्स के लिए महत्वपूर्ण है। एक फाइनेंस ऐप, एक VPN सेशन, और एक कर्मचारी WiFi कनेक्शन अलग-अलग सेवाएं हो सकती हैं, लेकिन वे सभी एक ही प्रश्न से शुरू होती हैं: यह उपयोगकर्ता कौन है, और क्या उन्हें अंदर आने की अनुमति दी जानी चाहिए? जब Microsoft Entra ID या Okta लगातार उस प्रश्न का उत्तर देता है, तो एप्लिकेशन्स और नेटवर्क प्रविष्टि बिंदुओं दोनों में एक्सेस नीति को प्रबंधित करना आसान हो जाता है।
उन टीमों के लिए जो अभी भी एक साझा पासवर्ड के साथ स्टाफ WiFi चला रही हैं, यह एक बड़ा बदलाव है। हर किसी को पता होने वाले पासवर्ड से किसी डिवाइस को प्रमाणित करने के बजाय, आप एक विश्वसनीय पहचान स्रोत के खिलाफ किसी व्यक्ति या प्रबंधित डिवाइस को प्रमाणित करते हैं। इससे आपको कड़ा नियंत्रण, स्पष्ट ऑडिट ट्रेल और भूमिकाएं बदलने या रोजगार समाप्त होने पर एक्सेस हटाने का एक आसान तरीका मिलता है।
SSO कैसे काम करता है - मुख्य प्रोटोकॉल
उपयोगकर्ता अनुभव सरल दिखता है। इसके पीछे, SSO उन मानक प्रोटोकॉल पर निर्भर करता है जो किसी एप्लिकेशन को कहीं और लिए गए पहचान निर्णय पर भरोसा करने की अनुमति देते हैं।
एक उद्यम IT प्रबंधक के लिए, व्यावहारिक प्रश्न केवल "SSO क्या है?" नहीं है। यह है कि "एक सिस्टम उपयोगकर्ता से दोबारा लॉग इन करने के लिए कहे बिना दूसरे सिस्टम से प्रमाण कैसे स्वीकार करता है?" इसका उत्तर प्रोटोकॉल के एक छोटे सेट पर निर्भर करता है जो एप्लिकेशन, पहचान प्रदाता और कभी-कभी डिवाइस के बीच पहचान डेटा को स्थानांतरित करते हैं।
यह ब्राउज़र लॉगिन से परे भी मायने रखता है। SaaS ऐप खोलने के लिए उपयोग किया जाने वाला वही ट्रस्ट मॉडल यह भी प्रभावित कर सकता है कि उपयोगकर्ता VPN, वायर्ड नेटवर्क और कॉर्पोरेट WiFi से कैसे जुड़ते हैं जब वे एक्सेस निर्णय Microsoft Entra ID, Okta या किसी अन्य केंद्रीय पहचान स्रोत से जुड़े होते हैं।
SAML सरल हिंदी में
SAML 2.0 अभी भी एंटरप्राइज SSO में आम है, विशेष रूप से स्थापित SaaS प्लेटफॉर्म और व्यावसायिक प्रणालियों के लिए।
SAML एप्लिकेशन और पहचान प्रदाता के बीच विश्वसनीय पहचान विवरण पारित करके काम करता है। एक उपयोगकर्ता एक एप्लिकेशन खोलने का प्रयास करता है। एप्लिकेशन उन्हें IdP पर रीडायरेक्ट करता है। IdP उपयोगकर्ता को प्रमाणित करता है और एक डिजिटल रूप से हस्ताक्षरित दावा वापस भेजता है। एप्लिकेशन उस हस्ताक्षर की जांच करता है, पहचान के दावे को स्वीकार करता है, और एक सत्र बनाता है।
यह प्रवाह उन वातावरणों के लिए उपयुक्त है जहाँ ब्राउज़र अधिकांश काम कर रहा होता है और एप्लिकेशन एक औपचारिक, मानकों पर आधारित आदान-प्रदान की अपेक्षा करता है।
SAML अक्सर इनके लिए बेहद उपयुक्त होता है:
- Enterprise SaaS जैसे कि HR, फाइनेंस, या लीगेसी व्यावसायिक एप्लिकेशन
- ब्राउज़र-आधारित वर्कफ़्लो जहाँ उपयोगकर्ता वेब सेशन के माध्यम से सिस्टम तक पहुँचते हैं
- केंद्रीय नीति प्रवर्तन जब IT प्रमाणीकरण को नियंत्रित करने के लिए एक स्थान चाहता है
सरल शब्दों में OAuth और OIDC
OAuth 2.0 की शुरुआत क्रेडेंशियल्स का पूरा सेट साझा किए बिना किसी रिसोर्स तक सीमित एक्सेस देने के तरीके के रूप में हुई थी। अपने आप में, यह ऑथराइजेशन (प्राधिकरण) के बारे में है।
OpenID Connect, या OIDC, OAuth 2.0 के ऊपर पहचान जोड़ता है। यह आधुनिक अनुप्रयोगों को टोकन-आधारित एक्सेस पैटर्न का उपयोग करते हुए उपयोगकर्ता की पहचान की पुष्टि करने का एक मानक तरीका प्रदान करता है। यदि SAML अक्सर पुराने ब्राउज़र-केंद्रित SaaS के अनुकूल होता है, तो OIDC आमतौर पर नए वेब ऐप्स, मोबाइल ऐप्स और API-संचालित सेवाओं के लिए उपयुक्त होता है।
व्यवहार में, आधुनिक विकास टीमों के लिए OIDC अधिक सुगम महसूस होता है क्योंकि टोकन फ्रंट-एंड ऐप्स, बैक-एंड सेवाओं और मोबाइल क्लाइंट्स पर अच्छी तरह से काम करते हैं। IT के लिए, इसका मतलब है कि जब एप्लिकेशन कोई पारंपरिक ब्राउज़र सेशन नहीं होता है, तो कम जटिल वर्कअराउंड की आवश्यकता होती है।
OIDC आमतौर पर इनके लिए उपयुक्त होता है:
- आधुनिक क्लाउड एप्लिकेशन्स
- मोबाइल और सिंगल-पेज ऐप्स
- API-भारी वातावरण जहाँ टोकन पहले से ही डिज़ाइन का हिस्सा हैं
Kerberos पर एक त्वरित टिप्पणी
SSO चर्चाओं में आप Kerberos के बारे में भी सुन सकते हैं। Kerberos पारंपरिक Active Directory वातावरण और ऑन-प्रिमाइसेस Windows प्रमाणीकरण से निकटता से जुड़ा हुआ है। यह आंतरिक कॉर्पोरेट परिसंपत्तियों में प्रासंगिक बना हुआ है, विशेष रूप से जहां डोमेन से जुड़े डिवाइस और लीगेसी एप्लिकेशन अभी भी आम हैं।
इसके बावजूद, कई वर्तमान SSO प्रोजेक्ट क्लाउड और हाइब्रिड सेवाओं में फ़ेडरेटेड पहचान पर ध्यान केंद्रित करते हैं। उन मामलों में, SAML और OIDC को आमतौर पर अधिक ध्यान मिलता है क्योंकि वे SaaS प्लेटफ़ॉर्म और बाहरी रूप से सुलभ सेवाओं से अधिक स्वाभाविक रूप से जुड़ते हैं।
SAML बनाम OIDC - एक नज़र में
| विशेषता | SAML 2.0 | OAuth 2.0 / OIDC |
|---|---|---|
| प्राथमिक भूमिका | एंटरप्राइज वेब एप्लिकेशन्स के लिए प्रमाणीकरण (Authentication) | OIDC के माध्यम से जोड़ी गई पहचान के साथ प्राधिकरण (Authorisation) |
| सामान्य उपयोग का मामला | स्थापित SaaS और ब्राउज़र-आधारित एंटरप्राइज ऐप्स | आधुनिक वेब ऐप्स, मोबाइल ऐप्स, API |
| प्रारूप (Format) | XML-आधारित एसर्शन्स (assertions) | टोकन-आधारित फ़्लो |
| सामान्य फ़्लो | IdP पर रीडायरेक्ट करें, प्रमाणित करें, हस्ताक्षरित एसर्शन वापस करें | रीडायरेक्ट या टोकन फ़्लो, फिर ऐप पहचान और एक्सेस के लिए टोकन का उपयोग करता है |
| सर्वोत्तम उपयुक्त | पारंपरिक एंटरप्राइज SSO एकीकरण | नए क्लाउड-नेटिव और ऐप-केंद्रित आर्किटेक्चर |
एक IT मैनेजर के लिए क्या मायने रखता है
प्रोटोकॉल के नाम डिजाइन विकल्पों की तुलना में कम मायने रखते हैं। आपको चार परिचालन प्रश्नों के स्पष्ट उत्तर चाहिए:
- कौन से ऐप्स SAML या OIDC का समर्थन करते हैं
- कौन सा IdP आपके केंद्रीय नियंत्रण विमान के रूप में कार्य करेगा
- सत्र टाइमआउट, MFA और सशर्त पहुंच को कैसे लागू किया जाएगा
- क्या नेटवर्क एक्सेस, जिसमें स्टाफ WiFi भी शामिल है, को भी उसी स्रोत के खिलाफ पहचान को सत्यापित करना चाहिए
वह अंतिम बिंदु वह जगह है जहाँ बुनियादी ढांचा (इन्फ्रास्ट्रक्चर) टीमों के लिए SSO विशेष रूप से उपयोगी हो जाता है। यदि आपका वायरलेस प्लेटफॉर्म उसी पहचान परत (आइडेंटिटी लेयर) का उपयोग कर सकता है जिसका उपयोग आपका SaaS एस्टेट करता है, तो लॉगिन पेज से लेकर नेटवर्क एज तक एक्सेस पॉलिसी अधिक सुसंगत हो जाती है। यही एक कारण है कि एक्सेस कंट्रोल और ऑपरेशन्स के लिए सिंगल साइन-ऑन के लाभों की समीक्षा करने वाली कई टीमें न केवल वेब ऐप लॉगिन, बल्कि आइडेंटिटी-समर्थित WiFi प्रमाणीकरण (ऑथेंटिकेशन) पर भी विचार करने लगती हैं।
लाभ और सुरक्षा समझौतों का आकलन करना
SSO को अक्सर उपयोगकर्ता की सुविधा वाले फीचर के रूप में प्रचारित किया जाता है। यह इसके महत्व को कम आंकना है। यदि इसे सही तरीके से किया जाए, तो यह एक एक्सेस कंट्रोल मॉडल है जो उपयोगकर्ता अनुभव को बेहतर बनाने के साथ-साथ परिचालन सुरक्षा को भी कड़ा कर सकता है।
Okta का मानना है कि SSO का तकनीकी लाभ केवल सुविधा नहीं है। यह पासवर्ड के फैलाव और बार-बार होने वाले लॉगिन इवेंट्स को कम करता है जो हेल्प-डेस्क का बोझ और यूजर की परेशानी को बढ़ाते हैं। सिंगल साइन-ऑन सुरक्षा के बारे में Okta का विवरण एक ऐसे बिंदु पर भी प्रकाश डालता है जिसकी आर्किटेक्ट्स परवाह करते हैं: यदि IdP सेशन अमान्य हो जाता है, तो जुड़े हुए एप्लिकेशन अगले टोकन चेक पर एक्सेस से इनकार कर सकते हैं।
व्यावसायिक मूल्य कहाँ दिखाई देता है
पहला लाभ सरल एक्सेस है। उपयोगकर्ता एक बार लॉग इन करते हैं, जल्दी काम शुरू करते हैं, और प्रमाणीकरण को दैनिक बाधा मानना बंद कर देते हैं।
दूसरा है अधिक मजबूत केंद्रीय नियंत्रण। IT प्रत्येक एप्लिकेशन के भीतर सेटिंग्स को ट्रैक करने के बजाय एक ही पहचान परत (identity layer) से MFA, कंडीशनल एक्सेस, सेशन नीतियां और रिवोकेशन (निरस्तीकरण) लागू कर सकता है।
तीसरा लाभ जॉइनर, मूवर, लीवर प्रबंधन को आसान बनाना है। जब पहचान केंद्रीय रूप से स्थित होती है, तो ऑनबोर्डिंग और ऑफबोर्डिंग अधिक सुसंगत हो जाती है। यही एक कारण है कि single sign-on benefits तलाशने वाली टीमें अक्सर SSO परियोजनाओं को व्यापक पहचान प्रशासन कार्य के साथ जोड़ती हैं।
वे समझौते जिन्हें आपको गंभीरता से लेना चाहिए
एक वास्तविक "कीज़ टू द किंगडम" वाली चिंता है। यदि कोई हमलावर उपयोगकर्ता के प्राथमिक साइन-इन से समझौता कर लेता है, तो प्रभाव का दायरा बड़ा हो सकता है क्योंकि एक अकाउंट कई सिस्टम्स तक पहुँच प्रदान कर सकता है।
इसमें लचीलेपन का जोखिम भी है। यदि IdP अनुपलब्ध है, तो कनेक्टेड सेवाओं तक पहुंच बाधित हो सकती है। और एकीकरण हमेशा साफ-सुथरा नहीं होता है। पुराने ऐप्स, विशिष्ट सिस्टम और स्थानीय नेटवर्क सेवाएं हमेशा एक आधुनिक SSO मॉडल में आसानी से फिट नहीं होती हैं।
सही सवाल यह नहीं है कि क्या SSO में समझौते करने पड़ते हैं। सवाल यह है कि क्या आप उन समझौतों को केंद्रीय रूप से प्रबंधित करना पसंद करेंगे या दर्जनों डिस्कनेक्टेड समझौतों को प्रबंधित करना जारी रखेंगे।
सामान्य समाधान
एक स्तरित दृष्टिकोण का उपयोग करें:
- MFA, कंडीशनल एक्सेस, डिवाइस ट्रस्ट और मजबूत एडमिन नियंत्रणों के साथ IdP को भारी सुरक्षा प्रदान करें।
- लचीलेपन की योजना बनाएं ताकि IdP की कोई समस्या पूरे संगठन के काम को ठप न कर दे।
- उच्च-मूल्य वाले ऐप्स और स्पष्ट उपयोगकर्ता समूहों के साथ शुरू करते हुए चरणबद्ध तरीके से लागू करें।
- नियमित रूप से एक्सेस की समीक्षा करें ताकि पुराने अधिकार उनकी आवश्यकता समाप्त होने के बाद लंबे समय तक जीवित न रहें।
एक कमजोर SSO रोलआउट समस्याओं को केंद्रित कर सकता है। एक मजबूत रोलआउट नियंत्रण को केंद्रित करता है।
वेब ऐप्स नेटवर्क और WiFi एक्सेस से परे SSO
अधिकांश लेख SaaS पर ही रुक जाते हैं। यह उपयोगी है, लेकिन अधूरा है। वास्तविक वातावरण में, कर्मचारियों को केवल ऐप एक्सेस की आवश्यकता नहीं होती है। जब वे साइट पर आते हैं, एक प्रबंधित लैपटॉप कनेक्ट करते हैं, किसी शाखा में टैबलेट खोलते हैं, या संपत्तियों के बीच घूमते हैं, तो उन्हें सुरक्षित नेटवर्क एक्सेस की आवश्यकता होती है।
यही वह जगह है जहाँ SSO की चर्चा और अधिक दिलचस्प हो जाती है। वही आइडेंटिटी प्रोवाइडर जो Microsoft 365, HR सिस्टम या इंटरनल डैशबोर्ड तक पहुँच को संभालता है, वायरलेस ऑथेंटिकेशन पॉलिसियों के लिए सोर्स ऑफ़ ट्रुथ भी बन सकता है।
Optimal IdM अपनी सिंगल साइन-ऑन अपनाने की चर्चा में रिपोर्ट करता है कि उत्तरी अमेरिका में 52% IT पेशेवर पहचान प्रबंधन के लिए SSO का उपयोग करते हैं। कई परिसरों या संपत्तियों वाले यूके के संगठनों के लिए, वह परिपक्वता मायने रखती है क्योंकि कर्मचारियों को अक्सर बार-बार लॉगिन किए बिना साझा प्रणालियों तक सुरक्षित पहुंच की आवश्यकता होती है।
ऐप SSO और नेटवर्क पहचान संबंधित हैं, समान नहीं
पाठकों के लिए भ्रम का एक सामान्य बिंदु यह है कि एप्लिकेशन्स के लिए SSO और आइडेंटिटी-आधारित नेटवर्क एक्सेस आपस में जुड़े हुए विचार हैं, लेकिन वे एक ही मैकेनिज्म नहीं हैं।
App SSO का अर्थ आमतौर पर यह होता है कि उपयोगकर्ता IdP के साथ एक बार प्रमाणित होता है और उसे कनेक्टेड एप्लिकेशनों द्वारा स्वीकृत टोकन या सेशन प्राप्त होता है। नेटवर्क एक्सेस अक्सर विभिन्न नियंत्रणों का उपयोग करता है, जैसे कि डिवाइस प्रमाणपत्र, वायरलेस प्रमाणीकरण विधियां, डायरेक्टरी-समर्थित नीति, और पोस्चर या ट्रस्ट जांच।
उन्हें जो जोड़ता है वह पहचान स्रोत है। यदि Microsoft Entra ID या Okta पहले से ही जानता है कि उपयोगकर्ता कौन है, वे किस समूह से संबंधित हैं, और क्या उनका डिवाइस प्रबंधित है, तो आप उस पहचान संदर्भ का उपयोग यह तय करने के लिए कर सकते हैं कि उन्हें कर्मचारी नेटवर्क में शामिल होना चाहिए या नहीं।
कॉर्पोरेट WiFi पर यह कैसा दिखता है
एक परिपक्व डिज़ाइन में, कर्मचारी साझा WiFi पासवर्ड बिल्कुल भी टाइप नहीं करते हैं। उनका संगठन द्वारा प्रबंधित डिवाइस नामांकित, विश्वसनीय और उनकी पहचान से संबद्ध होता है। जब वे भवन में प्रवेश करते हैं, तो डिवाइस प्रमाणपत्र-आधारित या समकक्ष एंटरप्राइज़ प्रमाणीकरण का उपयोग करके उपयुक्त सुरक्षित SSID से कनेक्ट हो जाता है।
इससे परिचालन के स्तर पर बहुत कुछ बदल जाता है:
- साझा किए गए पासवर्ड समाप्त हो जाते हैं, इसलिए एक लीक हुआ क्रेडेंशियल पूरे कार्यबल नेटवर्क को प्रभावित नहीं करता है।
- पहुँच भूमिका-जागरूक (रोल-अवेयर) बन जाती है, क्योंकि पॉलिसी पहचान समूहों (आइडेंटिटी ग्रुप्स) का अनुसरण कर सकती है।
- निरसन (रिवोकेशन) तेज़ हो जाता है, क्योंकि जब डायरेक्टरी एक्सेस बदलता है, तो नेटवर्क एक्सेस भी उसके साथ बदल सकता है।
- रोमिंग आसान हो जाती है, विशेष रूप से मल्टी-साइट एस्टेट में जहाँ उपयोगकर्ता हर जगह एक ही अनुभव की उम्मीद करते हैं।
आतिथ्य (hospitality), रिटेल और स्वास्थ्य सेवा में यह क्यों महत्वपूर्ण है
ये क्षेत्र कठिन और विशिष्ट परिस्थितियों (edge cases) से भरे हैं। आपके पास शिफ्ट वर्कर, साझा डिवाइस, एजेंसी कर्मचारी, घूमने वाली टीमें और कॉर्पोरेट, अर्ध-कॉर्पोरेट व अतिथि एक्सेस आवश्यकताओं का लगातार मिश्रण होता है।
एक होटल समूह चाह सकता है कि एक स्टाफ पहचान सभी संपत्तियों में PMS एक्सेस, बैक-ऑफिस ऐप्स और सुरक्षित आंतरिक WiFi को नियंत्रित करे। एक रिटेल चेन चाह सकती है कि प्रबंधित हैंडहेल्ड डिवाइस स्वचालित रूप से स्टोर WiFi से जुड़ें जबकि अतिथि ट्रैफ़िक अलग रहे। एक स्वास्थ्य सेवा प्रदाता नैदानिक उपयोगकर्ताओं, आगंतुकों और जुड़े उपकरणों के बीच मजबूत अलगाव चाह सकता है।
यही वह जगह भी है जहाँ नेटवर्क एक्सेस कंट्रोल समाधान चर्चा में शामिल होते हैं। वे आइडेंटिटी पॉलिसी को एप्लिकेशन लेयर से नेटवर्क लेयर तक विस्तारित करने में मदद करते हैं।
Purple कहाँ फिट बैठता है
एक व्यावहारिक विकल्प Purple है, जो कर्मचारियों और मल्टी-टेनेंट वातावरण के लिए पहचान-आधारित नेटवर्किंग का समर्थन करता है, जिसमें साझा पासवर्ड पर निर्भर हुए बिना सुरक्षित एक्सेस के लिए Entra ID, Google Workspace, और Okta के साथ एकीकरण शामिल है। इस प्रकार का दृष्टिकोण तब उपयोगी होता है जब आप चाहते हैं कि ऐप पहचान और नेटवर्क पहचान सत्य के एक ही स्रोत से काम करें।
आपके उद्योग में SSO - व्यावहारिक उपयोग के मामले
SSO के मूल्य को देखने का सबसे आसान तरीका दैनिक कार्य को देखना है, आर्किटेक्चर आरेखों को नहीं।
आतिथ्य सत्कार
एक होटल ऑपरेशन्स मैनेजर दिन की शुरुआत एक प्रॉपर्टी पर करता है और उसे दूसरी प्रॉपर्टी पर खत्म करता है। उन्हें दोनों स्थानों पर शेड्यूलिंग, प्रॉपर्टी मैनेजमेंट सिस्टम, शेयर्ड डॉक्यूमेंट्स और इंटरनल WiFi तक पहुँच की आवश्यकता होती है।
SSO के साथ, वह पहचान उनके साथ चलती है। वे एक बार साइन इन करते हैं, और स्वीकृत सिस्टम उस सेशन को पहचान लेते हैं। यदि संगठन नेटवर्क एक्सेस को भी उसी पहचान स्रोत से जोड़ता है, तो उनका प्रबंधित डिवाइस कर्मचारी WiFi से जुड़ जाता है, बिना किसी के ड्यूटी मैनेजर को नवीनतम पासवर्ड टेक्स्ट किए।
रिटेल
एक क्षेत्रीय प्रबंधक टैबलेट लेकर स्टोर में प्रवेश करता है। उन्हें तुरंत सेल्स डैशबोर्ड, स्टॉक टूल्स और आंतरिक संचार ऐप्स की आवश्यकता होती है।
एक खंडित सेटअप में, प्रत्येक पड़ाव का अर्थ एक और लॉगिन संकेत, एक और समाप्त हो चुका पासवर्ड, या सहायता के लिए एक और कॉल हो सकता है। एक पहचान-आधारित मॉडल में, टैबलेट सफाई से प्रमाणित होता है, पहुंच उपयोगकर्ता की भूमिका को दर्शाती है, और स्टोर कर्मचारियों को काम पूरा करने के लिए स्थानीय क्रेडेंशियल साझा नहीं करने पड़ते हैं।
अच्छा SSO पहुंच को अदृश्य नहीं बनाता है। यह वैध पहुंच को अनुमानित बनाता है।
स्वास्थ्य सेवा
एक चिकित्सक अपनी शिफ्ट शुरू करता है और उसे मुख्य प्रणालियों तक त्वरित, नियंत्रित एक्सेस की आवश्यकता होती है। वे दिन के दौरान वर्कस्टेशन, साझा डिवाइस और प्रतिबंधित नेटवर्क सेगमेंट के बीच आ-जा सकते हैं।
यहाँ, SSO स्वीकृत एप्लिकेशनों में बार-बार होने वाले साइन-इन को कम करने में मदद करता है, जबकि पहचान-आधारित नेटवर्क नियंत्रण यह सुनिश्चित करने में मदद करते हैं कि सही उपयोगकर्ता और डिवाइस सही वायरलेस वातावरण से कनेक्ट हों। वह अलगाव मायने रखता है। क्लिनिकल एक्सेस, गेस्ट एक्सेस और डिवाइस एक्सेस सभी को एक ही तरह से नियंत्रित नहीं किया जाना चाहिए।
मल्टी-टेनेंट संपत्तियां और परिसर
छात्र आवासों, व्यावसायिक केंद्रों और मिश्रित उपयोग वाली संपत्तियों में, कर्मचारी और निवासी अक्सर एक ही भौतिक बुनियादी ढांचे पर सह-अस्तित्व में रहते हैं, लेकिन उन्हें कभी भी एक ही एक्सेस मॉडल साझा नहीं करना चाहिए।
कर्मचारियों को भवन प्रणालियों, सहायता उपकरणों और आंतरिक प्रशासनिक ऐप्स की आवश्यकता हो सकती है। निवासियों या किरायेदारों को विश्वसनीय कनेक्टिविटी की आवश्यकता होती है, लेकिन परिचालन प्लेटफार्मों तक पहुंच की नहीं। इस संदर्भ में, पहचान का डिज़ाइन सबसे अधिक मायने रखता है। SSO कार्यबल की पहुंच का समर्थन कर सकता है, जबकि अलग नेटवर्क पहचान नीतियां किरायेदार और अतिथि ट्रैफ़िक को अलग रखती हैं।
SSO कार्यान्वयन और सर्वोत्तम प्रथाएं
एक सफल SSO प्रोजेक्ट की शुरुआत एक निर्णय से होती है: उस पहचान प्रदाता (identity provider) को चुनें जो आपके कंट्रोल प्लेन के रूप में कार्य करेगा। कई संगठनों के लिए यह Microsoft Entra ID या Okta है, क्योंकि वे प्लेटफ़ॉर्म पहले से ही उपयोगकर्ता जीवनचक्र, MFA और डिवाइस नीति के करीब हैं।
रोलआउट चरणबद्ध होना चाहिए। उन एप्लिकेशन्स से शुरुआत करें जो सबसे महत्वपूर्ण हैं और उन यूजर ग्रुप्स से जिन्हें सबसे अधिक लाभ होने की संभावना है। डुप्लिकेट अकाउंट्स को साफ़ करें, रोल ग्रुप्स को ठीक से परिभाषित करें, और दायरा बढ़ाने से पहले सेशन के व्यवहार का परीक्षण करें।
वे नियंत्रण जो सबसे अधिक मायने रखते हैं
कुछ अभ्यास एक अच्छे प्रदर्शन और एक टिकाऊ परिनियोजन (deployment) के बीच अंतर पैदा करते हैं:
- प्राथमिक साइन-इन बिंदु पर MFA की आवश्यकता रखें। यदि एक लॉगिन कई संसाधनों तक पहुंच प्रदान कर सकता है, तो उस लॉगिन को अधिक मजबूत सुरक्षा की आवश्यकता होती है।
- छोड़कर जाने वाले कर्मचारियों की प्रक्रियाओं को तत्काल निरस्तीकरण के इर्द-गिर्द बनाएं। केंद्रीय पहचान तभी मदद करती है जब खाते में बदलाव तेजी से लागू हों।
- भूमिका (role) द्वारा एक्सेस की समीक्षा करें। यदि कोई यह जांच नहीं करता है कि अभी भी किसके पास एक्सेस है, तो SSO के कारण अधिक-अधिकारों को अनदेखा करना आसान हो सकता है।
- IdP व्यवधान के लिए योजना बनाएं। जानें कि यदि आपकी पहचान सेवा अनुपलब्ध है तो क्या होगा और किन प्रणालियों को फ़ॉलबैक हैंडलिंग की आवश्यकता है।
जानें कि कब SSO सही टूल नहीं है
यह बिंदु कई सामान्य स्पष्टीकरणों में छूट जाता है। OneLogin वास्तविक दुनिया के डिप्लॉयमेंट में वर्कफोर्स SSO और गेस्ट या डिवाइस एक्सेस के बीच बढ़ते अंतर को रेखांकित करता है, और सिंगल साइन-ऑन कैसे काम करता है के अपने स्पष्टीकरण में एक उपयोगी खरीदार प्रश्न पूछता है: कब SSO गलत टूल है, और ऐप लॉगिन के बजाय नेटवर्क एक्सेस पर पहचान कब लागू की जानी चाहिए?
यह WiFi डिज़ाइन में मायने रखता है। कर्मचारियों को अक्सर पहचान से जुड़े, नीति-संचालित एक्सेस का उपयोग करना चाहिए। मेहमानों को आम तौर पर कुछ हल्का, सरल और अलग चाहिए होता है। कार्यबल SSO के माध्यम से हर एक्सेस समस्या को जबरन हल करने का प्रयास करने से वहां बाधाएं उत्पन्न होती हैं जहां इसकी आवश्यकता नहीं होती है।
यदि आप एक व्यापक एक्सेस रणनीति के हिस्से के रूप में SSO की समीक्षा कर रहे हैं, तो एक ही बातचीत में ऐप्स, स्टाफ WiFi, गेस्ट ऑनबोर्डिंग, शेयर्ड डिवाइसेस और रिवोकेशन वर्कफ़्लो को शामिल करें। आम तौर पर सबसे बड़ा परिचालन लाभ वहीं दिखाई देता है।
यदि आप ऐप्स, स्टाफ WiFi, गेस्ट ऑनबोर्डिंग, या मल्टी-टेनेंट नेटवर्क पर एक्सेस के बारे में फिर से सोच रहे हैं, तो Purple देखने लायक है। यह पहचान-आधारित नेटवर्किंग प्रदान करता है जो Entra ID, Okta, और Google Workspace जैसे प्लेटफॉर्मों के साथ काम कर सकती है, जिससे टीमों को साझा पासवर्ड और पुराने Captive Portal के स्थान पर कर्मचारियों, मेहमानों और निवासियों के लिए नियंत्रित एक्सेस प्रदान करने में मदद मिलती है।
