यहां दो दृष्टिकोण हैं जो मैं देखता हूं। ओपनआईडी कनेक्ट पॉइंट ऑफ व्यू से एक। और दूसरा उपयोगकर्ता निर्देशिका हैंडलिंग से।
आईडी टोकन
OpenID Connect ने विनिर्देश एक आईडी टोकन के दावों (link आईडी टोकन परिभाषा और दावा स्पष्टीकरण के लिए) को परिभाषित करता है दावा करता है। और यह हमें अपने दावों का दावा करने की आजादी देता है। उदाहरण के लिए, यदि RPsub पर निर्भर नहीं हो सकता है तो अंतिम उपयोगकर्ता को पहचानने और मानचित्र करने का दावा, कोई standard claims के अलावा एक कस्टम दावा पेश कर सकता है।
आईडी टोकन में अन्य दावे शामिल हैं। इस्तेमाल किया किसी भी दावे कि नहीं समझा गया है
पर ध्यान नहीं दिया जाना चाहिए उदाहरण के लिए, आप आईडी टोकन में एक का दावा rp_identifier जो आप आरपी प्रयोक्ता आईडी देता है परिभाषित कर सकते हैं।
इसके लिए आपके आईडीपी में कुछ कॉन्फ़िगरेशन की आवश्यकता होगी और आईडीपी स्टोरेज में आवश्यक पहचानकर्ता भी संग्रहीत करना होगा।
निर्देशिका सिंक्रनाइज़ेशन
सुनिश्चित नहीं हैं कि आपके उपयोगकर्ता निर्देशिका स्थापित कर रहे हैं। लेकिन यदि आप बाहरी आईडीपी का उपयोग कर रहे हैं, तो आप अपनी आंतरिक और बाहरी उपयोगकर्ता निर्देशिका को सिंक्रनाइज़ करना चाहेंगे। मैं इस डोमेन में एक विशेषज्ञ नहीं हूं, लेकिन आपके संदर्भ this आलेख के लिए Azure सक्रिय निर्देशिका सिंक्रनाइज़ेशन के बारे में बताता है।
हालांकि उपयोगकर्ता सिंक्रनाइज़ेशन ओपनआईडी कनेक्ट के दायरे से बाहर है, फिर भी जो कुछ बिंदु पर ओपनआईडी कनेक्ट पर जा रहे हैं, उन्हें आईडीपी प्रदान करने वाले उपयोगकर्ताओं को आंतरिक उपयोगकर्ताओं को मैप करना होगा।
स्रोत
2017-11-18 10:16:28
क्या आप अंतिम उपयोगकर्ता को प्रमाणीकृत करने के लिए आईडी टोकन का उपयोग कर रहे हैं? अगर ऐसा है, तो आपके पास अभी समस्या है जो आंतरिक उपयोगकर्ता के साथ आईडी टोकन के उप पैरामीटर का मेल नहीं है? –
क्या आपने निर्देशिका सिंक्रनाइज़ेशन के बारे में भी सोचा है? –
मुझे नहीं पता कि निर्देशिका (आईडीपी से आरपी) को सिंक्रनाइज़ करने के लिए, यह समस्या है ... – Dunken