2015-05-28 11 views
7

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

यहां तक ​​कि सबकुछ बढ़िया है। लेकिन अब मेरे पास समस्या यह है कि मैं बहु किरायेदारी सक्षम करना चाहता हूं, इसलिए बाहरी एडी निर्देशिका के उपयोगकर्ता मेरे ऐप में लॉगिन कर सकते हैं। यह काम करता है, लेकिन मुझे खाते के लिए व्यवस्थापक के रूप में लॉगिन करने की आवश्यकता है क्योंकि यह को निर्देशिका में पढ़ने-लिखने की पहुंच भी पूछता है।

क्या इसे ठीक करने का कोई तरीका है? मैं केवल उपयोगकर्ता खातों को बनाने में सक्षम होने के लिए अपनी निर्देशिका में पढ़ने-लिखने की पहुंच चाहता हूं। मैं अपनी निर्देशिका को छूने की अनुमति नहीं मांगना चाहता क्योंकि शायद, वे मेरे ऐप पर भरोसा नहीं करेंगे।

धन्यवाद।

+0

संक्षिप्त उत्तर नहीं है, आप नहीं कर सकते हैं। एज़ूर में एडी 2 के साथ एडी 1 को एकीकृत करने के तरीके हैं, लेकिन यह 2 विशिष्ट डोमेन के साथ है, न कि "सबकुछ बाहर"। लेकिन, आप किसी अन्य एडी का उपयोग किसी तृतीय पक्ष प्रमाणीकरणकर्ता के रूप में कर सकते हैं और फिर भी एक स्थानीय उपयोगकर्ता बना सकते हैं जिसके पास आपके पास व्यवस्थापक है। –

उत्तर

2

मुझे एक त्वरित और गंदा समाधान मिला: सक्रिय निर्देशिका में एक और ऐप जोड़ें। यह ऐप एकल किरायेदार होना चाहिए और सक्रिय निर्देशिका को पढ़ने और लिखने की अनुमति है। हम उपयोगकर्ताओं को प्रमाणीकृत करने के लिए ग्राफ़ एपीआई और अन्य ऐप के क्रेडेंशियल्स तक पहुंचने के लिए इस ऐप के क्रेडेंशियल्स का उपयोग कर सकते हैं।

मैं अगर किसी को इस स्थिति के लिए एक बेहतर समाधान है देखने के लिए इंतजार ...

+2

यह वास्तव में एकमात्र तरीका है। आप अन्य एज़ूर एडी का सम्मान कर रहे हैं लेकिन अपने "स्पेस" में एक स्थानीय "उपयोगकर्ता" बना रहे हैं जिसे आप "प्रबंधित" कर सकते हैं। यह वास्तव में एक गंदे समाधान नहीं है। यह सभी तृतीय पक्ष प्रमाणीकरणों का उपयोग करने के लिए स्थापित वर्कफ़्लो है। यदि आप Google Plus OAuth का सम्मान करते हैं, तो आप Google उपयोगकर्ता को मैनेजर करने की अपेक्षा नहीं करते हैं।आप Google पहचान के साथ अपनी स्थानीय पहचान के रूप में स्थानीय इकाई बनाते हैं और स्थानीय उपयोगकर्ता का प्रबंधन करते हैं। –

0

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

आशा है कि मदद करता है,

+0

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

+0

हम सभी प्रमाणीकरण के लिए एज़ूर विज्ञापन का उपयोग करना चाहते हैं। यदि उपयोगकर्ता का अपना AzureAD (कार्यालय 365, ...) है तो वह हमारे आवेदन में खाता बनाने के लिए इसका उपयोग कर सकता है। यदि नहीं, तो वह हमारे AzureAD में एक खाता बना सकता है ... लेकिन मैं अन्य उपयोगकर्ताओं को बनाने के लिए केवल अन्य AzureAD निर्देशिकाओं को स्पर्श करने के लिए सहमति मांगना नहीं चाहता हूं। उम्मीद है कि यह थोड़ा सा परिदृश्य साफ़ करता है ... –

0

प्रमाणीकरण भूमिका के एवज में एक माध्यमिक एप्लिकेशन का उपयोग करने की आवश्यकता नहीं है - गायब प्रणाली/आंतरिक संदर्भ।

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

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

फिर एक इकाई मॉडल में, आप किरायेदार पहचानकर्ताओं (ईएफ के एक हिस्से के रूप में) को संदर्भित करने वाले सभी के लिए एक बहुमुखी इंटरफेस का उत्तराधिकारी हो सकते हैं।

इस तरह बोझ को ओएथ या अन्य पुस्तकालयों के लिए अलग किया जाता है ताकि तीसरे पक्ष के प्रमाणीकरण की देखभाल की जा सके।

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