security - एसएसओ - ससो रजिस्ट्रेशन




सीएएस या ओएथ के साथ एसएसओ? (4)

मुझे आश्चर्य है कि मुझे सिंगल साइन-ऑन के लिए CAS प्रोटोकॉल या OAuth + कुछ प्रमाणीकरण प्रदाता का उपयोग करना चाहिए।

उदाहरण परिदृश्य:

  1. उपयोगकर्ता एक संरक्षित संसाधन तक पहुंचने का प्रयास करता है, लेकिन प्रमाणीकृत नहीं है।
  2. एप्लिकेशन उपयोगकर्ता को एसएसओ सर्वर पर रीडायरेक्ट करता है।
  3. यदि प्रमाणीकृत मधुमक्खी उपयोगकर्ता को एसएसओ सर्वर से टोकन मिलता है।
  4. एसएसओ मूल आवेदन पर रीडायरेक्ट करता है।
  5. मूल एप्लिकेशन एसएसओ सर्वर के खिलाफ टोकन की जांच करता है।
  6. यदि टोकन ठीक है, तो एक्सेस की अनुमति होगी और एप्लिकेशन उपयोगकर्ता आईडी के बारे में जानता है।
  7. उपयोगकर्ता लॉग-आउट करता है और एक ही समय में सभी कनेक्टेड एप्लिकेशन से लॉग आउट होता है (सिंगल साइन-आउट)।

जहां तक ​​मैं समझता हूं कि सीएएस का आविष्कार किया गया था। सीएएस ग्राहकों को प्रमाणीकरण सेवा का उपयोग करने के लिए सीएएस प्रोटोकॉल को लागू करना होगा। अब मैं क्लाइंट (उपभोक्ता) साइट पर सीएएस या ओएथ का उपयोग करने के बारे में सोच रहा हूं। ओएथ सीएएस के उस हिस्से के लिए एक प्रतिस्थापन है? क्या ओएथ को एक नए डी-फैक्टो मानक के रूप में प्राथमिकता दी जानी चाहिए? उपयोगकर्ता नाम / पासवर्ड, ओपनआईडी, टीएलएस प्रमाण पत्र जैसे विभिन्न तरीकों का समर्थन करने वाले सीएएस के प्रमाणीकरण भाग के लिए उपयोग करने में आसान है (सूर्य ओपनएसएसओ नहीं!) ...?

प्रसंग:

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

मैंने अभी रैप की खोज की है , जो ओथ उत्तराधिकारी बन सकता है। यह माइक्रोसॉफ्ट, Google और याहू द्वारा निर्दिष्ट एक नया प्रोटोकॉल है।

परिशिष्ट

मैंने सीखा है कि ओथ को प्रमाणीकरण के लिए डिज़ाइन नहीं किया गया था, यहां तक ​​कि इसका उपयोग एसएसओ को लागू करने के लिए भी किया जा सकता था, लेकिन ओपनआईडी जैसी एसएसओ सेवा के साथ ही।

ओपनआईडी मुझे "नया सीएएस" लगता है। सीएएस में कुछ विशेषताएं ओपनआईडी मिस (जैसे सिंगल साइन-आउट) हैं, लेकिन किसी विशेष परिदृश्य में लापता हिस्सों को जोड़ना मुश्किल नहीं होना चाहिए। मुझे लगता है कि ओपनआईडी की व्यापक स्वीकृति है और ओपनआईडी को एप्लिकेशन या एप्लिकेशन सर्वर में एकीकृत करना बेहतर है। मुझे पता है कि सीएएस ओपनआईडी का भी समर्थन करता है, लेकिन मुझे लगता है कि सीएएस ओपनआईडी के साथ व्यवहार्य है।


ओपनआईडी सीएएस के लिए 'उत्तराधिकारी' या 'विकल्प' नहीं है, वे इरादे और कार्यान्वयन में अलग हैं।

