SSO के बारे में जानकारी: एंटरप्राइज आइडेंटिटी और पासवर्डलेस WiFi

2021 तक, यूके सरकार के पास लगभग 121 अलग-अलग सिंगल साइन-ऑन समाधान थे, जो यह दर्शाता है कि SSO केवल एक सुविधा से कहीं अधिक क्यों है। SSO फ़ेडरेटेड आइडेंटिटी समेकन (consolidation) है: यह एक विश्वसनीय आइडेंटिटी प्रदाता के माध्यम से ऑथेंटिकेशन को केंद्रीकृत करता है, जबकि प्रत्येक एप्लिकेशन इस बात पर नियंत्रण रखता है कि एक ऑथेंटिकेटेड उपयोगकर्ता को क्या करने का अधिकार है।

आप इस समस्या को अपने सामान्य कार्य दिवस से पहचान सकते हैं। कर्मचारियों के एक सदस्य को ईमेल, एक क्लाउड एप्लिकेशन, एक संपत्ति प्रबंधन प्रणाली, आंतरिक WiFi और एक प्रशासनिक पोर्टल की आवश्यकता होती है। प्रत्येक सेवा का अपना लॉगिन, पासवर्ड नीति और खाता स्वामी होता है। जब कोई शामिल होता है, भूमिका बदलता है या छोड़ता है, तो प्रशासकों को कई प्रणालियों को अपडेट करना होगा, और उपयोगकर्ताओं को याद रखना होगा कि कौन से क्रेडेंशियल किस सेवा के हैं।

यही वह व्यावहारिक कारण है जिससे संगठन SSO की व्याख्या खोजते हैं। सवाल केवल लॉगिन स्क्रीन की संख्या को कम करने का नहीं है। सवाल यह है कि एप्लिकेशन-स्तरीय अनुमतियों को कमजोर किए बिना या एक अधिक खतरनाक केंद्रीय लक्ष्य बनाए बिना एक विश्वसनीय पहचान नियंत्रण तल (identity control plane) कैसे बनाया जाए।

खंडित पहचान वास्तव में एक्सेस संबंधी समस्याएं क्यों उत्पन्न करती है

UK सरकार का अनुभव एक उपयोगी शुरुआती बिंदु प्रदान करता है। एक 2021 GOV.UK सेवा-मानक समीक्षा ने अनुमान लगाया कि केंद्रीय सरकार के पास लगभग 121 विभिन्न SSO समाधान थे क्योंकि सेवा टीमों ने एक साझा सरकार-व्यापी पहचान मंच का उपयोग करने के बजाय अलग-अलग प्रमाणीकरण प्रणाली बनाई थी। इसलिए कई सार्वजनिक सेवाओं का उपयोग करने वाले लोगों के पास साइन-इन विवरण के कई सेट हो सकते थे और वे नहीं जानते होंगे कि किसी विशिष्ट लेनदेन के लिए किस खाते की आवश्यकता थी। (UK सरकार प्रमाणीकरण और डिजिटल पहचान समीक्षा)

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

प्रमाणीकरण (Authentication) और प्राधिकरण (Authorisation) अलग-अलग कार्य हैं

प्रमाणीकरण (Authentication) उत्तर देता है, "आप कौन हैं?" प्राधिकरण (Authorisation) उत्तर देता है, "आप यहाँ क्या एक्सेस कर सकते हैं?" SSO एक विश्वसनीय पहचान प्रदाता (identity provider) के माध्यम से पहले प्रश्न को समेकित करता है। लक्षित एप्लिकेशन अभी भी यह तय करता है कि वह पहचान रिकॉर्ड देख सकती है, किसी सिस्टम का प्रशासन कर सकती है, नेटवर्क सेगमेंट में शामिल हो सकती है या किसी विशेष सुविधा का उपयोग कर सकती है या नहीं।

एक उपयोगी मानसिक मॉडल इस प्रकार है:

उपयोगकर्ता
  |
  | एक बार प्रामाणिक होता है
  v
आइडेंटिटी प्रोवाइडर
  |
  | विश्वसनीय पहचान जानकारी भेजता है
  v
