उपयोगकर्ताओं को बैकएंड सेवाओं को बैकएंड करने के लिए प्रमाणीकृत करने के लिए SAML बेयरर टोकन का उपयोग करना एक बुरा विचार है?

Question

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

आदर्श रूप में सामने के अंत करने के लिए प्रमाणीकृत उपयोगकर्ता है, जो (WS-ट्रस्ट में विनिर्दिष्ट है) एक ActAs टोकन का उपयोग के लिए एक मददगार लगता की ओर से कार्य करना चाहते हैं। हालांकि, यह पता चला है कि ACS does not currently support ActAs।

बैक-एंड सेवा को प्रमाणित करने के लिए वास्तविक बेयरर टोकन (फ्रंट एंड ऐप में बूटस्ट्रैप टोकन) का उपयोग करने के लिए एक कामकाज हो सकता है। It's not hard to do, लेकिन क्या किसी कारण से यह बुरा विचार होगा?

Answer 1

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

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

वैसे भी, एचटीएच!