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

मैं हालांकि इसके लिए सुरक्षा के स्तर पर चिंतित हूं।

कुछ प्रसंग
चूंकि हमारा मंच बहु-किरायेदार है, हम अनुरोध करते हैं कि प्रत्येक ग्राहक अपने Azure AD पोर्टल पर आवेदन पंजीकृत करें, फिर हमें उत्पन्न आवेदन (क्लाइंट आईडी) और निर्देशिका (किरायेदार) आईडी< प्रदान करें। /em>. हम अपने फ़्रंट-एंड एसपीए के माध्यम से Azure के लिए प्रारंभिक अनुरोध करने के लिए जानकारी के इन दो टुकड़ों का उपयोग करते हैं (किसी ऐप को पंजीकृत करते समय Microsoft की Quickstart मार्गदर्शिका द्वारा प्रदान किए गए node.js उदाहरण के बाद)। अब क्योंकि उपयोगकर्ता इस बिंदु पर अनधिकृत है, हमें क्लाइंट के लिए उन दो विशिष्ट आईडी को वापस करने के लिए किसी तरह की आवश्यकता है। हमने पहचान के लिए उप-डोमेन का उपयोग करके इसे पूरा किया है।

उदा. acmeinc.mydomain.com billy.mydomain.com की तुलना में एक अलग एप्लिकेशन (क्लाइंट आईडी) और डायरेक्टरी (टेनेंट) आईडी लौटाएगा। ये स्पष्ट रूप से अब सार्वजनिक हैं क्योंकि यह अनुरोध एक गैर-प्रमाणित फ़्रंट-एंड रूट से होता है।

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

क्या मुझसे कोई चूक हो रही है? अगर क्लाइंट से अनुरोध करना संभव होता तो मैं और अधिक सहज महसूस करता, जिसमें यह दावा भी शामिल होता है कि मेरा प्लेटफॉर्म निजी तौर पर इस तरह से उत्पन्न होता है कि मैं सामान्य JWT सत्यापन के साथ इस दावे को मान्य कर सकता हूं। Azure AD पोर्टल से कस्टम दावे संभव नहीं लगते हैं।

क्या मुझे एक महत्वपूर्ण कदम याद आ रहा है, या बस इस पर विचार कर रहा हूं?

0
JP Damstra 30 मार्च 2020, 19:22

1 उत्तर

सबसे बढ़िया उत्तर

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

यदि आप मानक JWT सत्यापन का उपयोग कर रहे हैं तो आपका बैक-एंड पहले से ही इस हस्ताक्षर को मान्य कर रहा होगा।

ग्राहकों को अपने टैनेंट में एक ऐप पंजीकृत करने के लिए कहना एक छोटा सा काम है जिसे मैं उन पर नहीं डालना पसंद करूंगा। क्या आपने अपने ऐप को Azure AD में एक बहु-किरायेदार ऐप बनाने पर विचार किया है? इस तरह आपके ग्राहक आपके ऐप में लॉग इन कर सकते हैं, आवश्यक अनुमतियों के लिए सहमति दे सकते हैं और इसका उपयोग शुरू कर सकते हैं। मैन्युअल रूप से कुछ भी पंजीकृत करने की आवश्यकता के बिना। यह एक ऑन-बोर्डिंग प्रवाह में किया जा सकता है जहां उपयोगकर्ता साइन इन करता है, और फिर वे तय कर सकते हैं कि उन्हें कौन सा उप-डोमेन चाहिए। तब आपको उनकी टेनेंट आईडी पता चल जाएगी, जिसे आप स्टोर कर सकते हैं। इसलिए भविष्य में साइन इन करते समय आप हमेशा सही टैनेंट/निर्देशिका आईडी का उपयोग कर सकते हैं।

इस दृष्टिकोण का नकारात्मक पक्ष उत्तर URL का प्रबंधन कर रहा है। विशेष रूप से पंजीकृत ऐप्स के साथ, वे अपने स्वयं के उप-डोमेन संस्करण को उत्तर URL के रूप में पंजीकृत कर सकते हैं। इस सामान्य बहु-किरायेदार ऐप के साथ, आपको उन्हें प्रबंधित करने की आवश्यकता होगी। और आप उनमें से एक अनंत राशि नहीं जोड़ सकते हैं, और वाइल्डकार्ड भी अब समर्थित नहीं हैं। इसलिए, आपका प्रमाणीकरण सामान्य प्रमाणीकरण उत्तर URL जैसे auth.mydomain.com के साथ होना चाहिए, जिससे उन्हें उनके टैनेंट URL पर रीडायरेक्ट किया जाएगा।

1
juunas 30 मार्च 2020, 16:38