एप्लिकेशन या नेटवर्क
  |
  | स्थानीय अनुमतियां लागू करता है
  v
अधिकृत सत्र

यह अंतर नए कर्मचारियों के जुड़ने, स्थानांतरण और कार्य छोड़ने (joiner, mover, leaver) की प्रक्रियाओं के दौरान महत्वपूर्ण होता है। जब कोई व्यक्ति संस्था छोड़ता है तो एक केंद्रीय पहचान को अक्षम किया जा सकता है, जबकि प्रत्येक कनेक्टेड सेवा को अभी भी एक स्पष्ट प्राधिकरण मॉडल और अधिकार हटाने के विश्वसनीय तरीके की आवश्यकता होती है।

व्यावहारिक नियम: SSO को पहचान को केंद्रीय रूप से नियंत्रित करने के एक तरीके के रूप में देखें, न कि एप्लिकेशन अनुमतियों के विकल्प के रूप में।

वही सिद्धांत वायरलाइन और वायरलेस परिनियोजन (wireline and wireless deployment) को डिज़ाइन करते समय लागू होता है। नेटवर्क एक्सेस पहचान संपत्ति का हिस्सा है, इसलिए टीमों को यह तय करना चाहिए कि कौन से डायरेक्टरी समूह किन नेटवर्क भूमिकाओं तक पहुंच सकते हैं, न कि किसी साझा पासवर्ड से एक्सेस को जोड़ना चाहिए।

स्टाफ WiFi और आइडेंटिटी-अवेयर एक्सेस के लिए, Purple की आइडेंटिटी-आधारित नेटवर्किंग यह दर्शाती है कि नेटवर्क नीति को किसी सामान्य क्रेडेंशियल के बजाय व्यक्तिगत पहचान से कैसे जोड़ा जा सकता है। इसका परिणाम किसी व्यक्ति, उसकी डायरेक्टरी स्थिति और उसे मिलने वाली एक्सेस के बीच एक स्पष्ट संबंध के रूप में सामने आता है।

एंटरप्राइज फ़ेडरेशन में Single Sign-On कैसे काम करता है

एक एंटरप्राइज फ़ेडरेशन में, एक पहचान प्रदाता (identity provider), एक भरोसा करने वाला पक्ष (relying party) और एक हस्ताक्षरित पहचान संदेश अलग-अलग कार्य करते हैं। पहचान प्रदाता उपयोगकर्ता को प्रमाणित करता है, जबकि भरोसा करने वाला पक्ष, जैसे कि कोई एप्लिकेशन या नेटवर्क सेवा, परिणामी पहचान जानकारी को सत्यापित करता है।

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

फ़ेडरेशन फ़्लो

1. उपयोगकर्ता किसी सेवा का अनुरोध करता है। वे एक एप्लिकेशन, प्रशासनिक पोर्टल या संरक्षित नेटवर्क सेवा खोलते हैं।
2. सेवा मौजूदा सत्र की जांच करती है। इसके बिना, यह उपयोगकर्ता को पहचान प्रदाता पर पुनर्निर्देशित करती है।
3. पहचान प्रदाता उपयोगकर्ता को प्रमाणित करता है। यह कॉन्फ़िगर किए गए नियंत्रण लागू करता है, जैसे MFA या सशर्त एक्सेस।
4. पहचान प्रदाता एक हस्ताक्षरित संदेश जारी करता है। एकीकरण आमतौर पर SAML एसेर्शन या OpenID Connect टोकन का उपयोग करता है।
5. सेवा संदेश को मान्य करती है। यह जारीकर्ता, हस्ताक्षर, दर्शक, समाप्ति और प्रासंगिक दावों की जांच करती है।
6. एप्लिकेशन अपना स्वयं का सत्र बनाता है। यह सत्यापित पहचान को स्थानीय अनुमतियों से मैप करता है और प्रमाणीकरण घटना को रिकॉर्ड करता है।

