wcf - एक आरईएसटी एपीआई/वेब सेवा को सुरक्षित करने के लिए सर्वोत्तम अभ्यास




security rest (12)

एक आरईएसटी एपीआई या सेवा को डिजाइन करते समय सुरक्षा (प्रमाणीकरण, प्रमाणीकरण, पहचान प्रबंधन) से निपटने के लिए कोई स्थापित सर्वोत्तम प्रथाएं हैं?

एक एसओएपी एपीआई बनाने के दौरान आपके पास एक गाइड के रूप में डब्ल्यूएस-सुरक्षा है और विषय पर अधिक साहित्य मौजूद है। मुझे आरईएसटी एंडपॉइंट्स को सुरक्षित करने के बारे में कम जानकारी मिली है।

जबकि मैं समझता हूं कि आरईएसटी जानबूझकर डब्ल्यूएस- * के समान विनिर्देश नहीं है। मुझे उम्मीद है कि सर्वोत्तम प्रथाओं या अनुशंसित पैटर्न उभरे हैं।

प्रासंगिक दस्तावेजों के लिए कोई भी चर्चा या लिंक बहुत सराहना की जाएगी। यदि यह मायने रखता है, तो हम .NET Framework के v3.5 का उपयोग करके निर्मित हमारे आरईएसटी एपीआई / सेवाओं के लिए पीओएक्स / जेएसओएन क्रमबद्ध संदेशों के साथ डब्ल्यूसीएफ का उपयोग करेंगे।


HTTP के अलावा आरईएसटी के लिए कोई मानक नहीं है। वहाँ आरईएसटी सेवाओं की स्थापना की गई है। मेरा सुझाव है कि आप उन पर एक नज़र डालें और महसूस करें कि वे कैसे काम करते हैं।

उदाहरण के लिए, हमने अपने विकास के दौरान अमेज़ॅन की एस 3 आरईएसटी सेवा से बहुत से विचार उधार लिया। लेकिन हमने अनुरोध हस्ताक्षरों के आधार पर अधिक उन्नत सुरक्षा मॉडल का उपयोग न करने का विकल्प चुना। एसएसएल पर HTTP बेसिक ऑथ सरल तरीका है। आपको यह तय करना होगा कि आपकी स्थिति में सबसे अच्छा क्या काम करता है।

इसके अलावा, मैं ओरेली से रीस्टफुल वेब सर्विसेज की पुस्तक की अत्यधिक अनुशंसा करता हूं। यह मूल अवधारणाओं को समझाता है और कुछ सर्वोत्तम प्रथाओं को प्रदान करता है। आप आम तौर पर उनके द्वारा प्रदान किए जाने वाले मॉडल को ले सकते हैं और इसे अपने स्वयं के एप्लिकेशन में मैप कर सकते हैं।


आप विशेष रूप से http apis को लक्षित करने वाले टोकन-आधारित प्राधिकरण के लिए उभरते खुले प्रोटोकॉल OAuth को भी देखना चाहते हैं।

यह flickr द्वारा उठाए गए दृष्टिकोण के समान ही है और दूध "आराम" एपिस याद रखें (जरूरी एपिस के जरूरी अच्छे उदाहरण नहीं, बल्कि टोकन-आधारित दृष्टिकोण के अच्छे उदाहरण हैं)।


इन उत्तरों में से प्रत्येक ने सही पहुंच नियंत्रण / प्राधिकरण को अनदेखा कर दिया है।

