8

में प्रमाणीकरण और भूमिका आधारित प्राधिकरण को कार्यान्वित करना मुझे अपने वेब एपीआई (सेवा) - एमवीसी (क्लाइंट) आर्किटेक्चर के लिए प्रमाणीकरण/प्राधिकरण परिदृश्य को लागू करते समय एक दृष्टिकोण का निर्णय लेने में कठिन समय है परियोजना। भले ही मैंने वेब एपीआई प्रोजेक्ट में कस्टम टोकन आधारित प्रमाणीकरण लागू किया है, मुझे यह मुश्किल लगता है जहां मुझे प्राधिकरण को लागू करना चाहिए (क्लाइंट या एपीआई में ही)।एएसपी.नेट एमवीसी वेब एपीआई सेवा और एमवीसी क्लाइंट आर्किटेक्चर


वास्तुकला अवलोकन:

  • परियोजनाओं समाधान -
    |
    | __ एएसपी.नेट वेब एपीआई आधारित आरईएसटी सेवा (स्वतंत्र रूप से एमआईएस 1 पर आईआईएस पर होस्ट किया गया)
    |
    | __ एएसपी.नेट एमवीसी आधारित ग्राहक (एमआईएस पर एमआईएस पर स्वतंत्र रूप से होस्ट किया गया आरईएसटी सेवा उपभोग)
    |
    | __ स्मार्ट फोन ग्राहक आवेदन (बाकी सेवा उपभोक्ता)

पहले से ही लागू किया प्रमाणीकरण: वेब एपीआई (संदेश हैंडलर का उपयोग) में

  • टोकन आधारित प्रमाणीकरण - कौन प्रमाणित उपयोगकर्ता के लिए SHA1 encripted टोकन जनरेट जिसे प्रमाणीकरण के लिए प्रत्येक http अनुरोध शीर्षलेख का हिस्सा होना आवश्यक है।
    (टोकन = उपयोगकर्ता नाम + उपयोगकर्ता आईपी)

  • एसएसएल सुरक्षित HTTP अनुरोध। (फिर से, संदेश हैंडलर का उपयोग करना)

वर्तमान समस्याओं:

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

मुझे आशा है कि, मैं कोई बात बिगड़ नहीं कर रहा हूँ, जबकि ध्यान में पूरे प्रमाणीकरण/प्राधिकरण अवधारणा ले रही। इस प्रकार, मैं किसी भी वैकल्पिक दृष्टिकोण/सुझाव की सराहना करता हूं।

+2

आपका प्रश्न क्या है? – Bizmarck

+2

मुझे क्षमा करें, मैं वास्तव में इसे पूरा करने से पहले गलती से पोस्ट प्रश्न बटन दबाता हूं। – vabz

उत्तर

3

सबसे पहले मुझे लगता है कि अपने स्वयं के प्रमाणीकरण तंत्र का आविष्कार करना कभी अच्छा विचार नहीं है।

अपने वर्तमान समस्याओं का जवाब करने के लिए:

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

चूंकि आप एक बाकी एपीआई का उपयोग कर रहे मैं दूसरे शब्दों के साथ राज्यविहीन अपने एपीआई रखने के लिए, किसी भी सत्र जानकारी नहीं रखते हैं सुझाव है। बस अपनी टोकन में आवश्यक भूमिका डेटा शामिल करें। उदाहरण के लिए आप JSON Web Token का उपयोग कर सकते हैं।

मैं प्राधिकरण डेटा भेजने के लिए हमेशा प्राधिकरण शीर्षलेख का उपयोग करता हूं। अपने DelegatingHandler में (अंतर संदेश हैडलर एमवीसी, DelegatingHander HTTP ध्यान दें) आप शीर्षलेख को पुनः प्राप्त कर सकते हैं।

protected override Task<HttpResponseMessage> SendAsync(
     HttpRequestMessage request, CancellationToken cancellationToken) 
{ 
    var authorizationHeader = request.Headers.Authorization; 
    // Your authorization logic. 

    return base.SendAsync(request, cancellationToken); 
} 

कैसे एक ajax कॉल में प्राधिकरण हैडर कृपया देखें शामिल करने के लिए के बारे में अधिक जानकारी के लिए: How to use Basic Auth with jQuery and AJAX?

अतिरिक्त जानकारी:

अगर मैं तुम्हें थे मैं भी Thinktecture के पर एक नज़र ले जाएगा पहचान सर्वर: https://github.com/thinktecture/Thinktecture.IdentityServer.v2

और शायद आरईएसटी सेवा प्रमाणीकरण के बारे में यह उत्तर आपको भी मदद करेगा: REST service authentication

+1

देर से यहां धन्यवाद धन्यवाद। लेकिन धन्यवाद! – vabz

0

क्यों एक संपूर्ण टोकन सिस्टम बनाते हैं (जब तक कि आप किसी प्रकार की संघीय सुरक्षा का उपयोग नहीं कर रहे हों) आपके पास कुकी सेट होने के बाद प्रमाणीकरण और कुकीज़ बन जाती है, ब्राउज़र आपके स्पा द्वारा किए गए किसी भी AJAX अनुरोध के साथ कुकी भेज देगा ।

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