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 रिकॉर्ड देता है। डोमेन सत्यापित होने तक एनफ़ोर्समेंट चालू नहीं किया जा सकता।
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 उपयोग करें, जिस भी रूप में आपके पास हों:

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

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

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

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

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

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

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

अगर टेस्ट कोई अप्रत्याशित फ़ॉर्मेट रिपोर्ट करता है, तो आपके पास इसे ठीक करने के दो तरीके हैं, और कौन-सा सही है यह इस पर निर्भर करता है कि गलती क्या है:

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

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

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

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

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

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

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

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

अगले कदम

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