जेएक्स-डब्ल्यूएस, प्रमाणीकरण और प्रमाणीकरण - कैसे करें?

Question

वेब सेवाओं में प्रमाणीकरण और प्रमाणीकरण करने का सबसे अच्छा तरीका क्या है?

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

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

अब तक:

• पढ़ें authentication using a database - लेकिन मैं अनुप्रयोग स्तर मान्यता चाहते हैं;
  

• application authentication with jax-ws पढ़ें - लेकिन मैं हर बार प्रमाणीकरण तंत्र नहीं करना चाहता;

• मुझे लगता है कि मैं सभी संदेशों को रोकने के लिए एक एसओएपी हैंडलर का उपयोग कर सकता हूं, और कुछ सत्र पहचानकर्ता टोकन का उपयोग करके हैंडर में प्राधिकरण नियंत्रण कर सकता हूं, जो संदेश के साथ आता है, जिसे सहेजे गए पहचानकर्ता के विरुद्ध मिलान किया जा सकता है लॉगिन वेब विधि में डेटा बेस।

संपादित करें:

मैं अभी भी कुछ सवाल हैं:

• कैसे वेब विधि का नाम पता करने के लिए बुलाया जा रहा है?
• मुझे किस प्रकार का टोकन उपयोग करना चाहिए?
• कॉल के बीच इस टोकन को कैसे पास करें?

संपादित 2

क्योंकि @ के

जवाब ag112:

मैं Glassfish उपयोग कर रहा हूँ।

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

मैं केवल सेवाओं का विकास कर रहा हूं, और मुझे ग्राहकों को लगभग कुछ भी नहीं पता है, बस उन्हें विभिन्न भाषाओं में बनाया जा सकता है।

इस बिंदु पर मुझे लगता है कि सबसे महत्वपूर्ण बात यह है कि मुझे उपयोगकर्ताओं को प्रमाणित करने और प्रमाणीकरण करने के लिए क्या करना है, मैं क्लाइंट अनुप्रयोगों के लिए लागू करने का सबसे आसान तरीका है।

Answer 1

सभी मदद के बाद, मैं इस उत्तर को सरल बनाने के लिए तैयार करता हूं, और चर्चा किए गए सभी विचारों को सारांशित करता हूं।

सवाल

2 आवश्यक वस्तुएँ हैं:

• संदेश स्तर की सुरक्षा;
• एक बार प्रमाणीकरण।

ag112 सहायता के साथ, यह करना मुश्किल है, या किसी भी तरह से सुरुचिपूर्ण है।तो यहाँ निष्कर्ष हैं:

• संदेश स्तर की सुरक्षा के लिए उपयोगकर्ता साख हर बार (सोप शीर्ष लेख में यह जगह) भेजते हैं,
• एक बार प्रमाणीकरण परिवहन स्तर की सुरक्षा का उपयोग करें, और सत्र प्रबंधन करें।

मैं पहली बार पसंद करता हूं, क्योंकि संदेश स्तर सबसे बड़ी आवश्यकता थी।

Answer 2

के रूप में कोई उत्तर नहीं था, अब तक @unhillbilly निम्नलिखित सलाह देने के लिए, मैं अपने ही सवाल का जवाब, प्रगति के साथ:

कैसे वेब विधि बुलाया जा रहा है का नाम पता करने के लिए;

एसओएपी हैंडलर का उपयोग करके, शरीर में पहले तत्व का नाम ढूंढना।

मुझे किस प्रकार का टोकन उपयोग करना चाहिए;

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

कॉल के बीच इस टोकन को कैसे पास करें।

लॉगिन वेब विधि के लिए परिणाम प्रत्येक टोकन में टोकन होता है, टोकन एक पैरामीटर है।

क्या कोई बेहतर उत्तर है?

Answer 3

आप OpenEJB के लिए भी जा सकते हैं।

यह डब्ल्यूएस-सुरक्षा के साथ जेएएएस का इस्तेमाल करता था।

मुझे आशा है कि लिंक उपयोगी होगा।

Answer 4

@Luis: यहां मेरे इनपुट हैं।

आपकी समस्या के लिए सटीक समाधान आपके द्वारा अपेक्षित वेब सेवा क्लाइंट्स पर निर्भर करता है, क्या आपके पास वेब सेवा क्लाइंट सिस्टम, आपके ऐप सर्वर आदि पर नियंत्रण है ..... लेकिन मानते हैं कि आपके पास वेब पर कोई नियंत्रण नहीं है सेवा क्लाइंट, आपके लिए यह केवल HTTP परिवहन पर एक SOAP संदेश है, यहां संभावित समाधान है।

आप संदेश स्तर या परिवहन स्तर पर सत्र प्रबंधन & प्रमाणीकरण कर सकते हैं। इसका मतलब है कि या तो आप एसओएपी संदेश में सत्र टोकन और ऑथ टोकन जानकारी प्राप्त कर सकते हैं या आप मानक HTTP सत्र और HTTP प्रमाणीकरण तंत्र का उपयोग कर सकते हैं।

