बाइक के बिना एक साथ क्रॉस-साइट प्रमाणीकरण

एक साथ क्रॉस-साइट प्रमाणीकरण (SSO), इसकी आवश्यकता क्यों है? मान लें कि हमारे पास यह है, आइए इसे ब्लॉग, फ़ोटो, विफल (या फ़ाइलें, जो भी हो) के साथ "पोर्टल" नाम दें, इसे विफल करें। कॉल करें.ru (एम अक्षर के साथ समान नाम की मेल सेवा के साथ भ्रमित नहीं होना चाहिए), और यह सब निम्नलिखित कारकों से जटिल है। :
- कार्यक्षमता पूरी तरह से अलग है;
- कोड अलग-अलग लोगों द्वारा, विभिन्न तकनीकों का उपयोग करके लिखा गया है;
- यह सब अलग-अलग डेटा केंद्रों में और अलग-अलग डेटाबेस के साथ अलग-अलग सर्वरों पर काम करता है;
- सर्वर विभिन्न डोमेन पर स्थित हैं।

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

इस बारे में बहुत कुछ लिखा जा चुका है, और कोड भी। लेकिन हम साइकिल निर्माण के पीटा ट्रैक के साथ नहीं जाएंगे, लेकिन वास्तविक इंजीनियरों के रूप में हम तैयार किए गए विकास लेंगे और उनका उपयोग करेंगे। विधि सरल है, और ऐसी कठिन परिस्थिति के लिए भी उपयुक्त है।

इसके बाद, हम स्व-लिखित विकल्पों पर विचार करेंगे, OpenID, OAuth, SAML और क्यों यह सब आम तौर पर एक अच्छा समाधान नहीं है, प्रमाणीकरण डेटा संग्रहीत करने के मुद्दे, साथ ही कुछ सुरक्षा मुद्दे जो आपको उचित ज्ञान के बिना नहीं जाना चाहिए, क्रॉस-साइट प्रमाणीकरण क्या है, कुछ मिथकों को दूर करें।

कम सार्वभौमिक मामलों के लिए सफल समाधान

वास्तविक जीवन में, चीजों को शुरू नहीं किया जाता है जैसा कि हम विचार कर रहे हैं, और कभी-कभी ऐसा लगता है कि आप एक सामान्य कुकी सेट करने के साथ समाधान प्राप्त कर सकते हैं, लेकिन जैसे ही बाहरी डोमेन प्रकट होता है या सामान्य डेटाबेस संग्रह सत्रों के लिए गायब हो जाता है, समाधान गायब हो जाता है।

आप यहाँ वर्णित विकल्प का उपयोग कर सकते हैं, लेकिन टिप्पणियों में iframe, जावास्क्रिप्ट और अन्य चीजों के बारे में काफी नकारात्मकता है।

OpenID

नेटवर्क पर एक बहुत ही दिलचस्प नोट है जो ओपनआईडी एक समस्या को हल करता है जिसे उसने खुद का आविष्कार किया था। OpenID मेल और उस साइट के बीच एक अनावश्यक परत है जिस पर आप प्रमाणित करना चाहते हैं। उदाहरण के लिए, आपके पास coolopenid.net पर एक खाता है, जो आपके मेल से बंधा हुआ है। जब आप लक्ष्य साइट में प्रवेश करते हैं, तो आपको coolopenid.net पर भेजा जाएगा, वहां वे या तो कुकी देखेंगे, यदि आप पहले से लॉग इन हैं, या ईमेल और पासवर्ड के लिए पूछते हैं, तो आप अपनी पहचान की पुष्टि करेंगे, और फिर लक्ष्य साइट में प्रवेश करेंगे, उदाहरण के लिए, foo1@coolopenid.net। सच है, ईमेल लिंक के माध्यम से पुष्टि करने की तुलना में बहुत आसान नहीं है?

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

OAuth

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

SAML

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

कैस

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

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

फायदे के अलावा, यह ध्यान दिया जा सकता है कि CAS मोटे ग्राहकों के साथ भी काम कर सकता है , और क्लाइंट एजेंट से कुकीज़ सेट करने की क्षमता की भी आवश्यकता नहीं है। कैस के माध्यम से उपयोगकर्ता प्रमाणीकरण के आसान एकीकरण के लिए विभिन्न प्लेटफार्मों के लिए पर्याप्त ग्राहक हैं।

कैस ज्यादा कुछ नहीं करता है। यह उपयोगकर्ताओं के बारे में डेटा संग्रहीत नहीं करता है, यह उनकी भूमिकाओं को संग्रहीत नहीं करता है, और अन्य सदस्यों के बारे में कुछ भी नहीं जानता है। एक उपयोगकर्ता भंडार के रूप में, आप उपयोग कर सकते हैं:
- डेटाबेस
- LDAP / विज्ञापन
- SPNEGO
- त्रिज्या
- तृतीय-पक्ष सेवा
- ... हाँ एक पाठ फ़ाइल भी

दो-कारक प्रमाणीकरण के साथ, और usb टोकन के साथ X.509 प्रमाणपत्र का उपयोग करना संभव है।

कृतिका और मिथक

कैस एक पुरानी परियोजना है, विकसित नहीं है। सर्वर का वर्तमान संस्करण 3.4.8 है, प्रोटोकॉल का नवीनतम संशोधन 2005 है।

