2012-12-20 16 views
11

तो हाल ही में हम एक जावा ग्राहक के लिए एक सेवा अवगत कराया। हमारी सेवा उपयोगकर्ता नाम/पासवर्ड सत्यापन के साथ परिवहन सुरक्षा का उपयोग करती है।WCF जावा ग्राहकों और IncludeTimestamp

हमारी सेवा कॉल करने के लिए ग्राहक सुरक्षा हेडर के बारे में एक अपवाद प्राप्त था प्रयास कर सकते हैं। आगे के शोध से संकेत मिलता है कि डब्ल्यूसीएफ क्लाइंट से पास किए गए एसओएपी हेडर में टाइमस्टैंप को शामिल करने की अपेक्षा करता है। यदि यह मौजूद नहीं है (या भिन्नता 5 मिनट से अधिक है) तो यह अपवाद फेंक देगा।

हम यह भी पाया गया कि जावा ग्राहकों टाइमस्टैम्प WCF की उम्मीद है उत्तीर्ण नहीं होते हैं। केवल वैकल्पिक हल हमने पाया CustomBinding को लागू करने और गलत पर IncludeTimestamp स्थापित करने के लिए किया गया था। इसने क्लाइंट को सेवा को सफलतापूर्वक कॉल करने की अनुमति दी।

आज जबकि WCF मैं MSDN पर निम्न देखें के साथ सुरक्षा के लिए सर्वोत्तम प्रथाओं को देख:

सेट सच करने के लिए कस्टम बाइंडिंग पर SecurityBindingElement.IncludeTimestamp

जब आप कोई कस्टम बंधन बनाते हैं, आप सत्य पर IncludeTimestamp सेट करना होगा। अन्यथा, यदि IncludeTimestamp को गलत पर सेट किया गया है, और क्लाइंट एक असममित कुंजी-आधारित टोकन का उपयोग कर रहा है जैसे X509 प्रमाणपत्र, संदेश पर हस्ताक्षर नहीं किए जाएंगे।

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

+0

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

उत्तर

1

सर्वोत्तम अभ्यास केवल लागू होने पर मान्य है। यदि आपके पास क्लाइंट पर कोई नियंत्रण नहीं है, और वे टाइमस्टैंप नहीं भेज सकते हैं, तो हर तरह से गलत करने के लिए includetimestamp सेट करें।