最近在做為其他單位提供的資料服務的工作,因為不同單位的用戶端都不一樣,所以考慮到了以WebService的方式來提供資料介面。為了提高安全性,我們採用WSE安全認證方案。但受到伺服器客觀環境的限制,所以只能使用.net framework 1.1+wse2.0 sp3來做(建議服務端安裝一些截包工具或學會開啟輸入輸出及反饋的細節資訊,這樣便於調試和找到問題)。這裡為什麼是wse2.0後面會做描述。在用戶端方面,我們類比了C#用戶端和Java用戶端,並針對遇到的一些問題找到了一些解決方案,這裡分享一下。
1.使用wse1.0,java用戶端調用時,提示SOAP頭資訊不正確
如果.net服務端採用了wse1.0,而且採用UsernameToken來驗證時,當Java用戶端也傳遞UsernameToke資訊給服務端時,會提示“SOAP Header 不正確”的錯誤,但是.net 用戶端沒有任何問題,這就是為什麼要使用WSE 2.0以上版本。
2.使用WSE2.0,java用戶端調用時,提示“缺少Nonce和Created”節點
這種問題是因為java傳遞過去的SOAP資訊不完整或無法讓.NET服務端識別。解決的辦法一是要麼讓服務端在傳遞過來SOAP資訊中添加兩個WSE節點,如:
//添加Nonce節點XmlNode node1 = doc.CreateNode(XmlNodeType.Element,"wsse:Nonce","http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd");node1.Prefix = "wsse" ;node1.InnerText = Convert.ToBase64String(System.Text.Encoding.UTF8.GetBytes(System.DateTime.Now.ToString("yyyy-MM-ddTHH:mm:ss.fffZ"))) ;//添加Created節點XmlNode node2 = doc.CreateNode(XmlNodeType.Element,"wsu:Created","http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd");node2.Prefix = "wsu" ;node2.InnerText = DateTime.UtcNow.ToString("yyyy-MM-ddTHH:mm:ss.fffZ");
至於在什麼位置添加這些資訊,通過微軟的協助檔案找到了UsernameTokenManager的LoadTokenFromXml方法,在這裡可以自訂SOAP資訊。
二是讓JAVA用戶端修正傳遞的SOAP資訊
3.其他錯誤
根據“詳細”的“錯誤資訊”和基本原理 去尋找或自我改進。
我在做的過程中,遇到過很多問題,但是解決方案卻很少,大部分都是老外的,而且也沒有answer,總是根據一部分資訊找來找去花了很多時間。總結起來,就是太過馬虎,沒有仔細看錯誤資訊或去思考它的相關原理,而只是一味的依賴於去網上尋找資料,結果都不如意。最後還是耐下心來查看協助和思考它的工作機制時才發現原來可以這樣做。
因為懶惰耽擱了好久才寫,有些東西都忘了,所以寫的簡單,自我檢討。姑且先記錄下來