एकल signon

के लिए बड़े उपयोगकर्ता डेटाबेस के प्रबंध कैसे आप निम्नलिखित उद्देश्यों के साथ एक प्रणाली लागू करना होगा: हजारों की सैकड़ों की मौजूदा उपयोगकर्ताओं वर्तमान में कसकर एक साथ एकीकृत के लिएएकल signon

प्रमाणीकरण की व्यवस्था करें, प्राधिकरण तीसरे पक्ष के विक्रेता का आवेदन (हम इन उपयोगकर्ताओं को हमारे द्वारा प्रबंधित की जाने वाली चीज़ों में बस्ट करना चाहते हैं और हमारे ऐप्स इसके खिलाफ काम करते हैं, साथ ही हमारे तृतीय पक्ष विक्रेता इसके खिलाफ काम करते हैं)।
उन उपयोगकर्ताओं से जुड़ी प्रोफाइल जानकारी प्रबंधित करें
किसी भी प्लेटफ़ॉर्म (विंडोज, * निक्स, PHP, एएसपी/सी #, पायथन/डीजेगो, एट कैटेरा) पर किसी भी वेब एप्लिकेशन से एक्सेस किया जा सकता है।

कुछ नमूने यहां कार्यान्वयन:

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

इनमें से कोई भी सर्वश्रेष्ठ सर्वश्रेष्ठ है? क्या ऐसे अन्य समाधान हैं जो ऊपर के उद्देश्यों को फिट करते हैं और कार्यान्वित करना आसान है?

** मुझे यह जोड़ना चाहिए कि उपयोगकर्ता डेटाबेस के विरुद्ध प्रमाणीकरण करने वाले लगभग सभी एप्लिकेशन हमारे नियंत्रण में होंगे। अकेले कुछ बाहरी लोग ऐसे अनुप्रयोग होंगे जो हम वर्तमान उपयोगकर्ता डेटाबेस को हटा रहे हैं और शायद 1 या 2 अन्य। ओपनआईडी सर्वर की आवश्यकता के लिए इतना कुछ भी व्यापक नहीं है।

यह जानना भी महत्वपूर्ण है कि इनमें से बहुत से उपयोगकर्ताओं के पास 5-8 साल के लिए ये खाते हैं और उनके लॉगिन और पासवर्ड, et cetera जानते हैं।

स्रोत

2008-09-16 Anonymous

प्रमाणीकरण और प्रमाणीकरण/प्रोफाइलिंग के बीच एक अंतर है इसलिए जरूरी दोनों को एक ही उपकरण में मजबूर न करें। प्रमाणीकरण के लिए एलडीएपी का उपयोग करने का आपका दूसरा समाधान और प्राधिकरण के लिए डीबी अधिक मजबूत लगता है क्योंकि एलडीएपी डेटा उपयोगकर्ता द्वारा नियंत्रित होता है और डीबी को व्यवस्थापक द्वारा नियंत्रित किया जाएगा। उत्तरार्द्ध समय के साथ संरचना और जटिलता में morph की संभावना है, लेकिन प्रमाणीकरण सिर्फ प्रमाणीकरण है। इन कार्यों का पृथक्करण अधिक प्रबंधनीय साबित होगा।

स्रोत

2008-09-16 23:26:51 dacracot

-1

आप हमेशा अपना खुद का OpenID सर्वर लागू कर सकते हैं। पहले से ही Python library for OpenID है इसलिए यह काफी आसान होना चाहिए।

बेशक आपको अपने अनुप्रयोगों में अन्य सर्वरों द्वारा अधिकृत लॉग इन स्वीकार करने की आवश्यकता नहीं है। केवल अपने सर्वर द्वारा अधिकृत प्रमाण पत्र स्वीकार करें।

संपादित करें: मुझे implementation of OpenID server protocol in Django मिला है।

संपादित 2: आपके उपयोगकर्ताओं के लिए ओपनआईडी लागू करने में एक स्पष्ट लाभ है। वे अपने लॉग इन के साथ स्टैक ओवरव्लो में लॉगिन करने में सक्षम होंगे :-)

स्रोत

2008-09-16 23:14:00 zuber

