आवश्यक ओपनआईडी जानकारी संग्रहीत

Question

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

• लॉगिन करने के लिए सक्षम होना चाहते हैं
• ईमेल/पासवर्ड के माध्यम से (उपयोगकर्ता ने फॉर्म भरकर साइट पर पंजीकरण किया है)
• अपने खाते में खुले आईडी (ओपनिड्स + एक खाते के लिए ईमेल) संलग्न करें।

अब मुझे नहीं पता कि मुझे खुले आईडी के लिए कौन से प्रमाण-पत्र स्टोर करना चाहिए। और डीबी स्कीमा के बारे में निश्चित नहीं है। यहाँ डेटाबेस स्कीमा है: जब कोई उपयोगकर्ता में लॉग करता है, कि क्या openid/कस्टम सदस्यता का उपयोग करके

Table: Users 
UserId => PK 
... => Custom info. Not related to authentication. 

Table: Authentication 
AuthenticationId => PK 
LoginId => (when custom site membership => email address) (when openId => openid unique address) 

UserId => FK to Users. 
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address) 
Password => filled when using custom membership. empty when using open id. 

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

• मुख्य प्रश्न: Provider और LoginId OpenID प्रमाणीकरण के भंडारण के लिए पर्याप्त (देखने के लिए इन क्षेत्रों में संग्रहीत किया जा रहा है इसके बाद के संस्करण की टिप्पणियां देखें) भंडारण है? क्या मुझे कोई अतिरिक्त डेटा स्टोर करना चाहिए ताकि जब उपयोगकर्ता लौटाता है तो मैं उसे अपने सहेजे गए डेटा के आधार पर प्रमाणित कर सकता हूं?

• क्या आप इसे लागू करने के लिए कोई अन्य (अधिक कुशल) दृष्टिकोण सुझाते हैं?
  धन्यवाद।

Answer 1

ओपनिड उपयोगकर्ता के लिए ClaimedIdentifier स्टोर करें - प्रदाता पता नहीं। दावा किया गया पहचानकर्ता ओपनआईडी प्रोटोकॉल सत्यापित करता है जो उपयोगकर्ता के लिए अद्वितीय है और संभावित रूप से ओपनआईडी प्रदाताओं में पोर्टेबिलिटी प्रदान करता है।

इसके अलावा, क्योंकि ओपनआईडी 2.0 के दावा किए गए पहचानकर्ताओं को ओपनआईडी कनेक्ट (ओपनआईडी 2.0 के लिए एक अधूरा उत्तराधिकारी) द्वारा बहिष्कृत किया जा सकता है, यह ओपनआईडी प्रदाता एंडपॉइंट यूआरआई और ईमेल पते द्वारा रिकॉर्ड किए गए ईमेल पते को रिकॉर्ड करने में आपकी सबसे अच्छी रुचि भी हो सकती है। उपयोगकर्ता रिकॉर्ड में प्रदाता। अभी के लिए, इन्हें अपने प्रमाणीकरण प्रवाह के हिस्से के रूप में उपयोग करें, लेकिन उन्हें रिकॉर्ड करके, आप बाद में यह निर्धारित करने में सक्षम होंगे कि आप किस ईमेल पते पर भरोसा करते हैं (यानी मान लीजिए कि आप Google द्वारा दिए गए ईमेल पते को भरोसेमंद हैं) और उपयोगकर्ता को उस सत्यापित ईमेल पते का उपयोग करके अपने खाते को एक ओपनआईडी कनेक्ट में माइग्रेट करने की अनुमति दें। यह आपकी वेबसाइट के दायरे (आमतौर पर http://yourdomainname.com) के खतरे के खिलाफ भी कम हो जाएगा और आपके सभी Google के उपयोगकर्ता दावा किए गए पहचानकर्ताओं को बदलने के कारण, जो वास्तव में उनके ईमेल पते के माध्यम से वास्तव में पुनर्प्राप्त किया जा सकता है।

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

Answer 2

हम केवल ओपनिड दावा यूआरएल स्टोर करते हैं। आप प्रदाता से उपयोगकर्ता की नाम जैसे अतिरिक्त जानकारी का अनुरोध करना चाह सकते हैं। सदस्यता और प्रमाणीकरण को अलग करना सबसे महत्वपूर्ण बात है।

हमारे स्कीमा था

Profiles 
-------- 
UserId 
FirstName 
LastName 
etc. 

Users 
----- 
Username 
Password 

Profiles.UserId बस एक स्ट्रिंग संपत्ति है कि या तो उन आन्तरिक प्रयोक्ता नाम या उनकी OpenID दावा यूआरएल संग्रहीत करता है, कि वे किस तरह के आधार पर पंजीकृत है।

सफल प्रमाणीकरण (या तो आंतरिक उपयोगकर्ता नाम/पासवर्ड या बाहरी प्रदाता का उपयोग करके) पर हम अपने आंतरिक उपयोगकर्ता नाम या उनके दावे यूआरएल का उपयोग करके अपनी प्रमाणीकरण कुकी सेट करते हैं। उपयोगकर्ता की प्रोफ़ाइल प्राप्त करना तब प्रोफाइलर ढूंढने का मामला है जहां (UserId == User.Identity.Name)।

यह लाभ है कि उपयोगकर्ता किसी भी बिंदु पर प्रमाणीकृत करने के लिए चुन सकता है (शायद किसी आंतरिक खाते में स्विच कर रहा है या एक अलग प्रदाता का उपयोग कर रहा है)।