उदाहरण के लिए यदि आपकी आरईएसटी एपीआई / वेब सेवाएं पोस्टिंग / मेडिकल रिकॉर्ड्स प्राप्त करने के बारे में हैं, तो आप एक्सेस कंट्रोल पॉलिसी को परिभाषित करना चाहेंगे कि डेटा तक कौन पहुंच सकता है और किस परिस्थिति में। उदाहरण के लिए:

  • डॉक्टर एक मरीज़ के मेडिकल रिकॉर्ड प्राप्त कर सकते हैं जिसके साथ उनका देखभाल संबंध है
  • अभ्यास घंटे के बाहर कोई भी मेडिकल डेटा पोस्ट नहीं कर सकता (उदाहरण के लिए 9 से 5)
  • अंत उपयोगकर्ता अपने मेडिकल रिकॉर्ड प्राप्त कर सकते हैं या रोगियों के मेडिकल रिकॉर्ड प्राप्त कर सकते हैं जिनके लिए वे अभिभावक हैं
  • नर्स एक रोगी के मेडिकल रिकॉर्ड को अद्यतन कर सकती हैं जो नर्स के समान इकाई से संबंधित है।

उन सुगंधित प्राधिकरणों को परिभाषित और कार्यान्वित करने के लिए, आपको XACML नामक एक विशेषता-आधारित पहुंच नियंत्रण भाषा का उपयोग करना होगा, जो एक्स्टेंसिबल एक्सेस कंट्रोल मार्कअप भाषा है।

यहां अन्य मानदंड निम्नलिखित हैं:

  • ओथ: आईडी। प्राधिकरण के संघ और प्रतिनिधिमंडल जैसे कि मेरी ओर से दूसरी सेवा पर एक सेवा अधिनियम देना (फेसबुक मेरे ट्विटर पर पोस्ट कर सकता है)
  • एसएएमएल: पहचान संघ / वेब एसएसओ। SAML बहुत है कि उपयोगकर्ता कौन है।
  • डब्ल्यूएस-सुरक्षा / डब्ल्यूएस- * मानकों: एसओएपी सेवाओं के बीच संचार पर ये ध्यान केंद्रित करते हैं। वे एप्लिकेशन-स्तरीय मैसेजिंग प्रारूप (एसओएपी) के लिए विशिष्ट हैं और वे संदेश के पहलुओं जैसे विश्वसनीयता, सुरक्षा, गोपनीयता, अखंडता, परमाणुता, घटनाक्रम से निपटते हैं ... कोई भी कवर एक्सेस नियंत्रण नहीं है और सभी SOAP के लिए विशिष्ट हैं।

एक्सएसीएमएल प्रौद्योगिकी-अज्ञेयवादी है। इसे जावा ऐप, .NET, पायथन, रूबी ... वेब सेवाओं, आरईएसटी एपीआई आदि पर लागू किया जा सकता है।

निम्नलिखित दिलचस्प संसाधन हैं:


उत्कृष्ट सलाह के लिए धन्यवाद। माइक्रोसॉफ्ट से आने वाले ज़र्मट पहचान फ्रेमवर्क के साथ हमारे रीस्टफुल एपीआई को एकीकृत करने की तैयारी में, क्लाइंट से सेवा में पहचान टोकन पास करने के लिए हमने एक कस्टम HTTP शीर्षलेख का उपयोग समाप्त कर दिया। मैंने here समस्या और here हमारे समाधान here वर्णन किया है। मैंने tweakt की सलाह भी ली और tweakt वेब सर्विसेज खरीदी - एक बहुत अच्छी किताब अगर आप किसी भी प्रकार का एक रीस्टफुल एपीआई बना रहे हैं।


जैसा कि @ नाथन समाप्त हुआ जिसके साथ एक साधारण HTTP हैडर है, और कुछ ने ओएथ 2 और क्लाइंट साइड एसएसएल प्रमाण पत्र कहा था। इसका अर्थ यह है कि ... आपके आरईएसटी एपीआई को सुरक्षा को संभालना नहीं चाहिए क्योंकि वास्तव में एपीआई के दायरे से बाहर होना चाहिए।

इसके बजाय एक सुरक्षा परत को इसके ऊपर रखा जाना चाहिए, भले ही यह एक वेब प्रॉक्सी (साइटमैंडर, ज़र्मट या यहां तक ​​कि अपाचे HTTPd जैसे एक सामान्य दृष्टिकोण) के पीछे एक HTTP शीर्षलेख है, या ओएथ 2 के रूप में जटिल है।