ताजा अपडेट इस साल के 9 नवंबर का है ।
जाहिरा तौर पर, प्रोटोकॉल एसएसओ की जरूरतों के लिए आवश्यक कार्यक्षमता को पूरी तरह से लागू करता है, और आगे के विकास की आवश्यकता नहीं होती है, उदाहरण के लिए, जून 1999 से HTTP प्रोटोकॉल को अपडेट नहीं किया गया है।

कैस एक अलोकप्रिय परियोजना है । इस तथ्य के बावजूद कि वह एक वर्ष का नहीं है, उसे कभी मान्यता नहीं मिली - लगभग कोई भी नहीं। तथ्य यह है कि 120 स्कूलों, कॉलेजों और विश्वविद्यालयों का उपयोग और अधिक कोई नहीं बताता है कि कोई और इसका उपयोग नहीं कर सकता है।

यह तथ्य नहीं है कि जो कोई भी एक कार्यान्वयन का उपयोग करता है, उसे यहां दिखाया गया है।

कैस को उसके विशिष्ट कार्य के लिए एक फर्म द्वारा विकसित किया जाता है। जिन प्रोग्रामर्स ने CAS लिखा है, वे अपना शैक्षिक पोर्टल बनाने के लिए प्रतिबद्ध हैं।

मैं मानूंगा कि ये लोग किसी और के सामान्य कार्य के लिए सॉफ्टवेयर बनाने के लिए इस तरह के संरक्षक नहीं हैं। और जब से यह किया गया है, यह सामान्य पहुंच देने के लिए दया नहीं है।

सीएएस एक निजी विकास है जिसमें कहीं भी आवेदन (विश्वविद्यालयों, छात्र नियंत्रण) के एक बहुत ही संकीर्ण क्षेत्र को छोड़कर कहीं भी वास्तविक सफलता की कहानियां नहीं हैं और किसी और के समाधान (uPortal) को छोड़कर कहीं भी नहीं है।

आप चर्चा के तहत विषय में वर्णित अन्य समाधानों के बारे में एक ही बात कह सकते हैं। हालांकि, शायद, मुझे कुछ पता नहीं है।

आश्चर्यजनक रूप से छोटा समुदाय। यदि हम एक सामान्य संपत्ति की एक विशिष्ट त्रुटि के लिए नेट खोजते हैं, तो हम केवल 100 समीक्षाएँ पाएंगे।

सही देख रहे हैं। लगभग 3,210,000 परिणाम (0.21 सेकंड)। यदि आप इसे उद्धरण चिह्नों में रखते हैं, अर्थात, एक सटीक मिलान देखें - 7.5 हजार।

आश्चर्यजनक रूप से छोटी संख्या में कार्यान्वयन। वास्तव में, केवल दो CAS सर्वर कार्यान्वयन हैं। और OpenID प्रदाताओं के कितने HUNDRED कार्यान्वयन लिखे गए हैं?

OpenID एक विकल्प नहीं है, जैसा कि ऊपर वर्णित है। कार्यान्वयन की संख्या का मतलब एकीकरण में आसानी नहीं है।

कार्य सिद्धांत

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

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

यह विधि पर्याप्त संख्या में सुरक्षा छिद्रों को बंद कर देती है।

स्थापना

1. माणिक संस्करण प्रबंधक
बैश << (कर्ल -s raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )
इको '[[-s "$ HOME / .rvm / लिपियों / आरवीएम"]] &&। "$ घर /। आरवीएम / स्क्रिप्ट / आरवीएम" # लोड आरवीएम फ़ंक्शन '>> ~ / .bash_profile

2. रूबी
rvm 1.9.1 स्थापित करें
आरवीएम का उपयोग - १.९ २
मणि स्थापित बंडल

3. रुबाइका-सर्वर
git क्लोन क्लोन git@github.com: रुबाइकस / आर्युबाइकस- server.git
सीडी रूबाइका-सर्वर
बंडल स्थापित करें

4. पतली (वेब ​​सर्वर) स्थापित करें और शुरू करें
मणि पतली स्थापित करें
पतली शुरुआत
यह सबसे आसान है, लेकिन सबसे अच्छा विकल्प नहीं है। यह गेंडा और नगनेक्स के तहत चलने पर विचार करने के लायक है।

ग्राहक का उपयोग करें

रूबी / रैक / सिनात्रा आवेदन के उदाहरण पर:

Gemfile:
...
मणि 'ओए-एंटरप्राइज',: की आवश्यकता है>> 'ओमनियाथ / उद्यम'
...

परिशिष्ट:
...
सेट: login_page, "/ सामान्य / कैस"

OmniAuth का उपयोग करें :: रणनीतियाँ :: CAS :: cas_server => 'https://ruby-cas.mydydain.com "

पाने के लिए '/ सामान्य / कैस / कॉलबैक' करते हैं
विशेषाधिकार = request.env ["omniauth.auth"]
account = Account.first (: ईमेल => सामान्य ["uid"]) || Account.first (: ईमेल => सामान्य ["uid"],: भूमिका =>: बाहरी)
set_current_account (खाता)
पुनर्निर्देशित '/'
अंत
...