SSO और प्रोविज़निंग

सिंगल साइन-ऑन (SSO) से सदस्य अलग Bird पासवर्ड के बजाय आपके आइडेंटिटी प्रोवाइडर के ज़रिए Bird में साइन इन कर सकते हैं। Bird SAML 2.0 और OpenID Connect (OIDC) कनेक्शन सपोर्ट करता है।

इसे सेट अप करना संगठन के Owner का काम है, और इसके नियंत्रण आपके संगठन के Single sign-on पेज पर होते हैं। जिस सदस्य को SSO अनुमति दी गई है, वह Owner हुए बिना भी कनेक्शन प्रबंधित कर सकता है।

व्यक्तिगत Google या GitHub साइन-इन संगठन के SSO से अलग है। देखें लॉगिन, पासवर्ड और MFA।

SSO कैसे काम करता है

एक SSO कनेक्शन एक या अधिक सत्यापित ईमेल डोमेन पर लागू होता है, जैसे yourcompany.com। इन डोमेन के सदस्य आपके आइडेंटिटी प्रोवाइडर से प्रमाणीकरण करते हैं। उनकी Bird अनुमतियाँ फिर भी उनके संगठन और वर्कस्पेस की भूमिकाओं से तय होती हैं।

सेटअप में क्या शामिल है

संगठन का Owner और आइडेंटिटी प्रोवाइडर का एडमिनिस्ट्रेटर मिलकर सेटअप पूरा करते हैं:

1. साबित करें कि डोमेन आपका है। कनेक्शन में शामिल हर ईमेल डोमेन के लिए Bird आपको प्रकाशित करने हेतु एक DNS रिकॉर्ड देता है। डोमेन सत्यापित होने तक SSO अनिवार्य नहीं किया जा सकता।
2. कनेक्शन कॉन्फ़िगर करें। SAML के लिए आइडेंटिटी प्रोवाइडर का मेटाडेटा दें, या साइन-इन URL और साइनिंग सर्टिफ़िकेट दें। OIDC के लिए issuer और क्लाइंट क्रेडेंशियल दें। Bird के सर्विस प्रोवाइडर या रीडायरेक्ट विवरण अपने आइडेंटिटी प्रोवाइडर में कॉपी करें।
3. कनेक्शन का परीक्षण करें। कनेक्शन सक्रिय करने से पहले एक परीक्षण साइन-इन पूरा करें। आपने चाहे कोई भी प्रोटोकॉल चुना हो, जिस ड्राफ़्ट का परीक्षण सफल होता है वह आपके लिए अपने-आप सक्रिय हो जाता है, बशर्ते आपके संगठन के पास एक सत्यापित डोमेन हो और वह सक्रिय कनेक्शनों की अपनी सीमा से नीचे हो।
4. तय करें कि SSO अनिवार्य करना है या नहीं। जब SSO वैकल्पिक होता है, तो सदस्य SSO या कोई अन्य उपलब्ध साइन-इन तरीका इस्तेमाल कर सकते हैं। जब यह अनिवार्य होता है, तो संगठन तक पहुँचने के लिए सदस्यों को SSO पूरा करना होता है। SSO अनिवार्य करने के लिए एक सक्रिय कनेक्शन और कम से कम एक सत्यापित डोमेन ज़रूरी है।

SSO अनिवार्य करना तुरंत और हर अनुरोध पर लागू होता है, सिर्फ़ अगले साइन-इन पर नहीं। जिस सदस्य का मौजूदा सेशन आपके आइडेंटिटी प्रोवाइडर के ज़रिए नहीं बना था, वह तब तक संगठन तक पहुँच खो देता है जब तक वह उसके ज़रिए फिर से साइन इन नहीं करता। इसलिए यह बदलाव बाद में घोषित करने के बजाय अपनी टीम के कामकाजी दिन को ध्यान में रखकर तय करें। संगठन के Owner इसका अपवाद हैं: Owner अपने Bird पासवर्ड से पहुँच बनाए रखता है, और इसी वजह से गलत तरीके से कॉन्फ़िगर किया गया कनेक्शन सभी को बाहर नहीं कर पाता।

अपना आइडेंटिटी प्रोवाइडर सेट अप करें

चरण 2 वह हिस्सा है जो हर प्रोवाइडर में अलग होता है: एक ही मान का नाम हर प्रोवाइडर में अलग होता है, और हर प्रोवाइडर में एक ऐसी सेटिंग होती है जो गलत होने पर हर साइन-इन को अस्वीकार कर देती है। Bird के अपने फ़ील्ड नाम कनेक्शन पेज पर Register these with your identity provider के नीचे दिए होते हैं।

• Okta के साथ SSO सेट अप करें
• Google Workspace के साथ SSO सेट अप करें
• Microsoft Entra ID के साथ SSO सेट अप करें

किसी भी अन्य SAML 2.0 या OpenID Connect प्रोवाइडर के लिए ऊपर दिए गए चार चरण ही पूरी प्रक्रिया हैं।

प्लेसहोल्डर मानों के बिना SAML सेट अप करना

SAML कनेक्शन का Entity ID और Assertion Consumer Service URL कनेक्शन से ही बनते हैं, इसलिए कनेक्शन बनाने से पहले वे मौजूद नहीं होते। इससे एक चक्र बनता है: आपके आइडेंटिटी प्रोवाइडर को इन मानों की ज़रूरत होती है, और इन मानों के लिए कनेक्शन ज़रूरी है।