सत्यापन विश्वास संबंध की रक्षा करता है। UK National Cyber Security Centre सलाह देता है कि अविश्वसनीय नेटवर्क पर प्राप्त SAML दावों की जांच अपेक्षित प्रमाण पत्र प्राधिकरण के विरुद्ध की जानी चाहिए। एक असत्यापित दावा एक विश्वसनीय पहचान प्रदाता कनेक्शन के माध्यम से खाता अधिग्रहण का मार्ग प्रदान कर सकता है। (पहचान और पहुंच प्रबंधन पर NCSC मार्गदर्शन)

एक मान्य आइडेंटिटी जांच केवल एक ऑथेंटिकेटेड पहचान प्रदान करती है, न कि टारगेट सेवा में हर अनुमति। एप्लिकेशन को केवल ऑथराइजेशन के लिए आवश्यक दावों का उपयोग करना चाहिए, फिर अपने स्वयं के रोल और संसाधन नियमों को लागू करना चाहिए। यह पृथक्करण एक ही फ़ेडरेशन पैटर्न को स्टाफ एप्लिकेशन्स, प्रशासनिक पोर्टल्स और आइडेंटिटी-अवेयर नेटवर्क सेवाओं का समर्थन करने की अनुमति भी देता है।

एंटरप्राइज संदर्भ में SAML, OIDC, और OAuth

एक बार जब फ़ेडरेशन मॉडल स्पष्ट हो जाता है, तो प्रोटोकॉल का चयन करना आसान हो जाता है। SAML और OpenID Connect एंटरप्राइज SSO के लिए सामान्य मानक हैं, जबकि OAuth मुख्य रूप से API तक प्रतिनिधि पहुंच (delegated access) के लिए एक ऑथराइजेशन ढांचा है। OAuth को ऑथेंटिकेशन समझने की भूल करने से टीमें एक ऐसी आइडेंटिटी फ़्लो का निर्माण कर सकती हैं जो उनके सुरक्षा प्रश्नों का उत्तर नहीं देती है।

मानक	व्यावहारिक भूमिका	विशिष्ट उपयुक्तता
SAML	हस्ताक्षरित पहचान दावों का आदान-प्रदान करता है	स्थापित एंटरप्राइज और ब्राउज़र-आधारित एप्लिकेशन
OpenID Connect	टोकन का उपयोग करके एक पहचान परत जोड़ता है	आधुनिक SaaS, वेब और मोबाइल-उन्मुख सेवाएं
OAuth	सुरक्षित संसाधनों तक पहुंच प्रदान करता है	किसी उपयोगकर्ता या सेवा की ओर से API पहुंच

SAML अक्सर परिपक्व एंटरप्राइज सॉफ़्टवेयर में दिखाई देता है क्योंकि यह एक अच्छी तरह से स्थापित ब्राउज़र फ़ेडरेशन मॉडल का उपयोग करता है। OIDC आमतौर पर JSON, REST और टोकन-आधारित इंटरैक्शन के आसपास डिज़ाइन की गई आधुनिक सेवाओं के लिए अधिक स्वाभाविक है। सही विकल्प इस बात पर निर्भर करता है कि एप्लिकेशन किसका समर्थन करता है और सेवा पहचान जानकारी को कैसे सत्यापित करती है।

सेवा को क्या सत्यापित करना चाहिए

मानक चाहे जो भी हो, भरोसा करने वाले पक्ष (relying party) को सत्र बनाने से पहले प्राप्त पहचान सामग्री को सत्यापित करना होगा। मुख्य जांचों में शामिल हैं:

• जारीकर्ता: पुष्टि करें कि संदेश अपेक्षित पहचान प्रदाता से आया है।
• हस्ताक्षर: सत्यापित करें कि संदेश पर विश्वसनीय कुंजी या प्रमाण पत्र द्वारा हस्ताक्षर किए गए थे।
• दर्शक: जांचें कि संदेश इसी सेवा के लिए लक्षित था।
• समाप्ति: पुराने दावों या टोकन को अस्वीकार करें।
• दावे: केवल प्रासंगिक, सत्यापित पहचान और समूह जानकारी का उपयोग करें।

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

