2008-09-04 18 views
95

हमारी कंपनी के पास प्रत्येक डोमेन पर होस्ट की गई एक वेबसाइट के साथ कई डोमेन सेट हैं। इस समय, प्रत्येक डोमेन का अपना प्रमाणीकरण होता है जो कुकीज़ के माध्यम से किया जाता है।एकाधिक डोमेन पर सिंगल साइन ऑन

जब किसी एक डोमेन पर लॉग ऑन करने वाले किसी अन्य व्यक्ति से कुछ भी एक्सेस करने की आवश्यकता होती है, तो उपयोगकर्ता को अन्य डोमेन पर स्थित अन्य वेबसाइट पर अलग-अलग प्रमाण-पत्रों का उपयोग करके फिर से लॉग इन करने की आवश्यकता होती है।

मैं एकल साइन ऑन (एसएसओ) की ओर बढ़ने की सोच रहा था, ताकि इस परेशानी को समाप्त किया जा सके। मैं इस बारे में किसी भी विचार की सराहना करता हूं कि यह कैसे हासिल किया जा सकता है, क्योंकि मुझे इस संबंध में कोई अनुभव नहीं है।

धन्यवाद।

संपादित करें: वेबसाइटें इंटरनेट (बाहरी) और इंट्रानेट (कंपनी के भीतर आंतरिक-उपयोग) साइटों का मिश्रण हैं।

+0

यह [ओपनआईडी] (http://openid.net/) के लिए नौकरी की तरह लगता है - लेकिन केवल आपके साइन-इन डोमेन से आईडी की अनुमति देता है। – Neall

उत्तर

2

यदि आप सक्रिय निर्देशिका का उपयोग करते हैं तो आप प्रत्येक ऐप प्रमाणीकरण के लिए एडी का उपयोग कर सकते हैं, तो लॉगिन निर्बाध हो सकता है।

अन्यथा, यदि अनुप्रयोग दृश्यों के पीछे एक-दूसरे से बात कर सकते हैं, तो आप सत्र आईडी का उपयोग कर सकते हैं और एक ऐप हैंडलिंग आईडी पीढ़ी आपके सभी अन्य अनुप्रयोगों की सेवा कर सकते हैं।

+0

उपयोगकर्ता को अभी भी डोमेन 1.com और domain2.com और domain3.com पर उपयोगकर्ता नाम और पासवर्ड दर्ज करना नहीं है जब वह इस सत्र के लिए पहली बार उन साइटों पर उतरते हैं? – HaBo

14

होस्ट नाम कितने अलग हैं?

ये मेजबान साझा कर सकते हैं कुकीज़:

  • mail.xyz.com
  • www.xyz.com
  • logon.xyz.com

लेकिन इन नहीं कर सकते हैं:

  • abc.com
  • xyz.com
  • www.tre.com

पूर्व के मामले आप एक कुकी-आधारित समाधान बाहर टकरा सकते हैं। GUID और डेटाबेस सत्र तालिका सोचें।

76

एसएसओ समाधान कि मैं यहाँ लागू किया कार्य करता है इस प्रकार है:

  1. एक मास्टर डोमेन, login.mydomain.com स्क्रिप्ट master_login.php कि लॉगिन का प्रबंधन करता है के साथ नहीं है।
  2. प्रत्येक ग्राहक डोमेन में स्क्रिप्ट क्लाइंट_login.php
  3. सभी डोमेन में साझा उपयोगकर्ता सत्र डेटाबेस होता है।
  4. जब ग्राहक डोमेन को उपयोगकर्ता को लॉग इन करने की आवश्यकता होती है, तो यह मास्टर डोमेन (login.mydomain.com/master_login.php) पर रीडायरेक्ट करता है। यदि उपयोगकर्ता ने मास्टर में साइन इन नहीं किया है तो यह उपयोगकर्ता से प्रमाणीकरण का अनुरोध करता है (यानी प्रदर्शन लॉगिन पृष्ठ)। उपयोगकर्ता प्रमाणीकृत होने के बाद यह डेटाबेस में एक सत्र बनाता है। यदि उपयोगकर्ता पहले ही प्रमाणीकृत है तो यह डेटाबेस में अपना सत्र आईडी देखता है।
  5. मास्टर डोमेन क्लाइंट डोमेन (client.mydomain.com/client_login.php) पर वापस जाता है सत्र आईडी पास करता है।
  6. क्लाइंट डोमेन मास्टर से सत्र आईडी संग्रहीत कुकी बनाता है। ग्राहक सत्र आईडी का उपयोग कर साझा डेटाबेस से पूछताछ करके लॉग इन उपयोगकर्ता को ढूंढ सकता है।

नोट्स:

  • सत्र id एक अद्वितीय वैश्विक आरएफसी से एल्गोरिदम के साथ जेनरेट पहचानकर्ता 4122
  • master_login.php केवल उसकी श्वेतसूची
  • मास्टर और ग्राहकों में डोमेन पर रीडायरेक्ट करेगा विभिन्न शीर्ष स्तर डोमेन में हो सकता है। उदाहरण के लिए। client1.abc.com, client2.xyz.com, login.mydomain.com
+0

यह एक अच्छा समाधान ग्रोम की तरह दिखता है। आप डेटाबेस में क्या स्टोर करते हैं? क्या यह (session_id, उपयोगकर्ता नाम, हैश_पासवर्ड) है? –

+1

मास्टर डोमेन login.mydomain.com नीचे जाने के मामले को आप कैसे संभालेंगे? क्या उस समय लॉगिन असंभव है? – jjxtra

+3

किसी भी शरीर ने कोई कोड उदाहरण या एक गिथब रेपो बनाया? –

30

पहिया का पुन: आविष्कार न करें। जॉस, ओपनएसएसओ, सीएएस, शिबबोलेथ और अन्य जैसे कई ओपन सोर्स क्रॉस-डोमेन एसएसओ पैकेज हैं। यदि आप माइक्रोसॉफ्ट टेक्नोलॉजी (आईआईएस, एडी) में उपयोग कर रहे हैं, तो आप इसके बजाय माइक्रोसॉफ्ट फेडरेशन (एडीएफएस) का उपयोग कर सकते हैं।

+2

बिल्कुल - मैंने देखा है कि बहुत से लोग अपने स्वयं के सुरक्षा समाधानों को केवल यह पता लगाने के लिए कहते हैं कि वे रीप्ले, एक्सएसआरएफ या अन्य हमलों –

+3

+1 के लिए कमजोर हैं, आपको [लगभग] सुरक्षा चक्र को कभी भी पुनर्विचार नहीं करना चाहिए। –

+6

ओपनएसएसओ मर चुका है और जॉसो और सीएएस जावा समाधान हैं। बस एक एफवाईआई – OneHoopyFrood

संबंधित मुद्दे