2010-01-09 24 views
157

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

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

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

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

प्रसंग:

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

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

परिशिष्ट

मुझे लगता है कि OAuth प्रमाणीकरण भी यह एसएसओ को लागू करने के लिए इस्तेमाल किया जा सकता है के लिए नहीं बनाया गया था, लेकिन केवल एक साथ OpenID की तरह एक SSO सेवा के साथ सीखा है।

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

+6

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

+15

इस बात से सहमत न हों कि एकल साइन-आउट एक एंटीफेचर है। यह सब प्रश्न में अनुप्रयोगों पर निर्भर करता है। वेब अनुप्रयोगों के लिए जो किसी भी तरह से एक दूसरे से संबंधित हैं, यानी Google मेल और Google कैलेंडर, यह समझ में आता है कि यदि आप स्पष्ट रूप से लॉग आउट करते हैं, तो आप दूसरे के लॉगआउट करते हैं। उन ऐप्स के मामले में जहां कोई स्पष्ट "रिश्ते" नहीं है, मैं बॉब से सहमत हूं। – ashwoods

+3

ध्यान दें कि OAuth 2.0 को पेश करने से पहले यह प्रश्न मूल रूप से पूछा गया था, इसलिए OAuth से संबंधित जानकारी अब सही नहीं हो सकती है। – Andrew

उत्तर

206

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

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

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

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

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

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

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

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

[अद्यतन]

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

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

+6

हालांकि ओएथ मुख्य रूप से प्राधिकरण के बारे में है, लेकिन इसका उपयोग केंद्रीय प्रमाणीकरण सर्वर के रूप में किया जा सकता है। प्रमाणीकरण के लिए Google OAuth खाते का उपयोग कई साइटों (एसओ सहित) द्वारा किया जाता है, वास्तव में OAuth प्रदाता से किसी भी सेवा का उपयोग किए बिना। –

+1

इसके अलावा, जैसा कि [बर्टल उत्तर] में कहा गया है (http://stackoverflow.com/a/10226744/535203) सीएएस अब क्लाइंट या सर्वर दोनों के रूप में OAuth प्रदान करता है। –

+0

बहुत बढ़िया जवाब! स्पष्ट करने के लिए आपको धन्यवाद! – emanuelcds

12

OpenID एक प्रमाणीकरण प्रोटोकॉल है, OAuth और OAuth WRAP प्रमाणीकरण प्रोटोकॉल हैं। उन्हें hybrid OpenID extension के साथ जोड़ा जा सकता है।

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

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

उपयोग कैस:

40

मैं इसके बारे में इस तरह से सोचने के लिए करते हैं।

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

+4

ओपनआईडी एक प्रमाणीकरण प्रोटोकॉल है, ओएथ एक प्राधिकरण प्रोटोकॉल है। – zenw0lf

5

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

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

3

मेरे लिए, एसएसओ और OAuth के बीच वास्तविक अंतर अनुदान है प्रमाणीकरण नहीं है क्योंकि एक सर्वर है कि OAuth जाहिर लागू करता प्रमाणीकरण है (यदि आप अपने गूगल, OpenID या के लिए फेसबुक में लॉग इन करना होगा ओएथ क्लाइंट ऐप के साथ होने के लिए)

एसएसओ में, एक पावर उपयोगकर्ता/सिसडमिन "एसएसओ ऐप" पर पहले से किसी एप्लिकेशन को अंतिम उपयोगकर्ता पहुंच प्रदान करता है, ओएथ में, अंतिम उपयोगकर्ता अपने "डेटा" पर एप्लिकेशन तक पहुंच प्रदान करता है "ओथ ऐप"

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

(मेरे 2 सेंट)

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