Microsoft Entra ID, Okta या Google Workspace जैसे प्लेटफॉर्म को एकीकृत करते समय वह पृथक्करण उपयोगी होता है। प्रदाता प्रमाणीकरण नीति को संभालता है, जबकि कनेक्टेड एप्लिकेशन अपने एक्सेस मॉडल और सत्र नियंत्रण के लिए जिम्मेदार रहता है। RADIUS-आधारित एक्सेस के लिए Okta एकीकरण का मूल्यांकन करने वाले नेटवर्क ऑपरेटरों के लिए भी यही सिद्धांत लागू होता है: पहचान सत्यापन और नेटवर्क प्राधिकरण को एक साथ काम करना चाहिए, लेकिन वे एक ही नियंत्रण नहीं हैं।

SSO द्वारा उत्पन्न होने वाला एकाग्रता जोखिम (Concentration Risk)

एक अकेला समझौता किया गया पहचान-प्रदाता खाता एक साथ कई कनेक्टेड सेवाओं को खोल सकता है। SSO पासवर्ड के प्रसार को कम करता है, जबकि पहचान प्रदाता में विश्वास को केंद्रित करता है, जिससे यह एक उच्च-मूल्य वाला नियंत्रण तल (हाई-वैल्यू कंट्रोल प्लेन) बन जाता है। इसलिए संगठनों को यह आकलन करने की आवश्यकता है कि महासंघ (फ़ेडरेशन) उनके ब्लास्ट रेडियस और रिकवरी विकल्पों को कैसे प्रभावित करता है। प्रमाणीकरण विधियों को चुनने पर NCSC मार्गदर्शन विश्वास के इस एकाग्रता को एक जोखिम के रूप में रेखांकित करता है जिसके लिए जानबूझकर मूल्यांकन की आवश्यकता होती है।

SSO साइन-इन घटनाओं को समेकित करता है। फ़िशिंग प्रतिरोध, डिवाइस विश्वास और न्यूनतम-विशेषाधिकार एक्सेस फ़ेडरेशन आर्किटेक्चर के आसपास स्थापित नियंत्रणों से आना चाहिए। एक मजबूत डिज़ाइन प्रदाता, उसके द्वारा बनाए जाने वाले सत्रों और एक्सेस को पुनर्स्थापित करने वाली रिकवरी प्रक्रियाओं की सुरक्षा करता है।

प्रदाता के चारों ओर परतें बनाएं

नियंत्रणों में नियमित साइन-इन और खाता पुनर्प्राप्ति के दौरान उपयोग किए जाने वाले कम दिखाई देने वाले पथ शामिल होने चाहिए:

• विशेषाधिकार प्राप्त उपयोगकर्ताओं के लिए मजबूत MFA: जहाँ वातावरण उनका समर्थन करता है, वहाँ फ़िशिंग-प्रतिरोधी तरीकों का उपयोग करें, विशेष रूप से प्रशासकों के लिए।
• सशर्त पहुँच: पहुँच प्रदान करने से पहले डिवाइस की स्थिति, स्थान, सत्र जोखिम और अन्य उपलब्ध संकेतों का आकलन करें।
• अलग प्रशासक पहचानें: विशेषाधिकार प्राप्त प्रशासन को सामान्य दिन-प्रतिदिन की गतिविधि से अलग रखें।
• प्रमाणीकरण निगरानी: असंभव यात्रा, टोकन-रीप्ले संकेतकों, बार-बार विफलताओं और अप्रत्याशित विशेषाधिकार वृद्धि की जांच करें।
• रिकवरी सुरक्षा: हेल्प-डेस्क रीसेट और आपातकालीन खातों को अनुमोदन और निगरानी के साथ संवेदनशील पहचान संचालन के रूप में मानें।

NCSC MFA या सशर्त पहुंच सहित मजबूत उपयोगकर्ता और उपकरण प्रमाणीकरण के साथ एंटरप्राइज SSO को जोड़ने की सिफारिश करता है। यह SaaS के लिए SSO की भी सिफारिश करता है क्योंकि केंद्रीकृत नियंत्रण उपयोगकर्ता और समूह प्रबंधन को अधिक सुसंगत बनाते हैं और क्रेडेंशियल्स को हर एप्लिकेशन में सिंक होने से रोकते हैं। पहचान और प्रमाणीकरण पर इसका क्लाउड सुरक्षा सिद्धांत इस दृष्टिकोण को निर्धारित करता है।

