7

यह मेरे लिए एक पुन: संक्रमित समस्या प्रतीत होता है क्योंकि मुझे पिछले कुछ वर्षों में मोबाइल एप्लिकेशन के आसपास गुरुत्वाकर्षण लगता है। मैं वेब उपयोगकर्ताओं के अलावा मोबाइल उपयोगकर्ताओं को प्रमाणीकृत और अधिकृत करना चाहता हूं। मुझे यह निर्बाध बनाने की ज़रूरत है ताकि उपयोगकर्ता अपने डेटा में बाधा उत्पन्न किए बिना वेब खाता प्राप्त कर सकें। मैं चाहता हूं कि समाधान विषय में वास्तुशिल्प बनें, किसी भी भाषा/ढांचे के लिए विशिष्ट नहीं।मोबाइल और वेब उपयोगकर्ताओं के प्रमाणीकरण/प्रमाणीकरण के लिए आर्किटेक्चर

आवश्यकताओं/अनुमान

  1. मोबाइल उपयोगकर्ताओं के लिए सामग्री योगदान के लिए सहित (पसंदीदा अंकन, फोटो अपलोड करने, आदि), एक लॉगिन के बिना स्थानीय एप्लिकेशन का उपयोग करने के लिए सक्षम होना चाहिए।
  2. मोबाइल उपयोगकर्ता को सुरक्षित रूप से और विशिष्ट रूप से खाता प्रमाण-पत्र निर्दिष्ट किए बिना वेब सेवा के लिए प्रमाणित होना चाहिए।
  3. मोबाइल उपयोगकर्ता में कई डिवाइस हो सकते हैं, जो एक-दूसरे से अनजान होंगे।
  4. मोबाइल उपयोगकर्ता पंजीकरण/लॉगिन करने में सक्षम होना चाहिए, जो किसी भी सामग्री में खाते के स्वामित्व में रोल करना चाहिए। यह "सिंक्रनाइज़ेशन" प्रत्येक खाते के साथ होना चाहिए जो बाद में लॉग इन किया गया है।
  5. इससे कोई फर्क नहीं पड़ता कि मोबाइल या वेब पर खाता बनाया गया था या नहीं।

आर्किटेक्चर

  1. माना नहीं शर्ट, जूते नहीं, कोई प्रवेश = कोई योगदान। किसी भी प्रकार की सामग्री का योगदान करने के लिए लॉगिन की आवश्यकता है। यह एक मास्टर खाते के साथ डिवाइस खातों को "सिंक्रनाइज़" करने की आवश्यकता को रोकता है। डिवाइस लॉगिन करने के लिए बस एक ही उपयोगकर्ता नाम/पासवर्ड + टोकन की आवश्यकता होती है। सर्वर ऑब्जेक्ट्स: उपयोगकर्ता, रोल
  2. मल्टी-डिवाइस स्व-प्रमाणीकरण। सर्वर डिवाइस के साथ बातचीत करता है और डिवाइस को स्टोर करने वाले प्रमाण-पत्रों को हाथ देता है। प्रत्येक डिवाइस स्व-प्रमाणीकरण करता है और एक अनाम खाते से जुड़ा होता है जब तक रजिस्टर/लॉगिन नहीं होता है। यदि रजिस्टर होता है, तो अनाम खाता ज्ञात खाते में परिवर्तित हो जाता है। यदि लॉगिन होता है, तो अनाम खाते से सामग्री को ज्ञात खाते में ले जाया जाता है और फिर फेंक दिया जाता है। स्व-प्रमाणीकरण विवरण खोने वाले उपकरणों को नए प्रमाणीकरण विवरण मिलेंगे, और पिछला अनाम खाता छोड़ दिया जाएगा (और फिर उम्मीद है कि बाद में फेंक दिया जाएगा) और पुन: विश्राम नहीं किया जाएगा क्योंकि इसे किसी ज्ञात खाते में कभी परिवर्तित नहीं किया गया था। सर्वर ऑब्जेक्ट्स: उपयोगकर्ता, रोल, डिवाइस

आपको क्या लगता है कि एक अच्छा समाधान है? इनमें से एक, या कुछ और?

उत्तर

0

संख्या 2 आधार निर्णय के रूप में पर्याप्त है। उपयोगकर्ता पंजीकरण से नफरत करते हैं;) पंजीकरण के बिना सेवा का उपयोग करने की क्षमता अच्छा विचार है।

आप जीवित पहचानने के लिए GUID/UUID का उपयोग कर सकते हैं। और इसे उपयोगकर्ता लॉगिन से पहले अनाम लॉगिन के रूप में उपयोग करें।

लेकिन क्या करना है यदि 2 (या अधिक) लोग 1 डिवाइस का उपयोग करते हैं? या डिवाइस बंद हो जाएगा, चोरी हो गया? मुझे लगता है कि इनमें से कोई भी अंक इन मामलों को कवर नहीं करता है।

मुझे नहीं पता कि आप किस प्रकार की वेब सेवा आर्किटेक्ट करते हैं, इसलिए अधिक सलाह नहीं दे सकते।

2

मैं 2 के समान विचार प्रस्तावित करना चाहता हूं।

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

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

