माइक्रोसोर्सेज और उपभोक्ताओं के लिए प्राधिकरण और प्रमाणीकरण प्रणाली

Question

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

हम अनिश्चित हैं कि भूमिका और स्कोप को कैसे संभालना है। विचार यह है कि 3 मूल उपयोगकर्ता भूमिकाएं बनाएं जैसे कि Admins, Agent और End-Users और उपभोक्ता एप्स को जरूरत के हिसाब से ठीक-ठीक स्कोप करें।

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

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

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

इसका नकारात्मक पक्ष यह है कि हमारी टीम को हमारे आंतरिक अनुप्रयोगों में ठीक-ठीक पहुंच तंत्र बनाने की भी आवश्यकता होगी।

इस तरह की सोच के साथ, सूक्ष्म सेवाओं और उनके प्राधिकरण प्रणाली को ग्राहकों की जरूरतों से परेशान नहीं होना चाहिए, क्योंकि वे केवल उपभोक्ता हैं और सिस्टम का हिस्सा नहीं हैं (भले ही उन उपभोक्ताओं में से कुछ हमारे अपने आंतरिक ऐप हैं)?

क्या यह प्रतिनिधिमंडल एक अच्छा दृष्टिकोण है?

Answer 1

प्रमाणीकरण और प्राधिकरण हमेशा अच्छे विषय होते हैं

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

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

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

product

/products
/products/:id

payment

/payments/
/payments/:id

order

/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id

तो चलिए बताते हैं कि अब तक हमारी सेवा में तीन संसाधन हैं ; product, paymentऔर order।

क्रिया : यह एक ऑपरेशन है जिसे किसी संसाधन पर किया जा सकता है, जैसे, पढ़ना, बनाना, अपडेट करना, हटाना, आदि। यह केवल क्लासिक सीआरयूडी ऑपरेशन होने के लिए आवश्यक नहीं है follow, उदाहरण के लिए, यदि आपके पास है, तो आपके पास एक कार्रवाई हो सकती है एक ऐसी सेवा को उजागर करना चाहते हैं जो WebSockets का उपयोग करके किसी प्रकार की सूचना का प्रसार करती है।

क्षमता : एक actionपर प्रदर्शन करने की क्षमता resource। उदाहरण के लिए; उत्पाद पढ़ें, उत्पाद बनाएं, आदि यह मूल रूप से सिर्फ एक संसाधन / एक्शन जोड़ी है। लेकिन आप इसमें एक नाम और विवरण भी जोड़ सकते हैं।

भूमिका : क्षमताओं का एक सेट जो एक उपयोगकर्ता स्वयं कर सकता है। उदाहरण के लिए, एक भूमिका में Cashier"रीड पेमेंट", "भुगतान बनाएं" जैसी क्षमताएं हो सकती हैं या एक भूमिका में Seller"रीड प्रोडक्ट", "रीड ऑर्डर", "अपडेट ऑर्डर", "ऑर्डर हटाएं" जैसी क्षमताएं हो सकती हैं।

अंत में, उपयोगकर्ता के पास उसे सौंपी गई विभिन्न भूमिकाएँ हो सकती हैं।

---

व्याख्या

जैसा कि मैंने पहले कहा था, हम JSON वेब टोकन का उपयोग करते हैं और उपयोगकर्ता के पास टोकन के पेलोड में घोषित क्षमताएँ हैं। तो, मान लीजिए कि हमारे पास एक छोटे खुदरा स्टोर के लिए एक ही समय में कैशियर और विक्रेता की भूमिकाओं वाला एक उपयोगकर्ता है। पेलोड इस तरह दिखेगा:

{
    "scopes": {
        "payment": ["read", "create"],
        "order": ["read", "create", "update", "delete"]
    }
}

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

---

• संसाधनों को कैसे समूह और नाम दें और क्रियाओं और क्षमताओं को कैसे परिभाषित और नाम दें, यह डेवलपर्स द्वारा किया गया निर्णय होगा।

• क्या भूमिकाएं हैं और उन क्षमताओं में क्या भूमिकाएं होंगी, ग्राहकों द्वारा किए गए निर्णय हैं।

---

बेशक, आपको पेलोड में उपयोगकर्ता और ग्राहक (किरायेदार) की पहचान करने के लिए अतिरिक्त गुण जोड़ना होगा, जिसने टोकन जारी किया था।

{
    "scopes": {
        ...
    },
    "tenant": "acme",
    "user":"coyote"
}

---

इस विधि से, आप अपनी सेवा में किसी भी उपयोगकर्ता खाते की पहुंच को ठीक कर सकते हैं। और सबसे महत्वपूर्ण, आपको विभिन्न पूर्वनिर्धारित और स्थिर भूमिकाएँ बनाने की ज़रूरत नहीं है, जैसे कि व्यवस्थापक, एजेंट, और अंत-उपयोगकर्ता जैसे आप अपने प्रश्न में बताते हैं। एक सुपर उपयोगकर्ता एक उपयोगकर्ता होगा जो उसके पास सौंपी गई सेवा और roleसभी के साथ होता है।resourcesactions

