1
已經在爲最後在調用從C＃WCF客戶端（以.Net 4.5框架爲目標）的服務調用到使用端對端加密（使用客戶端和服務證書）的外部託管的Java Soap服務時，出現此錯誤Authentication of type {http://service.soap.xcompany.com}AuthenticationHeader had undefined attribute {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Id的幾天。當我使用帶有JKS文件的SoapUI測試服務時，請求已成功處理。Header上的類型認證具有未定義的屬性{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Id
所以，看看有什麼兩個請求之間的區別，我做了以下內容：
- 使用提琴手檢查器捕獲兩個要求，一個從了SoapUI這是成功的，一個從C＃失敗並500錯誤
- 使用VS2017功能Edit/Paste Special/Paste Xml as Classes將這兩個Xml消息提取到兩個C＃類（分別命名爲RequestByJava和RequestByDotNet）。
- 使用XmlSerializer將兩個請求反序列化爲2）中創建的兩個類型的對象，並比較它們的屬性。
- 考慮到Soap錯誤消息，我縮小了兩個Authentication標頭之間的區別 - 有趣的是，RequestByDotNet對象中有一個額外的屬性「Id」，而RequestByJava對象沒有。並且500 Soap錯誤消息似乎表明由於未定義的元素「Id」而存在架構驗證錯誤
- 也注意到RequestByDotNet。 Header.Security.BinarySecurityToken.ValueType =「http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0# X509v3」但RequestByJava（了SoapUI）具有不同的值類型「http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1」
- 另一個不同之處，不知道它的問題，是從.NET代碼的要求有Header.Security下「的mustUnderstand」值設置爲true，而一個從Java不是。
我的問題是：
- 爲什麼不一樣？
- 如何解決這個問題而無需編寫Java客戶端？
一些代碼使用的綁定和端點的行爲：
private static CustomBinding BuildCustomBinding()
{
var binding = new CustomBinding();
var textMessageEncoding = new TextMessageEncodingBindingElement()
{
MessageVersion = MessageVersion.Soap11
};
var securityBindingElement =
SecurityBindingElement.CreateMutualCertificateBindingElement(
MessageSecurityVersion.WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10, true);
binding.Elements.AddRange(textMessageEncoding, securityBindingElement, new HttpsTransportBindingElement());
return binding;
}
private static void CallAccountService()
{
//credential for test
const string applId = "testuser";
const string pwd = "password";
//for client certificate, import client.pfx to LocalMachine's Trusted Root Certification Authorities and make sure the thumbprint matches
var client = new NOLWSAccountSvc.WSAccountv1Client(BuildCustomBinding(), GetAccountServiceEndpointAddress());
client.ClientCredentials.ClientCertificate.SetCertificate(StoreLocation.LocalMachine,
StoreName.Root, X509FindType.FindByThumbprint, "thumbprintvalue");
//for service certificate, import service-provider.cer to same store location and store name and make sure the thumbprint matches
client.ClientCredentials.ServiceCertificate.SetDefaultCertificate(StoreLocation.LocalMachine, StoreName.Root,
X509FindType.FindByThumbprint, "thumprintvalue");
client.ClientCredentials.ServiceCertificate.Authentication.CertificateValidationMode =
X509CertificateValidationMode.PeerOrChainTrust;
client.Open();
var header = new NOLWSAccountSvc.AuthenticationHeader()
{
application_id = applId,
password = pwd
};
var getActiveAccountsFunc = new NOLWSAccountSvc.getActiveAccounts() { applRef = "softact-dev", resetRows = true };
try
{
var response = client.getActiveAccounts(header, getActiveAccountsFunc);
Console.WriteLine(response.moreData);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
finally
{
client.Close();
}
}
感謝您的時間！您的幫助將受到高度讚賞。
您是否比較了工作請求和非工作請求的主體。看起來這兩個請求都是使用509加密加密的。請參閱wiki：https：//en.wikipedia.org/wiki/X.509 – jdweng
看起來證書的命名約定是不同的，但是是等同的：X.509 v3證書標準的配置文件，如RFC 5280中所述，通常稱爲公鑰基礎設施PKIX（X.509）。實際證書一定有問題。你必須看看證書本身。 – jdweng