बेशक परिवहन स्तर समाधान बहुत आसान है और यदि परिवहन परत HTTP है तो उद्योग व्यापक मानक है। संदेश स्तर के लिए, ws-security जैसे ws विनिर्देशों का उपयोग किया जा सकता है। आपका प्रत्येक वेब सेवा अनुरोध एक साधारण HTTP यूआरआई द्वारा पहचाना गया सरल HTTP GET/POST है। आमतौर पर जैक्स-डब्ल्यू मेट्रो पर्यावरण में, WSServlet वह है जो किसी भी वेब सेवा कॉल के लिए एंट्री सर्वलेट है और अंततः सही सेवा प्रदाता कार्यान्वयन कक्षा में कॉल का प्रतिनिधित्व करता है। चूंकि आप वेब सर्वर में आवेदन तैनात किए जा रहे हैं, इसलिए आप जे 2 ई वेब कंटेनर द्वारा प्रदान किए गए सभी सत्र और प्रमाणीकरण सुविधाओं का फायदा उठा सकते हैं।

चूंकि आप भूमिका-आधारित पहुंच नियंत्रण की तलाश में हैं, इसलिए मैं वेब.एक्सएमएल में मानक <web-resource-collection> का उपयोग करता हूं ताकि यह निर्दिष्ट किया जा सके कि आप विशेष HTTP यूआरआई के मामले में कौन सी भूमिका लेना चाहते हैं। आप मानक जेएएएस लॉगिन मॉड्यूल का उपयोग कर सकते हैं जो प्रमाणीकरण कर सकता है और भूमिका के साथ जेएएएस विषय को पॉप्युलेट कर सकता है। यदि SOAP XML में उपयोगकर्ता नाम/पासवर्ड प्रदान किया जाता है, तो JAAS लॉगिन मॉड्यूल उन जानकारी को पुनर्प्राप्त करने के लिए SOAP XML को खोज/पार्स भी कर सकता है। जेएएएस/ऐप सर्वर स्वचालित रूप से ऑथ टोकन बना देगा और इसे कुकी के रूप में स्टोर करेगा ताकि प्रत्येक बाद के अनुरोध को फिर से प्रमाणीकरण प्रक्रिया से गुज़रने की आवश्यकता न हो। यह सभी जे 2ee मानक है। आप इस पर इंटरनेट पर बहुत मदद पा सकते हैं।कृपया मुझे अपना ऐप सर्वर बताएं ताकि मैं आपको अतिरिक्त विवरण प्रदान कर सकूं।

यदि आप अभी भी एसओएपी संदेश स्तर सत्र प्रबंधन, प्रमाणीकरण & प्रमाणीकरण प्रक्रिया का उपयोग करना चाहते हैं, तो आपको अधिक जानकारी प्रदान करने के लिए, क्या मैं आपके ग्राहक पक्ष के बारे में अधिक जानकारी प्राप्त कर सकता हूं।

EDIT1: खैर अपने आगे इनपुट के आधार पर, यहाँ मेरी अधिक विचार है: संदेश सुरक्षा अर्थात् एन्क्रिप्शन और हस्ताक्षर प्रत्येक संदेश सर्वर और ग्राहक के बीच यात्रा होने की जरूरत है। जहां संदेश प्रमाणीकरण के रूप में- आप एक बार ऐसा करने का इरादा रखते हैं और बाद में कॉल के लिए क्लाइंट को सत्र टोकन/ऑथ टोकन देते हैं।

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

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

पीएस: ग्लासफ़िश सर्वर संदेश प्रमाणीकरण प्रदाता को कॉन्फ़िगर करने का एक तरीका प्रदान करता है जो स्वचालित रूप से संदेश स्तर प्रमाणीकरण को सक्षम/अक्षम करता है।

EDIT2: मैं समझता हूँ कि आप में ग्राहक ऐप्लिकेशन और वेब सेवा सर्वर उन उपयोगकर्ता प्रमाणिकता की जरूरत उपयोगकर्ता क्रेडेंशियल स्टोर करने के लिए नहीं करना चाहती। ओएथ खुला मानक प्रोटोकॉल है जो साइट ए को साइट पर उपयोगकर्ता के निजी डेटा तक पहुंचने की अनुमति देता है। अंतिम विचार यह है कि साइट ए को ऑथ टोकन मिल जाता है जिसमें विशिष्ट समाप्ति समय होता है। इसलिए उपयोगकर्ता क्रेडेंशियल्स या जेएसशन आईडी से एन्क्रिप्टेड युक्त टोकन आपको पुनः प्रमाणीकरण की आवश्यकता से बचने में मदद करता है। आपको केवल यह तय करने की आवश्यकता है कि आप क्लाइंट ऐप साइड पर टोकन रखना चाहते हैं, यदि परिवहन HTTP प्रोटोकॉल है तो आप कुकी के रूप में टोकन रख सकते हैं।

यह कहकर कि हर बार उपयोगकर्ता प्रमाण-पत्र पास करने के लिए थोड़ा आसान और सीधे आगे लगता है।