SSO उन क्रेडेंशियल्स की संख्या को कम करता है जिन्हें आपको नियंत्रित करना होता है। यह कनेक्टेड सेवाओं को नियंत्रित करने वाले क्रेडेंशियल और सत्र को छोड़ देता है जिसके लिए मजबूत सुरक्षा की आवश्यकता होती है।

नेटवर्क टीमों को कार्यबल की पहचान को अतिथि पहचान से अलग रखना चाहिए। एक कर्मचारी फ़ेडरेशन न्यूनतम-विशेषवाधिकार पहुंच (least-privilege access) और तत्काल निरसन का समर्थन कर सकता है। अतिथि प्रमाणीकरण को केवल इसलिए कर्मचारी डायरेक्टरी विशेषाधिकार विरासत में नहीं मिलने चाहिए क्योंकि दोनों फ़्लो Captive Portal या वायरलेस इंफ्रास्ट्रक्चर का उपयोग करते हैं।

पासवर्ड रहित WiFi और निर्देशिका-आधारित नेटवर्क एक्सेस

WiFi से जुड़ने वाले कर्मचारी सदस्य को ऐसे साझा पासवर्ड की आवश्यकता नहीं होनी चाहिए जो उनके जाने के बाद भी मान्य रहे। डायरेक्टरी समर्थित डिज़ाइन संगठन के पहचान प्रदाता के माध्यम से प्रमाणीकरण के साथ शुरू होता है, फिर सत्यापित पहचान या समूह को नेटवर्क भूमिका में मैप करता है। इसलिए वायरलेस सेवा अलग से WiFi पासवर्ड की सूची बनाए रखने के बजाय अन्यत्र उपयोग किए जाने वाले रोजगार और पहुंच निर्णयों को लागू करती है।

Purple Microsoft Entra ID, Google Workspace और Okta के साथ एकीकरण के माध्यम से एंटरप्राइज WiFi के लिए इस मॉडल का समर्थन करता है। इसका passwordless WiFi दृष्टिकोण साझा क्रेडेंशियल्स और ऑन-प्रेमिस RADIUS प्रबंधन से बचाता है। डायरेक्टरी में परिवर्तन प्रोविजनिंग या निरसन को ट्रिगर कर सकते हैं। एक कर्मचारी की समूह सदस्यता नेटवर्क पहुंच निर्धारित करती है, जबकि संस्थान छोड़ने वाले के डायरेक्टरी खाते को निष्क्रिय करने से किसी सामान्य पासवर्ड को बदलने की प्रतीक्षा किए बिना वह पहुंच समाप्त हो सकती है।

नेटवर्क पर फ़ेडरेशन नियंत्रण लागू करें

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

सफल और विफल प्रमाणीकरण घटनाओं को रिकॉर्ड करें, और प्रत्येक पहचान निर्णय को परिणामी नेटवर्क प्राधिकरण के साथ जोड़ें। समाप्ति से पहले प्रमाणपत्र रोलओवर का परीक्षण करें, क्योंकि फेडरेशन ट्रस्ट की विफलताएं अन्यथा सुचारू WiFi पहुंच को बाधित कर सकती हैं।

मल्टी-टेनेंट साइटों को एक अलग सीमा की आवश्यकता होती है। आवासीय संपत्तियां, छात्र आवास, होटल और मिश्रित उपयोग वाले स्थान किरायेदारों का ट्रैफिक और कर्मचारियों के सिस्टम को अलग रखते हुए निवासियों या मेहमानों को आसान पहुंच प्रदान कर सकते हैं। iPSK विरासत (legacy) उपकरणों का समर्थन कर सकता है, जबकि कार्यबल SSO एक अलग कर्मचारी पहचान मार्ग प्रदान करता है।

गेस्ट WiFi सहमति, डेटा प्रतिधारण (retention) और ग्राहक प्रोफ़ाइल के बारे में भी निर्णय उत्पन्न करता है। स्थल नेटवर्किंग डिज़ाइन के साथ-साथ स्थानों के लिए गेस्ट डेटा की यह गाइड एक उपयोगी संदर्भ प्रदान करती है, जबकि Purple आइडेंटिटी-आधारित ऑथेंटिकेशन को वायरलेस एक्सेस अनुभव से जोड़ता है।