अब, क्या होगा अगर 100 संसाधन हैं और हम एक ऐसी भूमिका चाहते हैं जो सभी या लगभग सभी को एक्सेस दे। हमारा टोकन पेलोड बहुत बड़ा होगा। यह संसाधनों को नेस्ट करने और अभिगम टोकन दायरे में मूल संसाधन को जोड़कर हल किया जाता है।

---

प्राधिकरण एक जटिल विषय है जिसे प्रत्येक एप्लिकेशन की आवश्यकताओं के आधार पर संबोधित किया जाना चाहिए।

Comments

आपके जवाब के लिए धन्यवाद। यह बहुत मददगार है। मेरे पास प्रति उपयोगकर्ता कई भूमिकाओं से संबंधित प्रश्न है। क्या आपके पास कभी ऐसा मामला है जहां भूमिका अनुमतियाँ ओवरलैप होती हैं? जैसे कैशियर के पास होता है payment:[read], विक्रेता के पास होता है payment: [create]। क्या आप इस मामले में अनुमति एकत्र करते हैं?

— रॉबर्ट

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

— मिसो

क्या होगा यदि कोई उपयोगकर्ता केवल उन संसाधनों पर कार्रवाई करने की क्षमता रख सकता है जो वे ओ.एन.टी. उदाहरण के लिए एक बैंक खाते की तरह, निश्चित रूप से "bank_account": ["पढ़ा", "अपडेट"] यह निर्दिष्ट नहीं करता है। इसके अलावा, वास्तव में एक माइक्रोसेवा सिस्टम में प्राधिकरण की प्रक्रिया क्या होती है? एक केंद्रीकृत प्राधिकरण सर्वर पर, या प्रत्येक सेवा अपना प्राधिकरण करती है?

— रॉकेट्सपेसर

@rocketspacer। इसलिए टोकन के पास userअपने पेलोड में संपत्ति है। जिस तरह से मैं एक उपयोगकर्ता के स्वामित्व वाले संसाधन को लॉक करता हूं userवह URL के दावे को मैप करके है । उदाहरण के लिए: /users/coyote/back-accountकेवल userदावे के बराबर टोकन के साथ सुलभ होगा coyote। मुझे उम्मीद है कि मदद

— मिसो

Answer 2

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