मुख्य बात यह है कि अनुरोधों को किसी भी अंत उपयोगकर्ता इंटरैक्शन के बिना काम करना चाहिए। यह आवश्यक है कि आरईएसटी एपीआई के कनेक्शन को प्रमाणित किया जाए। जावा ईई में हमारे पास एक उपयोगकर्ता userPrincipal की धारणा है जिसे HttpServletRequest पर प्राप्त किया जा सकता है। यह तैनाती वर्णनकर्ता में भी प्रबंधित है कि एक यूआरएल पैटर्न सुरक्षित हो सकता है ताकि आरईएसटी एपीआई कोड को और जांचने की आवश्यकता न हो।

डब्ल्यूसीएफ दुनिया में, मैं वर्तमान सुरक्षा संदर्भ प्राप्त करने के लिए ServiceSecurityContext.Current का उपयोग करूंगा। प्रमाणीकरण की आवश्यकता के लिए आपको एप्लिकेशन को कॉन्फ़िगर करने की आवश्यकता है।

मेरे ऊपर दिए गए बयान में एक अपवाद है और यह रीप्ले को रोकने के लिए एक गैर-उपयोग का उपयोग है (जो हमले हो सकता है या कोई भी दो बार एक ही डेटा सबमिट कर सकता है)। उस भाग को केवल एप्लिकेशन परत में ही संभाला जा सकता है।


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

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

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


मैं ओथ 2/3 की सिफारिश करता हूं। आप http://oauth.net/2/ पर अधिक जानकारी प्राप्त कर सकते हैं


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


मैंने आराम से सुरक्षा के बारे में बहुत कुछ खोजा और हम अनुरोधों को प्रमाणित करने के लिए क्लाइंट से सर्वर तक कुकी के माध्यम से टोकन का उपयोग करने के साथ समाप्त हो गए। मैंने सेवा में अनुरोधों के प्रमाणीकरण के लिए वसंत सुरक्षा का उपयोग किया क्योंकि मुझे पहले से ही डीबी में निर्दिष्ट सुरक्षा नीतियों के आधार पर प्रत्येक अनुरोध को प्रमाणीकृत और अधिकृत करना था।


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

http://hueniverse.com/oauth/guide/


वेब एप्लिकेशन सुरक्षा के लिए, आपको OWASP ( https://www.owasp.org/index.php/Main_Page ) पर एक नज़र डालना चाहिए जो विभिन्न सुरक्षा हमलों के लिए चीटशीट प्रदान करता है। आप अपने आवेदन को सुरक्षित करने के लिए जितना संभव हो उतना उपाय शामिल कर सकते हैं। एपीआई सुरक्षा (प्रमाणीकरण, प्रमाणीकरण, पहचान प्रबंधन) के संबंध में, पहले से ही उल्लेख किए गए कई तरीके हैं (बेसिक, डाइजेस्ट और ओथ)। OAuth1.0 में लूप छेद हैं, इसलिए आप OAuth1.0a का उपयोग कर सकते हैं (OAuth2.0 विनिर्देश के साथ चिंताओं के कारण व्यापक रूप से अपनाया नहीं जाता है)


सुरक्षा के संबंध में मैंने कभी भी सबसे अच्छी पोस्टों में से एक है क्योंकि यह आरईएसटी से संबंधित है, 1 रेनड्रॉप पर है । माइस्पेस एपीआई का उपयोग सुरक्षा के लिए ओएथ भी है और आपके पास रीस्टचेस कोड में उनके कस्टम चैनलों तक पूर्ण पहुंच है, जिस पर मैंने बहुत सी खोज की है। यह मिक्स में डेमो किया गया था और आप here पोस्टिंग पा सकते हैं।





rest-security