CAS या OAuth के साथ SSO?

Question

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

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

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

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

प्रसंग:

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

मैंने अभी WRAP की खोज की है , जो OAuth उत्तराधिकारी बन सकता है। यह Microsoft, Google और Yahoo द्वारा निर्दिष्ट एक नया प्रोटोकॉल है।

परिशिष्ट

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

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

Comments

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

— बॉब अमन

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

— ashwoods

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

— एंड्रयू

Answer 1

OpenID CAS के लिए 'उत्तराधिकारी' या 'विकल्प' नहीं है, वे अलग-अलग हैं, इरादे और कार्यान्वयन में हैं।

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

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

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

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

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

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

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

[अद्यतन]

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

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

Comments

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

— अमीर अली अकबरी

इसके अलावा, जैसा कि बर्टल उत्तर कैस में कहा गया है अब ग्राहक या सर्वर दोनों के रूप में OAuth प्रदान करता है।

— एंथनी ओ।

क्या यह उत्तर अभी भी प्रासंगिक है कि OAuth 2.0 मौजूद है? OAuth 2.0 के साथ आपकी राय कैसे बदल गई है?

— एंड्रयू

OAuth 2.0 अभी भी एक प्राधिकरण प्रोटोकॉल है और प्रमाणीकरण प्रोटोकॉल नहीं है, लेकिन प्रमाणीकरण प्रोटोकॉल बनाने के लिए OAuth 2.0 के शीर्ष पर कोई भी निर्माण कर सकता है, जो कि फेसबुक / लिंक्डइन आदि ने किया है; OAuth 2.0 का एकमात्र मानकीकृत विस्तार जो प्रमाणीकरण प्रदान करता है, OpenID कनेक्ट है, जो OpenID के नामित उत्तराधिकारी है

— हंस जेड।

Answer 2

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

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

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

Comments

OpenID एक प्रमाणीकरण प्रोटोकॉल है, OAuth एक प्राधिकरण प्रोटोकॉल है।

— zenw0lf 20

Answer 3

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

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

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

Answer 4

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

SSO में, एक पॉवर यूजर / sysadmin "SSO ऐप" पर पहले से किसी एप्लिकेशन के लिए अंतिम यूजर एक्सेस प्राप्त करता है। OAuth में, अंतिम उपयोगकर्ता "OAuth ऐप" पर अपने "डेटा" के लिए एप्लिकेशन एक्सेस प्राप्त करता है।

मैं यह नहीं देखता कि OAuth प्रोटोकॉल का उपयोग SSO सर्वर के हिस्से के रूप में क्यों नहीं किया जा सकता है। बस अनुदान स्क्रीन को प्रवाह से बाहर निकालें और OAuth सर्वर को बैकिंग db से अनुदान को देखने दें।

Answer 5

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

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

Comments

यह देखने वाले और शायद भ्रमित होने वाले लोगों के लिए, CASयहाँ उल्लेख CAS प्रोटोकॉल के बजाय CAS सर्वर है ।

— एनजी सीके लॉन्ग