2013-01-24 28 views
7

के साथ एकल साइन ऑन मैं वर्तमान में ऊपर की समस्या के लिए एक अच्छा समाधान ढूंढ रहा हूं। हम शायद .NET एक पर फॉर्म प्रमाणीकरण चलाएंगे।2 सबडोमेन, एक जावा, एक .NET

मेरे पास a.mydomain.com पर चल रहा एक एएसपी.नेट एमवीसी ऐप है और जावा आधारित ऐप b.mydomain.com पर चल रहा है।

सबसे अच्छा तरीका क्या है ताकि मुझे प्रत्येक ऐप में लॉग इन करने की आवश्यकता न हो। कहें, जब मैं a.mydomain.com में लॉग इन करता हूं और फिर जावा b.mydomain.com खोलता हूं, और यह जांच करेगा और देखें कि मैं पहले से लॉग इन हूं?

क्या डब्ल्यूसीएफ प्रमाणीकरण सेवा वर्ग इस के लिए काम करेगा? क्या मैं पहले से ही .NET ऐप में लॉग इन हूं या नहीं, यह जांचने के लिए b.mydomain.com की जावास्क्रिप्ट से AJAX अनुरोध कर सकता हूं?

उत्तर

2

जब तक mydomain.com सार्वजनिक प्रत्यय सूची (http://publicsuffix.org/list/) में नहीं है, a.mydomain.com के लिए .mydomain.com

(ध्यान दें एक डोमेन कुकी रख सकते हैं कि आप केवल डाल कुकी में एक स्तर नीचे जा सकता है: a.b.mydomain.com एक नहीं डाल सकते .mydomain.com कुकी)

कुकी) *.mydomain.com और mydomain.com रूप b.mydomain.com को भेज दिया जाएगा (और साथ ही और एक सत्र को खोलने के लिए निशानी के रूप में इस्तेमाल किया जा सकता। तो पूरे * .mydomain.com उप डोमेन को नियंत्रित करने और यह केवल Http और सुरक्षित (https)

Response.SetCookie(new HttpCookie("myCookieName", "myCookieValue") { HttpOnly = true, Domain = ".myDomain.com", Secure=true }); 

Atlassian भीड़ समाधान http://www.atlassian.com/software/crowd/overview के कुछ हिस्सों इस कुकी तंत्र पर आधारित होते हैं

तो तुम हो सकता है बनाने के लिए सुनिश्चित हो :

  1. a.domain पर फॉर्म प्रमाणीकरण सक्षम करें।कॉम
  2. सफल लॉगिन पर
  3. एक myToken कुकी जो मूल्य userId शामिल निर्माण और हैशिंग a.myDomain.com और b.myDomain.com से जाना जाता है कुंजी के साथ userId टुकड़ों में बांटा
  4. डोमेन .mydomain.com
  5. जब साथ कुकी सेट उपयोगकर्ता userId और टुकड़ों में बांटा मूल्य के बीच मिलान के लिए b.myDomain.com, कुकी सर्वर साइड जाँच (जावा में) में प्रवेश करती है
  6. यदि कुकी सही है, तो उपयोगकर्ता userId के लिए खुला सत्र

ध्यान दें कि आप ऐसा नहीं करेंगे कुकी क्लाइंट साइड तक पहुंचने में सक्षम हो (इसलिए कोई जेएस कुकी हैंडलिंग, अगर मैं छोड़ूं टी सर्वर साइड जेएस है, उदाहरण के लिए nodejs)

+0

तो क्या मैं सिर्फ .NET एक पर फॉर्म प्रमाणीकरण सक्षम कर सकता हूं .. और फिर कुकी स्वचालित रूप से अन्य सबडोमेन में पारित हो जाएगी? :/ और फिर उन्हें जांचने की आवश्यकता है कि क्या कुकी जावास्क्रिप्ट में मौजूद है ??? क्या मैं यहाँ से रास्ता हूँ? और क्या यह बहुत बुरा नहीं होगा? और हमला करने के लिए खुला ?? –

+0

@NeilHosey मैंने अपने answser संपादित किया। उम्मीद है कि इससे – jbl

+0

मदद मिलेगी लेकिन क्या b.mydomain.com यह निर्धारित करने में सक्षम होगा कि वास्तव में कौन सा उपयोगकर्ता लॉग इन है? कुकी में इस डेटा को स्टोर करना एक अच्छा विचार है? सिस्टम के हिस्सों तक पहुंच के लिए स्वाभाविक जानकारी के साथ? –

1

जावा या .NET मौजूदा समाधान का उपयोग अन्य प्लेटफ़ॉर्म पर काम करने की संभावना नहीं है। आपको कई क्षमताओं की आवश्यकता है:

  1. पहचान (सत्र, कुकी) के लिए पहचानकर्ता के साथ क्लाइंट को ट्रैक करना।
  2. क्या जावा और .NET दोनों एप्लिकेशन संबंधित जानकारी प्राप्त करने में सक्षम हैं।

आप इन्हें कैसे कर सकते हैं?

  1. यह वास्तव में काफी आसान है। आप एक ही डोमेन का उपयोग कर रहे हैं ताकि आप सभी डोमेन के लिए ब्राउजर पर एक कुकी रख सकें, जिसका अर्थ है कि * और बी * के अनुरोधों में कुकी को सर्वर पर भेजा जाएगा। कुकी और .NET दोनों में कुकी प्लेसमेंट के लिए उत्कृष्ट सुविधाएं हैं।
  2. यह आपके बैक-एंड पर निर्भर है। लगातार भंडारण के लिए उपयोग कर रहे सिस्टम क्या हैं? यदि आपके पास एक MySQL डेटाबेस जैसा कुछ है जो दोनों सिस्टम से जुड़े हैं, तो आप प्रमाणीकरण के लिए प्रत्येक संग्रहीत पहचानकर्ता के लिए लॉगिन जानकारी के साथ एक तालिका बना सकते हैं। यदि आप इस मार्ग को लेते हैं, तो पुराने प्रमाणीकरण को अमान्य करने के लिए कुछ प्रकार के टाइम-आउट भी हैं।

यदि आपके पास दोनों जानकारी के टुकड़े हैं, तो आप प्रत्येक सिस्टम पर प्रमाणीकरण कर सकते हैं।

1

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

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

+0

धन्यवाद। मैं उन्हें देख लूंगा। आईडी बल्कि एक साधारण समाधान है, हालांकि यह मुझे एक साधारण समस्या के रूप में प्रतीत होता है, मेरे पास इस क्षेत्र में ज्ञान नहीं है –

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

  • कोई संबंधित समस्या नहीं^_^