सीएएस प्रमाणीकरण केंद्रीकृत करता है। यदि आप अपने सभी (संभवतः आंतरिक) अनुप्रयोगों को उपयोगकर्ताओं को एक सर्वर पर लॉगिन करने के लिए कहने के लिए चाहते हैं तो इसका उपयोग करें (सभी एप्लिकेशन एक एकल सीएएस सर्वर को इंगित करने के लिए कॉन्फ़िगर किए गए हैं)।

ओपनआईडी प्रमाणीकरण विकेंद्रीकृत करता है। इसका उपयोग करें यदि आप चाहते हैं कि आपका एप्लिकेशन उपयोगकर्ताओं को जो भी प्रमाणीकरण सेवा चाहते हैं उसे लॉगिन करने के लिए स्वीकार करें (उपयोगकर्ता ओपनआईडी सर्वर पता प्रदान करता है - असल में, 'उपयोगकर्ता नाम' सर्वर का यूआरएल है)।

उपरोक्त में से कोई भी प्राधिकरण प्राधिकरण (एक्सटेंशन और / या अनुकूलन के बिना)।

OAuth प्रमाणीकरण संभालती है, लेकिन यह पारंपरिक 'USER_ROLES तालिका' (उपयोगकर्ता पहुंच) के लिए एक विकल्प नहीं है। यह तीसरे पक्ष के लिए प्राधिकरण को संभालता है।

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

तो, ओथ एकल साइन-ऑन के बारे में नहीं है (न ही सीएएस प्रोटोकॉल के लिए एक विकल्प)। यह आपके नियंत्रण में नहीं है कि उपयोगकर्ता किस तक पहुंच सकता है। यह उपयोगकर्ता को यह नियंत्रित करने के बारे में है कि तृतीय-पक्षों द्वारा उनके संसाधनों का उपयोग कैसे किया जा सकता है। दो बहुत अलग उपयोग-मामले।

आपके द्वारा वर्णित संदर्भ में, सीएएस शायद सही विकल्प है।

[अद्यतन]

उस ने कहा, यदि आप एक सुरक्षित संसाधन के रूप में उपयोगकर्ता की पहचान पर विचार करते हैं, तो आप ओएथ के साथ एसएसओ को कार्यान्वित कर सकते हैं। यही है 'गिटहब के साथ साइन अप करें' और पसंद मूल रूप से करते हैं। शायद प्रोटोकॉल का मूल उद्देश्य नहीं है, लेकिन यह किया जा सकता है। यदि आप OAuth सर्वर को नियंत्रित करते हैं, और ऐप्स को केवल इसके साथ प्रमाणित करने के लिए प्रतिबंधित करते हैं, तो यह एसएसओ है।

लॉगआउट को मजबूर करने का कोई मानक तरीका नहीं है, हालांकि (सीएएस में यह सुविधा है)।


पुरानी पोस्ट, लेकिन यह उपयोगी हो सकती है:

सीएएस 3.5 क्लाइंट और सर्वर के रूप में ओथ का समर्थन करेगा। देखें: https://wiki.jasig.org/display/CASUM/OAuth


मैं इस तरह से सोचता हूं:

यदि आप उपयोगकर्ता प्रमाणीकरण प्रणाली को नियंत्रित / स्वामी करते हैं तो सीएएस का उपयोग करें और उन सर्वरों और ऐप्स के हेटरोजेनस सेट का समर्थन करने की आवश्यकता है जिन्हें केंद्रीकृत प्रमाणीकरण की आवश्यकता है।

OAuth का उपयोग करें यदि आप उन सिस्टम से उपयोगकर्ता प्रमाणीकरण का समर्थन करना चाहते हैं जिनके पास आपके पास / समर्थन नहीं है (यानी Google, Facebook, आदि)।


OpenID एक प्रमाणीकरण प्रोटोकॉल है, OAuth और ओथ क्रैप प्राधिकरण प्रोटोकॉल हैं। उन्हें हाइब्रिड ओपनआईडी एक्सटेंशन के साथ जोड़ा जा सकता है।

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

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







cas