सत्र आईडी या उपयोगकर्ता नाम + पासवर्ड

Question

के साथ शिरो प्रमाणीकरण मुझे जावा प्रमाणीकरण ढांचे और प्रमाणीकरण वर्कफ़्लो में सामान्य रूप से (केवल कुछ सैद्धांतिक ज्ञान) में अधिक अनुभव नहीं है, इसलिए शैक्षिक उद्देश्यों के लिए मैं अपने HTTP के लिए इस प्रकार का प्रमाणीकरण बनाने की कोशिश कर रहा हूं आवेदन:

1. ग्राहक पोस्ट लॉगिन + /login पर पासवर्ड।
2. शिरो उपयोगकर्ता को दिए गए प्रमाण-पत्र द्वारा लॉग इन करता है। सर्वर क्लाइंट को sessionId देता है।
3. ग्राहक किसी प्रकार का संसाधन /myresource?sessionId=1234567 अनुरोध करता है।
4. शिरो sessionId दिए गए विषय में लॉग इन करता है। फिर सर्वर /myresource (शिरो प्रबंधन विधि-स्तर पहुंच अधिकारों के साथ) प्राप्त करने के नियमित वर्कफ़्लो करता है।
   1. मैं मैं HTTP सत्रों है और न ही सर्वलेट सत्र की कोई आवश्यकता नहीं लगता है:

   मूल रूप से मैं इन प्रश्न हैं। शिरो का अपना सत्र प्रबंधक है जो मेरी ज़रूरतों के लिए पर्याप्त है। क्या मै गलत हु?

5. क्या क्लाइंट को वास्तविक सत्र देने के लिए यह अच्छा अभ्यास है या क्या मुझे किसी प्रकार का सत्र टोकन भेजना चाहिए (जो सर्वर पक्ष पर सत्र ID को हल किया गया है)?
6. सत्र आईडी (जिसे क्लाइंट को स्थानीय रूप से स्टोर करना चाहिए) का उपयोग करके मैं विषय कैसे लॉगिन करूं?
7. क्या इस तरह के प्रमाणीकरण करने से पहले मुझे कोई और चीज जानने की ज़रूरत है?

अग्रिम धन्यवाद।

Answer 1

मुझे लगता है कि मुझे HTTP सत्र और सर्वलेट सत्रों की आवश्यकता नहीं है। शिरो का अपना सत्र प्रबंधक है जो मेरी ज़रूरतों के लिए पर्याप्त है। क्या मै गलत हु?

नहीं, आप सही हैं। यही कारण है कि शिरो अद्भुत है। documentation से:

Shiro के सत्र समर्थन का उपयोग करें और इन दोनों [वेब कंटेनर या EJB स्टेटफुल सत्र बीन्स] तंत्र की किसी भी प्रबंधन करने के लिए बहुत सरल है, और यह कंटेनर की परवाह किए बिना, किसी भी आवेदन में उपलब्ध है।

उदा।

Subject currentUser = SecurityUtils.getSubject();  
Session session = currentUser.getSession(); 
session.setAttribute("someKey", someValue); 

the doc से उद्धृत: getSession calls work in any application, even non-web applications

ग्राहक वास्तविक sessionId देने के लिए या मैं (जो सर्वर साइड पर sessionId को हल हो गई है) sessionToken किसी तरह भेजना चाहिए यह अच्छा अभ्यास है?

सादा सत्र भेजने के लिए यह एक बुरा विचार है। विशेष रूप से, यदि आप अनएन्क्रिप्टेड नेटवर्क पर डेटा भेज रहे हैं। या तो HTTPS जैसे कुछ का उपयोग करें या कुछ पंक्ति NONCE का उपयोग करें।

और, एक साइड नोट, यदि URL में होने के बजाय http/s POST डेटा पर है।

सत्र आईडी (जिसे क्लाइंट को स्थानीय रूप से स्टोर करना चाहिए) का उपयोग करके मैं विषय कैसे लॉगिन करूं?

आपका मतलब है कि सत्र आईडी होने के बाद आप इस विषय को कैसे प्रमाणित कर सकते हैं? आप बस कर सकते हैं दस्तावेज़ से, ,

Subject requestSubject = new Subject.Builder().sessionId(sessionId).buildSubject(); 

वहाँ किसी भी अन्य बातों मैं प्रमाणीकरण इस तरह करने से पहले पता करने की जरूरत है?

हां।

1. पढ़ें Shiro's Session Management
2. झुक के बारे में MITM Attack
3. बारे HTTPS और SSL
हैश कार्यों पर
4. कुछ this, Apache Commons DigestUtils और हो सकता है this

---

अपडेट

उस विषय प्रमाणीकरण भाग के बारे में - क्या यह नव निर्मित विषय वर्तमान में प्रमाणीकृत विषय बना देगा? यदि नहीं, तो मैं इसे "वर्तमान" विषय कैसे बना सकता हूं?

