आप ऐप डोमेन

Question

के बीच एक प्रमाणित सत्र कैसे पास करते हैं, मान लें कि आपके पास वेबसाइट www.xyz.com और www.abc.com हैं।

आइए कहें कि कोई उपयोगकर्ता www.abc.com पर जाता है और वे सामान्य एएसपी .NET सदस्यता प्रदाता के माध्यम से प्रमाणित हो जाते हैं।

फिर, उस साइट से, उन्हें साइट www.xyz.com पर भेजा गया (रीडायरेक्शन, लिंक, जो भी काम करता है), और साइट www.abc.com का उद्देश्य उस उपयोगकर्ता को दूसरी साइट पर पास करना था प्रमाणीकृत की स्थिति है, ताकि साइट www.xyz.com फिर से उपयोगकर्ता के प्रमाण-पत्रों के लिए नहीं पूछे।

काम करने के लिए इसके लिए क्या आवश्यकता होगी? हालांकि, इस पर कुछ बाधाएं हैं, उपयोगकर्ता डेटाबेस पूरी तरह से अलग हैं, यह किसी संगठन के लिए आंतरिक नहीं है, यह सब कुछ है, यह stackoverflow.com से प्रमाणीकृत के रूप में गुजरने जैसा है, यह प्रकृति में अलग है। एक प्रासंगिक लेख का एक लिंक पर्याप्त होगा।

Answer 1

तो जैसे web.config प्रमाणीकरण अनुभाग की स्थापना करके FormAuthentication उपयोग करके देखें:

<authentication mode="Forms"> 
    <forms name=".ASPXAUTH" requireSSL="true" 
     protection="All" 
     enableCrossAppRedirects="true" /> 
</authentication> 

एक मशीन कुंजी उत्पन्न करें। उदाहरण: Easiest way to generate MachineKey – Tips and tricks: ASP.NET, IIS ...

अन्य एप्लिकेशन पर पोस्ट करते समय प्रमाणीकरण टिकट एक छिपे हुए क्षेत्र के रूप में पारित किया जाता है। पहले ऐप से पोस्ट पढ़ने के दौरान, दूसरा ऐप एन्क्रिप्टेड टिकट पढ़ेगा और उपयोगकर्ता को प्रमाणित करेगा। यहाँ पेज कि गुजरता है, इसका एक उदाहरण है कि पदों क्षेत्र:

.aspx:

<form id="form1" runat="server"> 
    <div> 
    <p><asp:Button ID="btnTransfer" runat="server" Text="Go" PostBackUrl="http://otherapp/" /></p> 
    <input id="hdnStreetCred" runat="server" type="hidden" /> 
    </div> 
</form> 

कोड-पीछे:

protected void Page_Load(object sender, EventArgs e) 
{ 
    FormsIdentity cIdentity = Page.User.Identity as FormsIdentity; 
    if (cIdentity != null) 
    { 
     this.hdnStreetCred.ID = FormsAuthentication.FormsCookieName; 
     this.hdnStreetCred.Value = FormsAuthentication.Encrypt(((FormsIdentity)User.Identity).Ticket); 
    } 
} 

इसके अलावा के अध्याय 5 में पार एप्लिकेशन प्रपत्र प्रमाणीकरण अनुभाग देखें Wrox से यह book। यह होमब्री एसएसओ समाधान प्रदान करने के अलावा उपर्युक्त लोगों की तरह उत्तर की सिफारिश करता है।

Answer 2

सुनिश्चित नहीं है कि आप .NET के लिए क्या उपयोग करेंगे लेकिन आम तौर पर मैं एक LAMP स्टैक में memcached का उपयोग करूंगा।

Answer 3

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

दृष्टिकोण यह कैसे करना है आमतौर पर एकल साइन-ऑन (देखें Wikipedia)।

Answer 4

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

Answer 5

