2017-07-17 31 views
5

कार्यान्वयन अज्ञेय चर्चा।OAuth2 संसाधन सर्वर से दूसरे

निम्नलिखित आरेख मानें। enter image description here

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

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

उस बिंदु से, यह स्पष्ट है कि क्लाइंट को एक संसाधन सर्वर तक पहुंचने की आवश्यकता होने पर क्या होता है। सर्वर संसाधन और हासिल कर ली टोकन

  • संसाधन सर्वर पारित करने के लिए

    1. मेक अनुरोध टोकन मान्य करता है (कैसे अप्रासंगिक)
    2. वैध, तो अनुरोध सेवा करते हैं।

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

    जब क्लाइंट आरेख में लाल रेखा का अनुसरण करता है तो मुझे परेशानी हो रही है। तो मुझे किसी सेवा (संसाधन सर्वर) तक पहुंचने की आवश्यकता है जो किसी अन्य सेवा (संसाधन सर्वर) तक पहुंचने के लिए उत्तर देने के लिए उत्तर देने के लिए है। प्रवाह उस मामले में कैसे जाता है?

    परिदृश्य 1.

    1. "आदेश सेवा" दोनों एक संसाधन सर्वर के रूप में और एक ग्राहक के रूप में सेटअप है।
    2. क्लाइंट एक्सेस टोकन के साथ अनुरोध करता है लेकिन "ऑर्डर सेवा" "डेटा सेवा" से बात करने के लिए अपने क्लाइंट प्रमाण-पत्रों के साथ एक और टोकन प्राप्त करेगा।

    यहां समस्या यह है कि मैं इसे देखता हूं कि मैं उपयोगकर्ता अनुमतियों को खो देता हूं। मैं "आदेश सेवा" अनुमतियों के साथ "डेटा सेवा" के अनुरोध को निष्पादित करूंगा, न कि उपयोगकर्ता की अनुमतियां।

    परिदृश्य 2.

    1. "आदेश सेवा" केवल एक संसाधन सर्वर के रूप में सेटअप है।
    2. क्लाइंट उपयोगकर्ता टोकन और "आदेश सेवा" के साथ अनुरोध "डेटा सेवा"

    यहाँ मैं प्रयोक्ता की अनुमति के साथ निष्पादित लेकिन अब मैं देखने के लिए नीचे इसी अग्रेषित करेंगे करता है कि मेरी "डेटा सेवा "खुलासा है और किसी भी अन्य सेवा के लिए खुला है। (वास्तव में मैं पता नहीं है, तो इस तरह के OAuth2 सीमा प्रदान करता है। केवल विशिष्ट संसाधन सर्वर के लिए एक ग्राहक को सीमित करें)

    परिदृश्य 3.

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

    कार्यान्वयन

    मैं सेटअप करने के क्रम में वसंत बूट और वसंत सुरक्षा का उपयोग कर रहा मेरी OAuth2 घटकों ऊपर देखा। मेरे पास पहले से ही एक ऑथ सर्वर, संसाधन सर्वर और क्लाइंट है। फिलहाल ग्राहक संसाधन संसाधन सर्वर से किसी अन्य संसाधन सर्वर को दिए गए अनुरोध के बिना बात करता है।

    सर्वोत्तम दृष्टिकोण के आधार पर मैं कार्यान्वयन पक्ष पर कैसे जाऊं? मेरे संसाधन सर्वर को बनाने के लिए मुझे किन परिवर्तनों की आवश्यकता है ताकि वे एक-दूसरे से सुरक्षित रूप से बात कर सकें?

    अपना समय

  • उत्तर

    0

    आप प्राधिकरण और पहचान अवधारणाओं मिश्रण कर रहे हैं के लिए धन्यवाद।

    OAuth2 भूमिकाओं (resource owner, resource server, authorization server और client) भूमिकाओं और नहीं पहचान रहे हैं। आपकी ऑर्डर सेवा में एक परिदृश्य में resource server भूमिका है और दूसरे में client भूमिका है।

    परिदृश्य 1 सही दृष्टिकोण है।

    ओथ 2 टोकन वास्तव में कुछ संसाधन पहचानकर्ताओं से बंधे हैं और इसलिए किसी विशिष्ट संसाधन को क्लाइंट को सीमित करना एक अंतर्निहित सुविधा है।

    ग्राहक संबंधित प्राधिकरण सेट OAuth2 scope अवधारणा

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

    1

    मेरी समझ से, पहला दृष्टिकोण सही लगता है, "ऑर्डर सेवा" क्लाइंट के रूप में "डेटा सेवा" संसाधन सर्वर के लिए कार्य करता है। इसलिए इसे क्लाइंट के रूप में प्रदान किए गए एक्सेस टोकन का उपयोग करना चाहिए।

    ओआईडीसी विशेष रूप से ग्राहकों के लिए इरादा है (here पढ़ें। यह भी "क्यों उपयोग का उपयोग-टोकन-टू-सुरक्षित-apis" के लिए उस पृष्ठ पर देखने के लिए), कोई संसाधन सर्वर कुछ भी है कि id_token का उपयोग करना चाहिए (लेकिन यह सच है कि प्रत्येक कार्यान्वयनकर्ता उस मामले पर अपने फैसले का पालन करता है, इसलिए यह भ्रमित है। मैं here पढ़ने की अनुशंसा करता हूं)।

    1. "आदेश सेवा" "डाटा सेवा" संसाधनों के तहत पूर्ण नियंत्रण के साथ एक ग्राहक के रूप में कार्य करने के लिए (या कम से:

      तो, देखने की मेरी बात से, हम इन विकल्पों तक पहुँचने के लिए आप के लिए क्या पूछा है कम से कम 'संसाधन प्रकार' जिसे आप एक्सेस करना चाहते हैं)। यदि आपको "डेटा सेवा" प्रदान करने की आवश्यकता है, तो "ऑर्डर सेवा" के लिए उत्प्रेरक कौन था, इसके बारे में कुछ जानकारी मांगने के लिए, तो संसाधन का अनुरोध करते समय यह पेलोड का हिस्सा है (यह access_token का हिस्सा नहीं है)।

    2. संसाधन स्वामी (उपयोगकर्ता) ने पहले "ऑर्डर सेवा" को अपने "डेटा सेवा" विशिष्ट संसाधनों तक विशिष्ट पहुंच प्रदान की थी। पिछले बिंदु की तरह, लेकिन "ऑर्डर सेवा" के पास सभी "डेटा सेवा" संसाधनों तक पहुंच नहीं है। पेलोड के हिस्से के रूप में अभी भी उत्प्रेरक से जानकारी।
    3. पेलोड के हिस्से के रूप में उत्प्रेरक जानकारी को पार करने से बचने के लिए, मुझे लगता है कि हमें "ऑर्डर सेवा" क्लाइंट क्रेडेंशियल्स 'मांग पर' उत्पन्न करने में सक्षम होना चाहिए, जिसमें संसाधन मालिक के संबंध में कुछ फ़ील्ड हैं, या किसी भी तरह से उपयोगकर्ता पहले से बना रहे हैं उन्हें और उनकी प्रोफ़ाइल से जोड़ने ताकि बाद में "ऑर्डर सेवा" द्वारा पुनर्प्राप्त किया जा सके। यही वह जगह है जहां यह मेरे उपक्रम में गन्दा हो जाता है, और दस्तावेज स्पष्ट नहीं है (OAuth2 आरएफसी उसको कवर नहीं करता है)।
    4. पूरे सिस्टम को केवल एक ग्राहक के साथ देखें। फ्रंट क्लाइंट से प्राप्त access_token (जिस उपयोगकर्ता के साथ इंटरैक्ट करता है) में सभी विशिष्ट स्कोप आवश्यक होते हैं। दोनों "क्लाइंट", "ऑर्डर सर्विस", "ग्राहक सेवा" एक ही ग्राहक प्रमाण-पत्र साझा करते हैं और एक तरफ से "एक्सेस टोकन" को आगे बढ़ाते हैं (इसलिए यह अब "क्लाइंट क्रेडेंशियल्स अनुदान" नहीं है)। तो वे दोनों अनुमतियों का एक ही सेट है। जब संसाधन प्राधिकरण सर्वर पर पहला लॉगिन करता है तो संसाधन स्वामी उन अनुमतियों को प्रदान करेगा, इसलिए यह बुरा नहीं है। लेकिन जाहिर है इसका मतलब है कि आप प्रत्येक 'सबमिशन क्लाइंट' से अनुमतियां परिशोधित नहीं कर सकते हैं और संसाधन सर्वर यह निर्धारित करने में सक्षम नहीं होंगे कि एक्सेस टूकेन उपयोगकर्ता अनुरोध अनुरोध (यदि आवश्यक हो, तो यह पेलोड का हिस्सा होना चाहिए) के आधार पर कौन सा 'सबमिशन' अनुरोध था। इस के लिए सुरक्षा प्रभाव है।

    मैंने अभी तक वैकल्पिक 4 का उपयोग किया है (यह आंतरिक नेटवर्क उद्देश्यों के लिए था)। तो वास्तविक दुनिया में अन्य 3 के बारे में ज्यादा कुछ नहीं कह सकता।

    मुझे अभी तक 'समुदाय स्वीकार किए गए मानकों' के आधार पर एक ठोस स्पष्टीकरण देखने के लिए अभी तक एक ठोस स्पष्टीकरण देखने के लिए नहीं है (और यह सीधे विनिर्देशों का खंडन नहीं करता है)।

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