सर्वर की तरफ, मैं पहचान के रूप में कार्यरत दो अलग-अलग प्रकार की इकाइयों की अनुमति दूंगा: वेब उपयोगकर्ता जो प्रमाण-पत्र द्वारा प्रमाणित हैं (ओपनआईडी मेरे दिमाग में एक अतिरिक्त के रूप में आता है) और डिवाइस जो उपयोगकर्ता हस्तक्षेप के बिना उनके GUID द्वारा प्रमाणीकृत हैं। स्वाभाविक रूप से, एक वेब उपयोगकर्ता इकाई कई डिवाइस इकाइयों का मालिक हो सकती है। एक डिवाइस इकाई किसी खाते से जुड़ी होती है जब उपयोगकर्ता अपने डिवाइस को किसी मौजूदा खाते से लिंक करने का विकल्प चुनता है। सामग्री आम तौर पर एक पहचान से जुड़ी होती है।

उपयोगकर्ता और डिवाइस के बीच संबंध रखा जाता है और सामग्री की उत्पत्ति प्रदर्शित करने के लिए भी इसका उपयोग किया जा सकता है।

आपको मोबाइल उपयोगकर्ताओं के लिए जेनरेट किए गए क्रेडेंशियल्स वाले खाते बनाने/ड्रॉप/कन्वर्ट करने की आवश्यकता नहीं होगी। आपको मोबाइल डिवाइस पर क्रेडेंशियल स्टोर करने की भी आवश्यकता नहीं होगी।

आपके आवेदन के संदर्भ की आलोचना के आधार पर अभी भी कुछ सुरक्षा विचार खुल गए हैं। किसी भी सुरक्षा उपायों के बिना, एक हमलावर को यूयूआईडी का दुरुपयोग करना आसान लगेगा।

2

मुझे लगता है कि यह गलत दिशा से देखा जा रहा है। एक मनमानी मूल्य द्वारा परिभाषित किए जाने के रूप में सर्वर पर एक पहचान परिभाषित करें। शायद सिर्फ एक डीबी अनुक्रम। इस पहचान के साथ किसी जनसांख्यिकीय जानकारी (नाम, ईमेल ...) और उपयोग इतिहास को संबद्ध करें।

अलग-अलग, सर्वर पर प्रमाणीकरण इकाई को परिभाषित करें। यह उपयोगकर्ता/पासवर्ड हो सकता है। यह एक डिवाइस GUID/UUID हो सकता है। यह ओपनआईडी जैसे संघीय आईडी हो सकता है। एक दी गई पहचान में कई संबंधित प्रमाणीकरण-संस्थाएं हो सकती हैं (और अक्सर आपके उपयोग-मामले में)। एक ही प्रकार की बहुत संभवतः कई प्रमाणीकरण-पहचान। (उदाहरण के लिए मेरे स्मार्टफोन के लिए GUID, मेरे आईपैड के लिए GUID ...)

आपका फ्रंट-एंड (चाहे वेब या ऐप-आधारित), किसी उपयोगकर्ता को प्रमाणीकृत करने के लिए परिभाषित एपीआई का उपयोग करें; फ्रंट-एंड का समर्थन करने वाले तंत्रों का उपयोग करना।

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

एक अन्य बिंदु, जो भी सर्वर विशिष्ट रूप से पहचान निर्दिष्ट करने के लिए उपयोग करता है वह एक मान होना चाहिए जो किसी ग्राहक को प्रदान नहीं किया गया है। ग्राहक केवल प्रमाणीकरण तंत्र और उसके डेटा के बारे में जानते हैं। यही है, GUID/UUID, उपयोगकर्ता नाम/पासवर्ड, ...

ऊपर सूचीबद्ध तकनीकों के अलावा, ओएथ की तरह कुछ स्थानीय रूप से जेनरेट किए गए GUID से अधिक सुरक्षित है। वे एक में से एक हैं: आसानी से निर्धारित या बी: आसानी से खो गया। यदि मूल्य अत्यधिक अनुमानित है (टेलीफोन # कहें) यह आसानी से खराब हो जाता है। यदि यह रनटाइम पर जेनरेट किया गया है और इसमें पहली बार हैश की तरह हार्ड-टू-पूर्वानुमान मूल्य शामिल है, तो इसे डिवाइस पर संग्रहीत किया जाना चाहिए और डिवाइस को मिटाए जाने पर आसानी से खोया जा सकता है। अच्छे GUID उत्पन्न किए जा सकते हैं, लेकिन वे अक्सर बहुत ही प्रकार के डिवाइस विशिष्ट होते हैं। रोम, आईएमईआई, से डिवाइस सीरियल नंबर जैसे चीजें पुनर्प्राप्त की गईं ... यह आसानी से करने योग्य है।लेकिन, यह बहुत अधिक विशिष्ट-डिवाइस निर्भर है जितना संभवतः मैं आरामदायक हूं।

इस पूरे दृष्टिकोण में मुझे सबसे बड़ी वास्तविक बाधा दिखाई देती है कि यह एक मौजूदा डिवाइस-केवल (कोई उपयोगकर्ता नाम/पासवर्ड) उपयोगकर्ता को पीसी ब्राउज़र पर बैठने और अपने मौजूदा खाते से कनेक्ट करने की अनुमति देने के लिए अजीब होगा।

+0

मुझे वास्तव में आपकी सोच की रेखा पसंद है। मुझे यकीन नहीं है कि यह वास्तव में इस विशेष समस्या से संपर्क करने के लिए सामान्य तकनीकों को दिखाता है, लेकिन मैं आपकी प्रतिक्रिया की बहुत सराहना करता हूं। (ध्यान दें कि मैंने 2010 में इस प्रतिक्रिया को वापस पढ़ा था, लेकिन मुझे अब आपको यह बताने के लिए मजबूर होना पड़ा कि इसकी सराहना की और उपयोगी थी) –

-3

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

यह बहुत दूर नहीं लग रहा है। मोटोरोला एट्रिक्स में एक फिंगरप्रिंट सेंसर है ...

+0

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