पहले कनेक्शन बनाएँ। Add connection में SAML चुनें और फिर I have not set up my provider yet चुनें। कनेक्शन बिना आइडेंटिटी प्रोवाइडर विवरण के ड्राफ़्ट के रूप में बनता है, और उसे खोलने पर Register these with your identity provider के नीचे वे मान दिखते हैं जिन्हें आपको रजिस्टर करना है। इन मानों से अपना प्रोवाइडर कॉन्फ़िगर करें, फिर वापस आकर उसी कनेक्शन पर Supply the details का इस्तेमाल करें, और विवरण उस रूप में दें जिसमें वे आपके पास हैं:

• एक मेटाडेटा URL, जिसे हम फ़ेच करके पढ़ते हैं
• स्वयं मेटाडेटा दस्तावेज़, उस प्रोवाइडर के लिए जो फ़ाइल होस्ट करने के बजाय उसे डाउनलोड के लिए देता है
• एंटिटी ID, साइन-इन URL और साइनिंग सर्टिफ़िकेट, जिन्हें आप सीधे दर्ज करते हैं

अपलोड किए गए दस्तावेज़ से केवल ये तीन मान पढ़े जाते हैं, और दस्तावेज़ संग्रहीत नहीं किया जाता।

जब तक विवरण नहीं मिलते, कनेक्शन ड्राफ़्ट ही रहता है: उससे कोई साइन-इन नहीं होता और उसे सक्रिय नहीं किया जा सकता।

सदस्यों की पहचान कैसे होती है

SAML कनेक्शन हर सदस्य की पहचान उस NameID से करता है जो आपका प्रोवाइडर भेजता है, और साइन इन करने वाले हर व्यक्ति के लिए यह पहचानकर्ता स्थायी होता है। कनेक्शन सेट अप करते समय आपसे फ़ॉर्मेट नहीं पूछा जाता। अगर आपने मेटाडेटा URL या दस्तावेज़ दिया है, तो हम पढ़ते हैं कि आपका प्रोवाइडर वहाँ कौन-सा फ़ॉर्मेट बताता है, और कनेक्शन को उसी पर आधारित करते हैं। अगर आपने विवरण हाथ से दर्ज किए हैं, तो पढ़ने के लिए कोई मेटाडेटा नहीं होता, इसलिए कनेक्शन एक स्थायी ID पर आधारित होता है।

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

मेटाडेटा बताता है कि आपका प्रोवाइडर क्या भेज सकता है; उसका एप्लिकेशन कॉन्फ़िगरेशन तय करता है कि वह असल में क्या भेजता है, और ये दोनों अलग हो सकते हैं। इसलिए चरण 3 का टेस्ट साइन-इन बताता है कि असर्शन में वास्तव में कौन-सा पहचानकर्ता और फ़ॉर्मेट आया। इसी रिपोर्ट से आप जाँचते हैं कि कनेक्शन पर किसी के निर्भर होने से पहले दोनों मेल खाते हैं। हम ऐसा पहचानकर्ता भी अस्वीकार करते हैं जिस पर persistent लिखा हो लेकिन वह असल में ईमेल पता हो।

अगर टेस्ट ऐसा फ़ॉर्मेट दिखाता है जिसकी आपको उम्मीद नहीं थी, तो उसे ठीक करने के दो तरीके हैं। सही तरीका इस पर निर्भर करता है कि गड़बड़ी कहाँ है:

• प्रोवाइडर गलत मान भेज रहा है। अपने प्रोवाइडर पर एप्लिकेशन यूज़रनेम बदलें, फिर दोबारा टेस्ट करें। आम तौर पर यही सही समाधान है, क्योंकि अपारदर्शी पहचानकर्ता ही रखने लायक होता है।
• कनेक्शन गलत मान पर आधारित है। कनेक्शन पर Edit खोलें और NameID फ़ॉर्मेट को वही चुनें जो आपका प्रोवाइडर भेजता है।

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

प्रोवाइडर बदलना

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

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

आपकी टीम के लिए क्या बदलता है

कोई कनेक्शन किसी सदस्य को उसके पहले सफल SSO साइन-इन पर डिफ़ॉल्ट संगठन और वर्कस्पेस एक्सेस दे सकता है। यह डिफ़ॉल्ट एक्सेस स्पष्ट रूप से कॉन्फ़िगर करें। अन्यथा सदस्यों के साइन इन करने से पहले उन्हें आमंत्रित करें और भूमिकाएँ सौंपें। उपयोगकर्ता, टीमें और भूमिकाएँ देखें।

किसी कनेक्शन को निलंबित करने पर उसके ज़रिए नए साइन-इन रुक जाते हैं। जब कोई आपकी कंपनी छोड़े, तो Bird सदस्यताओं और सक्रिय सेशन की अलग से समीक्षा करें।

अगले कदम

• लॉगिन, पासवर्ड और MFA: व्यक्तिगत खाते की सुरक्षा, जिसमें व्यक्तिगत Google/GitHub साइन-इन भी शामिल है
• उपयोगकर्ता, टीमें और भूमिकाएँ: सदस्यों के जुड़ने के बाद भूमिकाएँ और अनुमतियाँ कैसे काम करती हैं
• ऑथेंटिकेशन और API कुंजियाँ: डेवलपर्स के लिए ऑथेंटिकेशन संदर्भ