UK उद्यमों और स्थानों के लिए मापने योग्य परिणाम

एक व्यावहारिक SSO बिजनेस केस उन क्रेडेंशियल्स से शुरू होता है जिन्हें अब किसी संगठन को प्रबंधित करने की आवश्यकता नहीं है। 16 वर्ष और उससे अधिक आयु के 2,000 UK निवासियों के अप्रैल 2024 के इंस्टीट्यूट ऑफ इंजीनियरिंग एंड टेक्नोलॉजी सर्वेक्षण में पाया गया कि केवल 20% ही सुरक्षित पासवर्ड की सही पहचान कर सके। उसी सर्वेक्षण में रिपोर्ट किया गया कि पांचवें हिस्से ने कई वेबसाइटों या उपकरणों में एक ही पासवर्ड का पुन: उपयोग किया, जबकि 21% ने एक महत्वपूर्ण तारीख का उपयोग किया और 20% ने एक पालतू जानवर के नाम का उपयोग किया। इसमें यह भी पाया गया कि 38% का मानना था कि अक्षरों को संख्याओं से बदलने से पासवर्ड सुरक्षा में सुधार होता है, 65% का मानना था कि पासवर्ड कभी नहीं लिखा जाना चाहिए, और 77% का मानना था कि बार-बार पासवर्ड बदलने से सुरक्षा बढ़ती है। (IET पासवर्ड सुरक्षा सर्वेक्षण)

ये निष्कर्ष उपयोगकर्ताओं से हर एप्लिकेशन और नेटवर्क के लिए अलग-अलग क्रेडेंशियल बनाने और याद रखने के लिए कहने की सीमाओं को दर्शाते हैं। केंद्रीकृत पहचान यह बदल देती है कि संगठन कहाँ नियंत्रण लागू करता है और प्रशासक कितनी जल्दी कार्रवाई कर सकते हैं, भले ही फ़िशिंग और खाता समझौता (account compromise) सक्रिय जोखिम बने रहें।

एक ऑपरेटर के लिए, परिणाम व्यावहारिक होते हैं:

• कम अप्रबंधित क्रेडेंशियल्स: उपयोगकर्ता कम अलग-अलग एप्लिकेशन पासवर्ड बनाते हैं, याद रखते हैं और उनका पुन उपयोग करते हैं।
• निरंतर नीति: पहचान प्रदाता कनेक्टेड सेवाओं में MFA, सशर्त पहुँच और पासवर्ड प्रतिबंध लागू कर सकता है।
• तेज़ी से निरस्तीकरण: किसी संगठनात्मक पहचान को अक्षम करना केंद्रीय पहुँच हटाने की कार्रवाई बन सकता है, बशर्ते कनेक्टेड सेवाएं लाइफसाइकल परिवर्तनों को सही ढंग से प्रोसेस करें।
• स्पष्ट ऑडिट ट्रेल्स: लॉग किसी व्यक्ति की पहचान को प्रमाणीकरण और नेटवर्क प्राधिकरण निर्णयों से जोड़ सकते हैं।
• कम दोहराया गया प्रशासन: टीमें हर सेवा में समतुल्य नियंत्रणों को फिर से बनाने के बजाय केंद्रीय रूप से पहचान नीति को बनाए रखती हैं।

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

नया जोखिम पैदा किए बिना SSO लागू करना

एक सुरक्षित रोलआउट की शुरुआत लॉगिन बटन से नहीं, बल्कि आइडेंटिटी मॉडल से होती है। एप्लिकेशन या नेटवर्क प्लेटफॉर्म में पासवर्ड कॉपी करने के बजाय, जहाँ वे उपयुक्त हों वहाँ SAML या OIDC चुनें। आइडेंटिटी प्रदाता को ऑथेंटिकेशन अथॉरिटी के रूप में स्थापित करें, फिर सेशन बनाने से पहले प्रत्येक कनेक्टेड सेवा से जारीकर्ता (issuer), सिग्नेचर, ऑडियंस, समाप्ति (expiry) और दावों (claims) की पुष्टि करवाएं।