यदि आप new Subject.Builder().sessionId(sessionId).buildSubject() के बारे में बात कर रहे हैं, तो यह नहीं होगा। और मुझे नहीं पता कि इसे थ्रेड के लिए वर्तमान उपयोगकर्ता के रूप में कैसे सेट करें। Shiro के JavaDoc कहते हैं,

[इस तरह] लौटे विषय उदाहरण स्वचालित रूप से आगे उपयोग के लिए आवेदन (धागा) करने के लिए बाध्य नहीं है। यही है, SecurityUtils.getSubject() स्वचालित रूप से उसी उदाहरण को वापस नहीं करेगा जैसा कि निर्माता द्वारा लौटाया गया है। वांछित अगर निरंतर उपयोग के लिए निर्मित विषय को बांधने के लिए यह फ्रेमवर्क डेवलपर पर निर्भर है।

तो, यह आपके ऊपर है कि आप वर्तमान धागे या आगे के उपयोग में इस विषय को कैसे बाध्य करते हैं।

यदि आप चिंतित थे कि कैसे SecurityUtils.getSubject(); चीज काम करता है, ठीक है, वेब-कंटेनर संदर्भ में, यह आपके सत्र-डेटा को स्टोर करने के लिए सरल कुकी का उपयोग करता है। जब आपका अनुरोध शिरो फ़िल्टर के माध्यम से आता है, तो यह वर्तमान विषय को इसके जीवन चक्र (वर्तमान धागे) के अनुरोध के लिए संलग्न करता है। और जब आप getSubject() के रूप में अनुरोध से यह Subject प्राप्त करता है। मुझे एक दिलचस्प धागा here मिला।

गैर-भाग के बारे में: यदि वह मुझे अपने सत्र के बजाय किसी प्रकार का हैश भेजता है ID - मैं वास्तविक सत्र प्राप्त करने के लिए इसे डीकोड करने में सक्षम नहीं हूं (उसे उसके साथ अधिकृत करने के लिए)। क्या मुझसे कोई चूक हो रही है?

गैर-भाग - यह गर्दन में दर्द है। अब पुनर्विचार, मुझे लगता है कि नॉनसे करना सिर्फ ओवरकिल है। मुझे कुछ बताएं, वैसे भी,

1. उपयोगकर्ता अपने उपयोगकर्ता नाम और पासवर्ड के साथ पहली बार लॉग इन करता है।userid, nonce (कहें, यूयूआईडी), और HASH(sessionID+nonce) सेट करें, इसे क्लाइंट साइड पर हैश 1 पर कॉल करें। कुकी में कहो। सर्वर साइड पर इस nonce स्टोर, के रूप में user_id <--> nonce,session_id

2. बाद अनुरोध पर डीबी में या एक मानचित्र में हो सकता है, सुनिश्चित करें कि आप पासबैक userid, nonce और HASH बनाते हैं।

3. सर्वर की तरफ, सबसे पहले आप जो अनुरोध करेंगे वह अनुरोध को मान्य करता है। sessionId और nonce हैशैप या डीबी में संग्रहीत user_id पर आधारित क्लाइंट द्वारा भेजा गया था। एक हैश, हैश (sessionId_from_db + nonce_from_db) बनाएं, इसे हैश 2 कॉल करें।

4. अब, यदि हैश 1 मैचों हैश 2 है, तो आप अनुरोध को मान्य कर सकते हैं और चूंकि आपने मौजूदा सत्र को सर्वर पक्ष पर संग्रहीत किया है, तो आप इसका उपयोग कर सकते हैं। अनुरोध पूर्ण होने पर, कुकी और सर्वर पक्ष पर नया नॉन सेट करें।

यदि आप 1 - 4 के माध्यम से जाते हैं, तो आपको पता चलेगा कि आपको प्रमाणीकरण के लिए शिरो की आवश्यकता नहीं होगी। (: तो, मैं अपने शब्द वापस ले रहा हूँ, n एक इस मामले में लागू नहीं किया जाता जब तक आप प्रदर्शन से अधिक सुरक्षा के बारे में भी फ्रीकी हैं

क्यों मेरे लिए MITM हमले बात करना मेरे क्लाइंट (जावास्क्रिप्ट ajax कोड) को हासिल करेगा।? यह से डेटा ajax के माध्यम से सर्वर है। इसलिए मुझे नहीं लगता कि मैं किसी भी तरह से MITM के बारे में ध्यान देना चाहिए है।

मुझे लगता है कि यह आपके लिए महत्वपूर्ण चाहिए। MITM हमला मतलब है कि आपका अनुरोध/प्रतिक्रियाओं एक मशीन के माध्यम से श्रृंखलित किया जा रहा है (MITM) आपके राउटर के लिए। यदि यह एक अनएन्क्रिप्टेड अनुरोध है, तो यह एमआईटीएम के लिए सभी सादा पाठ है। वह आपके सभी अनुरोध देख सकता है ... और संभवतः अनुरोधों को खराब कर सकता है और सत्र को हाइजैक कर सकता है। मुझे कुछ उदाहरण मिलें .... http://michael-coates.blogspot.com/2010/03/man-in-middle-attack-explained.html