मुझे यह जोड़ना चाहिए कि उपयोगकर्ता डेटाबेस के विरुद्ध प्रमाणीकरण करने वाले लगभग सभी एप्लिकेशन हमारे नियंत्रण में होंगे। ओपनआईडी सर्वर की आवश्यकता के लिए इतना कुछ भी व्यापक नहीं है। यह जानना भी महत्वपूर्ण है कि इनमें से बहुत से उपयोगकर्ताओं के पास 5-8 साल के लिए ये खाते हैं और उनके लॉगिन और पासवर्ड –

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

अन्यथा यह एडी और ओपनसोर्स एलडीएपी विकल्पों के बीच टॉस-अप होगा।

एकल-साइन-ऑन के लिए अपनी खुद की प्रमाणीकरण स्कीमा को रोल करने के लिए व्यवहार्य नहीं हो सकता है (विशेष रूप से दस्तावेज और एकीकरण कार्य की उच्च मात्रा पर विचार करने के लिए), और स्पष्ट रूप से किसी भी के साथ अपने प्रमाणीकरण सर्वर को बंडल न करें आपके सिस्टम पर चल रहे एप्लिकेशन (क्योंकि आप चाहते हैं कि यह ऐसे अनुप्रयोगों के लोड से स्वतंत्र हो)।

गुडलक!

स्रोत

2008-09-16 23:19:26

वर्तमान उपयोगकर्ता डेटाबेस + प्रोफाइल हमारे तृतीय पक्ष विक्रेताओं पारंपरिक डेटाबेस (* एसक्यूएल) में संग्रहीत हैं। हमारे पास उस डेटाबेस में एकीकृत करने की बहुत सीमित क्षमता है और हम इसके बजाय पूर्ण नियंत्रण रखना चाहते हैं। हम उन उपयोगकर्ताओं को मुक्त करना चाहते हैं और फिर तीसरे पक्ष के काम को नए डीबी/एलडीएपी –

के साथ काम करना चाहते हैं एलडीएपी के बारे में क्या अच्छा है उद्यम के लिए अन्य तीसरे पक्ष के उत्पाद उपयोगकर्ता प्रबंधन के लिए उससे जुड़ने में सक्षम होना चाहिए। –

मुझे लगता है कि एलडीएपी शायद इस परियोजना के प्रमाणीकरण पोर्टिंग के लिए दिया गया है, लेकिन प्रोफ़ाइल जानकारी संग्रहीत करने के बारे में क्या है? इसे एलडीएपी में भी भरें? इसे एक अलग स्टोर में तोड़ दो? –

केवल प्रमाणीकरण के लिए एलडीएपी/एडी का उपयोग करें, कुछ प्रकार के पारंपरिक डेटाबेस (एमएसएसएलएल/पोस्टग्रेएसक्यूएल/माईएसक्यूएल) या दस्तावेज़ आधारित डीबी (कॉच डीबी, सिंपल डीबी, एट कैटेरा) का उपयोग करके एलडीएपी उपयोगकर्ताओं को सबसे मजबूत प्रोफ़ाइल/प्राधिकरण सर्वर से जोड़ दें। प्राधिकरण के लिए एलडीएपी का प्रयोग करें, फिर अधिक उन्नत सामग्री के लिए डीबी दबाएं।

स्रोत

2008-09-16 23:29:37

मैं इसे "सुरक्षित" उत्तर के रूप में चुनता हूं क्योंकि मुझे यकीन नहीं है कि एलडीएपी स्कीमा परिवर्तन कितने लचीले होते हैं। हालांकि, डेटाबेस को संशोधित करते समय मुझे उपयोगकर्ता स्टोर के लिए इसका उपयोग करने में बहुत सहज महसूस होता है क्योंकि सुविधाओं को जोड़ा जाता है। –

हमारे पास लगभग 100k उपयोगकर्ताओं के साथ अलग-अलग साइटें हैं और वे सभी सामान्य डेटाबेस के साथ काम करते हैं। यदि अधिकांश एप्लिकेशन डीबी तक पहुंच सकते हैं तो आप इस समाधान का उपयोग कर सकते हैं।

स्रोत

2008-09-16 23:31:58 Sklivvz

उत्तर

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