यदि आप निर्मित सदस्यता प्रणाली का उपयोग कर रहे हैं तो आप प्रत्येक वेब.कॉन्फिग में इस तरह कुछ का उपयोग करके फॉर्म एथ के साथ क्रॉस सब-डोमेन प्रमाणीकरण कर सकते हैं।

<authentication mode="Forms"> 
    <forms name=".ASPXAUTH" loginUrl="~/Login.aspx" path="/" 
        protection="All" 
        domain="datasharp.co.uk" 
        enableCrossAppRedirects="true" /> 

</authentication> 

सुनिश्चित करें कि नाम, पथ, सुरक्षा और डोमेन सभी web.configs में समान हैं। यदि साइटें विभिन्न मशीनों पर हैं तो आपको यह सुनिश्चित करने की भी आवश्यकता होगी कि मशीनकी और सत्यापन और एन्क्रिप्शन कुंजी समान हैं।

Answer 6

इस समस्या के कई दृष्टिकोण हैं, जिन्हें "क्रॉस-डोमेन एकल साइन ऑन" के रूप में वर्णित किया गया है। विकिपीडिया लेख बताया मेटि़ज द्वारा करने के लिए विशेष रूप से उपयोगी है आप एक खुला स्रोत समाधान के लिए देख रहे हैं - लेकिन - एक विंडोज़ वातावरण मैं belive आप 2 में से एक दृष्टिकोण के साथ बंद सबसे अच्छा कर रहे हैं में:

1. खरीदें एक वाणिज्यिक एसएसओ उत्पाद (जैसे साइटमाइंडर या पिंग इडेंटिटी)
2. माइक्रोस्कोफ्ट के क्रॉस-डोमेन एसएसओ समाधान का उपयोग करें, जिसे ADFS - सक्रिय डायरेक्टोरी फेडरेशन सर्विसेज कहा जाता है। (फेडरेशन एकाधिक डोमेन के व्यवहार को समन्वयित करने का शब्द है)

मैंने साइटमाइंडर का उपयोग किया है और यह अच्छी तरह से काम करता है, लेकिन यह महंगा है। यदि आप सभी माइक्रोसोफ्ट पर्यावरण में हैं तो मुझे लगता है कि एडीएफएस आपकी सबसे अच्छी शर्त है। इस ADFS whitepaper के साथ शुरू करें।

Answer 7

वैकल्पिक रूप से यदि आप अपना खुद का रोल करना चाहते हैं और प्रश्न में साइटें समान सर्वर पर नहीं हैं या किसी साझा डेटाबेस तक पहुंच नहीं है (इस मामले में उपर्युक्त प्रतिक्रियाएं देखें) तो आप प्रत्येक पर web beacon डाल सकते हैं उन साइटों का जो दूसरी साइट पर वापस देखेंगे।

साइट ए पर एक सिंगल पिक्सेल छवि (वेब ​​बीकन) रखें जो उपयोगकर्ता आईडी के माध्यम से गुजरने वाली साइट बी को कॉल करेगा (एन्क्रिप्टेड टाइम स्टैम्प)। इसके बाद उपयोगकर्ता के लिए साइट बी पर एक नया उपयोगकर्ता सत्र बनाया जाएगा जो लॉग इन के रूप में सेट किया जाएगा। फिर जब उपयोगकर्ता साइट बी का दौरा करता है तो वे पहले ही लॉग इन होंगे।

कॉल को कम करने के लिए आप केवल वेब बीकन डाल सकते हैं होम पेज पर और पुष्टि पृष्ठों में लॉग इन करें। मैंने पार्टनर साइटों के बीच जानकारी पास करने के लिए अतीत में सफलतापूर्वक इसका उपयोग किया है।

Answer 8

मैं करूंगा कैस की तरह उपयोगकर्ता कुछ:

[1]: http://www.ja-sig.org/products/cas/ कैस

यह एक हल समस्या है और अपने खुद के रोलिंग की सिफारिश नहीं होगा।