पारदर्शी उपयोगकर्ता सत्र (एकल साइन-ऑन + एकल साइन-बंद)

Question

मैं अलग डोमेन में कई साइटों है: example.com, example.org, mail.example.com और passport.example.org। सभी साइटों में आम दिखने और महसूस हो रहा है और समान उपयोगकर्ता आधार साझा करना चाहिए।

और इस तरह के चरम मामले मैं अभी भी पारदर्शी रूप से को सभी साइटों चाहते कुंजी गुण निम्नलिखित के साथ (जितना संभव हो उतना) उपयोगकर्ता शेयर सत्रों में:

1. एकल साइन-ऑन। में लॉग इन के रूप में वह व्यवहार किया जाना चाहिए

   उपयोगकर्ताओं में लॉग इन मिलता है "नमस्ते, $username" साइट के शीर्षक और विभिन्न नेविगेशन मेनू में अभिवादन, लिस्टिंग सेवाओं वे के लिए उपयोग किया - जब passport.example.org पर पर उपयोगकर्ता चिन्ह और यात्राओं किसी भी अन्य साइट। । अगर वह साइन इन नहीं है, तो ग्रीटिंग के बजाय "साइन ऑन" लिंक है, जो passport.example.org/signon पर इंगित करता है।

   विश्वसनीय डोमेन की सूची ज्ञात है, इसलिए ओपनआईडी के साथ या कुछ होमबर्न हल्के प्रोटोकॉल के साथ को लागू करना काफी आसान है। जब उपयोगकर्ता पहली बार साइट पर हिट करता है, तो मैं उसे passport.example.org, पर विशेष प्रमाणीकरण समापन बिंदु पर रीडायरेक्ट कर रहा हूं, जो तब पहचान जानकारी (या " अज्ञात पहचान पर हस्ताक्षर नहीं किया गया) के साथ चुपचाप उसे वापस रीडायरेक्ट करता है। अधिकांश ब्राउज़रों के लिए यह पूरी तरह से पारदर्शी है। जाहिर है, मैं पुनर्निर्देशन loops से लड़ने के लिए nonce मूल्यों का उपयोग कर रहा हूँ।

2. एकल साइन-ऑफ। जब उपयोगकर्ता किसी भी साइट के शीर्षलेख में "साइन ऑफ़" पर क्लिक करता है अगली बार जब वह किसी भी साइट पर जाता है - उसे "साइन ऑन नहीं" के रूप में देखा जाना चाहिए।

   ओपनआईडी इस के लिए डिज़ाइन नहीं किया गया था। मेरा वर्तमान विचार (मेरे पास पहले से ही आंशिक रूप से काम कर रहा है कार्यान्वयन) उपयोगकर्ता पहचान नहीं भेजना है, बल्कि "वैश्विक" सत्र टोकन और डीबी में वैश्विक सत्र तालिका (global_session_token ↔ उपयोगकर्ता संबंध) साझा करना है।

3. रोबोट और कुकीज-उपयोगकर्ता का समर्थन करते हैं। साइट्स में सार्वजनिक क्षेत्र हैं, जिन्हें किसी भी कुकी समर्थन के बिना उपयोगकर्ता-एजेंटों द्वारा पहुंचा जा सकता है।

   इस वजह से, मैंने (1) में वर्णित पुनर्निर्देशन एक समस्या बन गई है, क्योंकि प्रत्येक पृष्ठ अनुरोध के लिए, मैं उपयोगकर्ता-एजेंट को एंड एंडपॉइंट और पीछे वापस फेंक दूंगा। न केवल यह रोबोट को भ्रमित करेगा, लेकिन यह मेरे सत्र डेटाबेस को मृत-जन्म-सत्र सत्रों के साथ बहुत जल्दी प्रदूषित करेगा। और मैं निश्चित रूप से "हे, प्रदर्शित करना नहीं चाहता हूं, आपके पास कुकीज़ सक्षम नहीं है, चले जाओ!" पृष्ठ, जो बेहद कठोर और निराशाजनक होगा। जबकि मुझे लॉगिन करने के लिए कुकी समर्थन की आवश्यकता है, मैं चाहता हूं कि उपयोगकर्ता बिना किसी प्रतिबंध के साइटें कितनी आसानी से पढ़ सकें।

   और मैं स्पष्ट रूप से कुछ पारदर्शी क्रॉस-डोमेन पुनर्निर्देशन के अलावा यूआरएल में सत्र आईडी डालना चाहता हूं। मुझे विश्वास है कि ऐसा करना एक सुरक्षा समस्या है और आमतौर पर एक बुरी बात है।

   और यहां मैं लगभग विचारों से बाहर हूं।

ठीक है, मैं जानता हूँ कि यह मुश्किल है, लेकिन गूगल वास्तव में साथ किसी भी तरह से करता है (google.com, google.बहुत के- gTLDs, gmail.com और इसी तरह), है ना? तो यह होना चाहिए।

मैं या तो प्रोटोकॉल विवरण विचारों के लिए आभारी (है कि सबसे अच्छा होगा) या लिंक सिस्टम को (या तो कोड को पढ़ने के लिए या सिर्फ देखने और जानने के लिए पर साइटों रहते हैं) पहले से ही सफलतापूर्वक कुछ इस तरह लागू करने होंगे।

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

साइटों की सभी एक ही नेटवर्क पर कर रहे हैं (लेकिन अलग सर्वर पर आराम) और आंशिक रूप से ही PostgreSQL डेटाबेस का हिस्सा (एक ही डाटाबेस की विभिन्न योजनाओं में आराम कर)। अधिकांश साइटें पाइथन/डीजेगो के साथ लिखी जाती हैं, लेकिन उनमें से कुछ रेल पर PHP और रूबी का उपयोग कर रही हैं। जबकि मैं कुछ ढांचे के बारे में सोच रहा हूं- और भाषा-अज्ञेयवादी, मैं किसी भी कार्यान्वयन को इंगित करने के लिए आभारी हूं। यहां तक ​​कि अगर मैं उनका उपयोग नहीं कर पाऊंगा, अगर मुझे यह पता चलेगा कि यह कैसे किया गया है तो शायद मैं कुछ इसी तरह लागू करने में सक्षम हो जाऊंगा।

Answer 1

ठीक है, तो मुझे थोड़ा आगे बताएं। (सभी यूआरएल काल्पनिक हैं!) जैसा कि मैंने कहा, आगंतुक http://www.yourwebpage.com पर जाता है और इंगित करता है कि वह लॉग इन करना चाहता है। उसे http://your.loginpage.org?return=http://www.yourwebpage.com/Authenticated पर रीडायरेक्ट किया गया है जहां उसे अपना उपयोगकर्ता नाम और पासवर्ड देना होगा।
जब उसकी खाता जानकारी मान्य होती है, तो वह लॉगिन पृष्ठ में प्रदान किए गए पृष्ठ पर वापस आ जाएगा, लेकिन अतिरिक्त पैरामीटर के साथ जो आईडी के रूप में उपयोग किया जाएगा। इस प्रकार, वह http://www.yourwebpage.com/Authenticated?ID=SharedSecret पर जाता है जहां साझासेक्रेट एक अस्थायी आईडी होगा, जो 30 सेकंड या उससे कम के लिए मान्य होगा।
जब आपका प्रमाणीकरण पृष्ठ बुलाया जाता है, तब पृष्ठ एक और तरीका को कॉल करेगा जो आपकेwebpage.com और loginpage.org के बीच साझा किया गया है ताकि अधिक स्थायी आईडी पुनर्प्राप्त करने के लिए SharedSecret की खाता जानकारी देखने के लिए साझा किया जा सके। यह स्थायी आईडी yourwebpage.com के वेब सत्र में संग्रहीत है और इसे उपयोगकर्ता को कभी नहीं दिखाया जाना चाहिए।
साझा विधि कुछ भी हो सकती है। यदि दोनों सर्वर एक ही मशीन पर हैं, तो वे दोनों एक ही डेटाबेस तक पहुंच सकते हैं। अन्यथा, वे वेब सेवाओं के माध्यम से किसी अन्य सर्वर के साथ संवाद कर सकते हैं। यह सर्वर-टू-सर्वर संचार होगा, इससे कोई फर्क नहीं पड़ता कि उपयोगकर्ता रोबोट है या कोई कुकी समर्थन नहीं है। इस भाग को उपयोगकर्ता द्वारा नहीं देखा जाएगा।
एकमात्र चीज़ जिसे आप सौदा करना चाहते हैं वह उपयोगकर्ता के लिए सत्र है। आम तौर पर, उपयोगकर्ताओं को एक कुकी आईडी भेजा जाएगा जो एक कुकी में संग्रहीत किया जाता है लेकिन यह जीईटी अनुरोध के हिस्से के रूप में यूआरएल का हिस्सा भी हो सकता है। POST अनुरोध के भीतर सत्र आईडी रखने के लिए यह थोड़ा और सुरक्षित है, हालांकि, आपके फ़ॉर्म में एक छिपी हुई इनपुट फ़ील्ड जोड़कर।

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

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

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

Answer 2

क्या आप ASP.NET का उपयोग कर रहे हैं? यदि ऐसा है, तो आप enableCrossAppRedirects संपत्ति पर एक नज़र रखना चाहेंगे।

Answer 3

AFAIK, Google बस "Google.com" डोमेन के लिए कुकी का उपयोग करता है। लेकिन Google ओपनआईडी का भी उपयोग करता है जो सामान्य लॉगिन तंत्र की अनुमति देता है। असल में, यह आपको एक विशेष लॉगिन पेज पर रीडायरेक्ट करके काम करता है। यह लॉगिन पेज पता लगाएगा कि आप लॉग इन हैं या नहीं और यदि आप लॉग इन नहीं हैं तो यह आपको लॉग इन करने के लिए कहेंगे। अन्यथा, यह आपको सीधे अगले पृष्ठ पर रीडायरेक्ट करता है।

तो, आपके मामले में कोई उपयोगकर्ता somepage.example.com खोल देगा और इस ऐप के सत्र में कोई लॉगिन आईडी नहीं है। इस प्रकार यह उपयोगकर्ता को logon.example.biz पर रीडायरेक्ट करेगा जहां उपयोगकर्ता लॉग इन करेगा। इस पृष्ठ के पीछे भी एक सत्र होगा और वह सत्र बताएगा कि उपयोगकर्ता पहले ही लॉग इन है। (या नहीं, इस मामले में उपयोगकर्ता को पहले लॉग इन करें।) फिर यह उपयोगकर्ता को somepage.example.com?sessionid=something पर रीडायरेक्ट करता है जहां यह sessionid somepage.example.com के सत्र में संग्रहीत किया जाएगा। फिर इस सत्र में यह भी पता चलेगा कि उपयोगकर्ता ने लॉग ऑन किया है और उपयोगकर्ता के लिए यह लगभग पारदर्शी प्रतीत होता है।

असल में, उपयोगकर्ता को दो बार पुनर्निर्देशित किया जाता है।

Answer 4

यदि आपके सभी एप्लिकेशन एक डोमेन पर हैं, तो यह बहुत मुश्किल नहीं है क्योंकि आप सत्र नियंत्रण को संभालने के लिए डोमेन स्तर कुकी का उपयोग कर सकते हैं। (कुकी-कम सत्र प्रबंधन मुश्किल है, लेकिन किया जा सकता है, लेकिन मुश्किल है।)

हालांकि, आपने example.com डोमेन पर कुछ साइटें और example.org डोमेन पर कुछ साइटें इंगित की हैं।

बजाना के साथ एक सा मेरी गूगल कराहते-इन, और की अन्य साइट्स किस तरह orkut.com, ऐसा लगता है जब आप एक पेज साख की जरूरत है कि मारा लग रहा है, यह खाते में प्रवेश के लिए एक आम साइट है, जो तब रीडायरेक्ट करने के लिए आप पुनर्निर्देश मूल साइट पर वापस, संभवतः यूआरएल में कुछ प्रकार के सत्र टोकन को गुजरना। इससे, संभावित रूप से orkut.com सर्वर टोकन को सत्यापित करने के लिए सीधे google.com सर्वर से प्रदान करते हैं और जो भी अन्य उपयोगकर्ता जानकारी की आवश्यकता होती है।

अधिक जानकारी पर डोमेन स्तर कुकीज़ Reqeusted रूप

आप दो साइटों है, तो foo.example.com कहना और bar.example.com, आप एक कुकी की मेजबानी के लिए विशिष्ट सेट कर सकते हैं, लेकिन आप भी डोमेन है कि होगा के लिए एक कुकी सेट कर सकते हैं डोमेन पर सभी मेजबानों द्वारा देखा जाना चाहिए।

तो, foo.example.com एक कुकी foo.example.com लिए विशेष रूप से सेट कर सकते हैं, और यह केवल अपने आप में देखा जाएगा, लेकिन यह भी डोमेन example.com, के लिए एक कुकी सेट कर सकते हैं और उपयोगकर्ता bar.example.com को जाता है जब वे भी इस दूसरे कुकी देखेंगे।

हालांकि, अगर आप भी एक साइट snafu.example.org, है यह इस डोमेन स्तर कुकी नहीं देख सकते हैं कि foo सेट, क्योंकि example.org और example.com दो बिल्कुल ही अलग डोमेन है।

आप उसी डोमेन में साइटों पर सत्र जानकारी को बनाए रखने के लिए डोमेन स्तर कुकी का उपयोग कर सकते हैं।

डोमेन स्तर कुकीज़ कैसे सेट करें आप अपने विकास पर्यावरण पर निर्भर करते हैं (मुझे रेल के साथ कोई अनुभव नहीं है, क्षमा करें)।

Answer 5

इस समाधान के लिए कोई आवश्यकता नहीं है टी सर्वर।

प्रवेश

1. लॉग इन
2. अपने पर कुकी सेट करने के लिए आप सभी डोमेन से एन्क्रिप्टेड सत्र id और अन्य जानकारी टोकन के माध्यम से
3. दिखाएँ img साथ टोकन बनाएं।

प्राधिकरण कुकी

1. से आप पहले से ही सभी डोमेन पर कुकीज़ की है।

साइन आउट

1. साफ़ कुकी
2. सत्र को नष्ट
डीबी में पिछले सत्र आईडी (मुझे लगता है कि आप कुकी द्वारा सत्र बढ़ने के लिए उपयोगकर्ता तालिका में सत्र id को बचाने के साथ
3. साफ़ संबंध प्रयोक्ता आईडी)

मैं इस समाधान का प्रयास नहीं कर सकता। लेकिन अब मुझे आपके जैसी समस्या है (एसएसओ) और मैं कल इसे आजमाता हूं।

Answer 6

मैं एसएसओ परिदृश्यों और संघीय पहचान दोनों के लिए किसी समूह का चिह्न का इस्तेमाल किया है, लेकिन मैं आपको और अधिक सरल समाधान है कि ऊपर उल्लेख किया है की जरूरत है मान।

Answer 7

ऐसा करने के लिए एक क्रॉस डोमेन सक्षम रेल प्लगइन अद्भुत होगा।

मैं यह करने के लिए करना चाहते हैं, एक ही रास्ता मैं के बारे में सोच सकता है उपयोगकर्ता एक उपकरण पट्टी, या कि मेरे लिए स्वचालित रूप से में प्रवेश करने संभाल होगा कुछ थोड़ा हवा एप्लिकेशन डाउनलोड करने के लिए मजबूर किया गया था।

मुझे एक और तरीका पता होना चाहिए क्योंकि