चूँकि सभी कॉलर्स को आपके माइक्रोसॉफ़्ट साक्ष्य प्रदान करने की आवश्यकता होती है जिसे वे प्रमाणित कर चुके हैं, आप उस प्रमाणीकरण के लिए अनुमतियाँ भी बाँध सकते हैं। यदि आप किसी उपयोगकर्ता को मनमाने तरीके से एक्सेस ग्रुप (या ग्रुप्स में बाँधना चाहते हैं, यदि आप फैंसी लेना चाहते हैं, तो अनुमतियाँ जोड़ना या घटाना यहाँ से निपटना कठिन है।), आपके ग्राहकों से कम सवाल आएंगे कि उपयोगकर्ता क्यों। एक्स एक अवांछित ऑपरेशन करने में सक्षम था। किसी भी मामले में किसी को प्रत्येक सेवा के लिए एक्सेस सूची की जाँच करनी होती है, इसलिए यह आप भी हो सकते हैं। यह कुछ ऐसा है जो सभी सेवाओं की शुरुआत में बहुत आसानी से कोडित हो जाएगा (if ( !TokenAuthorized(this.ServiceName, this.token) { Raise error }) कि आप ऐसा कर सकते हैं और उपयोगकर्ता समूहों का ध्यान रखें। यह सच है कि आपके पास एक अनुमतियाँ समूह प्रबंधक होनी चाहिए, और इसे उपयोगकर्ता प्रबंधन UI में उपयोग करें (उपयोगकर्ता अनुमतियों के लिए मौजूदा / नया समूह बनाएं) निश्चित रूप से भ्रम की स्थिति से बचने के लिए परिभाषा को संपादित करते समय समूह से बंधे उपयोगकर्ताओं को सूचीबद्ध करें । लेकिन, यह कठिन काम नहीं है। बस सभी सेवाओं के लिए मेटाडेटा है, और समूह और सेवा के बीच मैपिंग को देख कर टोकन हैंडलिंग में टाई करें।

ठीक है, इसलिए काफी कुछ विवरण हैं, लेकिन आपके प्रत्येक ग्राहक जो चाहते हैं कि यह कार्यक्षमता किसी भी स्थिति में इसे कोड करना होगा, और यदि आप तीन स्तरीय उपयोगकर्ता अनुमतियों का समर्थन करते हैं, तो आप इसे प्रति उपयोगकर्ता पहुंच के अनुसार बढ़ा सकते हैं। समूहों। संभवतः आधार समूह की अनुमतियों और उपयोगकर्ता की विशिष्ट अनुमतियों के बीच एक तार्किक प्रतिच्छेदन सही एकत्रीकरण होगा, लेकिन यदि आप व्यवस्थापक, एजेंट, अंतिम-उपयोगकर्ता आधार अनुमतियों के आधार अनुमतियों को जोड़ना और ले जाना चाहते हैं, तो आपको करना होगा us बेकार ट्राई-स्टेट फ्लैग इन परमिशन ग्रुप्स: परमिशन, डेनी परमिशन, डिफाल्ट परमिशन जोड़ें और अनुमतियों को उचित रूप से संयोजित करें।

(एक नोट के रूप में, यह सब SSL या यहां तक ​​कि दो-तरफ़ा SSL जैसी किसी चीज़ पर होना चाहिए यदि आप बातचीत के दोनों की सुरक्षा के बारे में चिंतित हैं। यदि आप किसी हमलावर के लिए इन टोकन को "लीक" करते हैं, तो वह इस तरह है जैसे कि वह ' डी एक पासवर्ड फटा।)

Comments

बुनियादी ढांचे और कार्यान्वयन के बारे में सोचते हुए, मैं ग्राहक अनुभव के बारे में पूरी तरह से भूल गया .. मुझे नियमों का सेट बनाने का विचार पसंद है जो हमारे व्यवसाय के साथ अधिक होगा। एडमिन, एजेंट और एंड-यूज़र बहुत सामान्य हैं और हम अधिक उपयोगकर्ता प्रकारों को लागू करने की योजना बनाते हैं, जो अधिक वर्णनात्मक हैं और हमारे व्यवसाय और सर्वव्यापी भाषा के साथ बंधे हैं।

— रॉबर्ट

मैं अंतिम वाक्य में "anded" टाइपो को ठीक करने में सक्षम नहीं था क्योंकि मैं इसे समझ नहीं पाया।

— ट्यूलेंस कोरडोवा

यह आवश्यक रूप से एक टाइपो नहीं है, लेकिन मैं इसे स्पष्ट कर

— दूंगा

Answer 3

मेरा विचार है कि आपके पास यहाँ दो विकल्प हैं।

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

• यदि आपके ग्राहक अपने स्वयं के एप्लिकेशन विकसित कर रहे हैं, तो उन्हें अपने स्वयं के मध्यवर्ती एपीआई का परिचय देना चाहिए। जो आपको व्यवस्थापक के रूप में जोड़ता है, लेकिन आपकी सेवाओं को कॉल करने से पहले अपनी स्वयं की कस्टम आवश्यकताओं के खिलाफ आने वाले अनुरोध की जांच करता है

Answer 4

सुरक्षा पर विचार

यदि मैं आपके डिज़ाइन को अच्छी तरह से समझता हूं, तो आप ग्राहक पक्ष के लिए कुछ संसाधन अभिगम नियंत्रण तंत्रों को सौंपने का इरादा रखते हैं, अर्थात एक उपभोगता ऐप उन वस्तुओं को कम कर देता है जो एक उपयोगकर्ता देख सकता है। आपकी धारणा है:

सूक्ष्म सेवाओं और उनके प्राधिकरण प्रणाली को ग्राहकों की जरूरतों से परेशान नहीं होना चाहिए, क्योंकि वे केवल उपभोक्ता हैं और सिस्टम का हिस्सा नहीं हैं

मैं यहां देख रहा हूं कि गंभीर व्यवसाय के लिए दो गंभीर समस्याएं हैं:

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

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

यदि आप अपनी वर्तमान स्थिति पर आगे बढ़ते हैं, तो कम से कम अपने सूचना सुरक्षा अधिकारी से परामर्श करें।

इसे कैसे लागू किया जाए

आपके पास चाल है:

इस तरह, हमें केवल टोकन स्कोप को ट्रैक करना होगा।

ठीक है, आप ग्राहक द्वारा चुने गए कुछ सामान्य टोकन का उपयोग करने का इरादा रखते हैं। फिर से मेरी नजर में कमजोरी, क्योंकि कुछ ग्राहक आपके नियंत्रण से बाहर हो सकते हैं।

मुझे नहीं पता कि आप पहले से ही JWT का उपयोग करते हैं या यदि आप कुछ अन्य तकनीकों का उपयोग करते हैं। लेकिन अगर आप JWT का उपयोग करते हैं, तो आपके पास एक पहचान टोकन हो सकता है जो उपयोगकर्ता की पहचान को आगे बढ़ाता है (और यहां तक ​​कि एक दूसरा टोकन जो सुरक्षित रूप से मूल एप्लिकेशन की पहचान करता है, जो आपको इन-हाउस क्लाइंट और बाहरी ग्राहकों के बीच विश्वास के स्तर को अलग करने की अनुमति दे सकता है) )।

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

Comments

यहाँ बहुत अच्छी सलाह है। मुझे दूसरे टोकन के साथ विचार पसंद है।

— रॉबर्ट

Answer 5

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