एक परिचालन चेकलिस्ट का उपयोग करें

• प्राधिकृत समूहों के साथ शुरुआत करें: सही व्यवसाय या IT टीम के स्वामित्व वाले निर्देशिका समूहों से एक्सेस का प्रावधान करें।
• मूवर नियमों को परिभाषित करें: भूमिका में बदलाव से पुरानी पात्रताएं हटनी चाहिए और नई जुड़नी चाहिए।
• छोड़ने वालों को केंद्रीय रूप से प्रोसेस करें: सांगठनिक पहचान को अक्षम करें और सत्यापित करें कि कनेक्टेड एप्लिकेशन और नेटवर्क भूमिकाएं सही ढंग से प्रतिक्रिया दे रही हैं।
• ब्रेक-ग्लास एक्सेस को सुरक्षित रखें: आपातकालीन खातों को सामान्य प्रशासन से अलग रखें, उनकी बारीकी से निगरानी करें और उनकी रिकवरी प्रक्रिया का परीक्षण करें।
• कर्मचारियों और मेहमानों को अलग रखें: वर्कफोर्स SSO न्यूनतम-विशेषाधिकार एक्सेस और निरसन का समर्थन कर सकता है। गेस्ट प्रमाणीकरण को कर्मचारी अनुमतियां विरासत में नहीं मिलनी चाहिए।
• ट्रस्ट परिवर्तनों का परीक्षण करें: उत्पादन निर्भरता से पहले प्रमाण पत्र रोलओवर, टोकन समाप्ति, सत्र समाप्ति और प्रदाता आउटेज को मान्य करें।
• निगरानी की समीक्षा करें: पुष्टि करें कि प्रमाणीकरण कार्यक्रम, प्रशासनिक कार्य और नेटवर्क प्राधिकरण निर्णय जांच के लिए उपलब्ध हैं।

किसी स्थान को अपने मौजूदा वायरलेस इंफ्रास्ट्रक्चर को बदलने के बजाय कई नेटवर्क विक्रेताओं का समर्थन करने की भी आवश्यकता हो सकती है। Purple को Meraki, Aruba, Ruckus, Mist और UniFi के साथ काम करने के लिए डिज़ाइन किया गया है, और इसका घोषित परिनियोजन मॉडल महीनों के बजाय हफ्तों में मापा जाता है। उन क्षमताओं को कार्यान्वयन संबंधी विचारों के रूप में देखें, न कि आर्किटेक्चर समीक्षा के विकल्प के रूप में। प्रौद्योगिकी प्रदाता सुरक्षा उपायों का वर्णन कैसे करते हैं, इसके व्यापक दृष्टिकोण के लिए, AdManage.ai's trust and controls एक उपयोगी तुलनात्मक बिंदु प्रदान करता है।

मुख्य निर्णय यह है कि क्या संगठन प्रत्येक कनेक्टेड सेवा के लिए यह स्पष्ट कर सकता है कि उपयोगकर्ता को कौन ऑथेंटिकेट करता है, किन दावों (claims) पर भरोसा किया जाता है, अनुमति कैसे दी जाती है और आइडेंटिटी बदलने पर क्या होता है। SSO आइडेंटिटी और एक्सेस मैनेजमेंट प्रोग्राम की एक परत है। यह MFA, कंडीशनल एक्सेस, ऑथेंटिकेशन मॉनिटरिंग, रिकवरी कंट्रोल या लाइफसाइकिल गवर्नेंस की जगह नहीं लेता है।

---

Purple Microsoft Entra ID, Google Workspace और Okta के साथ एकीकरण का समर्थन करते हुए, वर्कफ़ोर्स आइडेंटिटी को पासवर्ड-रहित WiFi, डायरेक्टरी-आधारित नेटवर्क भूमिकाओं और अलग गेस्ट एक्सेस से जोड़ता है। यह जांचने के लिए Purple पर जाएं कि इसका आइडेंटिटी-आधारित नेटवर्किंग मॉडल आपके मौजूदा वायरलेस वातावरण और SSO रोलआउट में कैसे फिट हो सकता है।