I am trying to consume a remote svc web service. I created the proxy class using svcutil.exe
, and after that I've added that class to my console application, but it yields an error:
An unsecured error or incorrectly secured fault was received from the other party. See the inner fault exception for the fault code and detail.
System.ServiceModel.FaultException: An error occurred when verifying security for the message
I didn't create the WCF side, it's a remote svc. Please help.
<?xml version="1.0" encoding="utf-8"?> <configuration> <system.serviceModel> <bindings> <basicHttpBinding> <binding name="EloquaDataTransferService" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Mtom" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true"> <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" /> <security mode="TransportWithMessageCredential"> <transport clientCredentialType="None" proxyCredentialType="None" realm="" /> <message clientCredentialType="UserName" algorithmSuite="Default" /> </security> </binding> </basicHttpBinding> </bindings> <client> <endpoint address="https://secure.eloqua.com/API/1.2/DataTransferService.svc" binding="basicHttpBinding" bindingConfiguration="EloquaDataTransferService" contract="DataTransferService" name="EloquaDataTransferService" /> </client> </system.serviceModel> </configuration>
This is my app.config
file. I am providing the username and password in my consoleApp.cs
file using obj.ServiceCredentials.UserName.UserName="xxxxxx"
and .Password="xxxXx"
<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.serviceModel> <bindings> <basicHttpBinding> <binding name="EloquaDataTransferService" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Mtom" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true"> <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" /> <security mode="TransportWithMessageCredential"> <transport clientCredentialType="None" proxyCredentialType="None" realm="" /> <message clientCredentialType="UserName" algorithmSuite="Default" /> </security> </binding> </basicHttpBinding> </bindings> <client> <endpoint address="https://secure.eloqua.com/API/1.2/DataTransferService.svc" binding="basicHttpBinding" bindingConfiguration="EloquaDataTransferService" contract="DataTransferService" name="EloquaDataTransferService" /> </client> </system.serviceModel> </configuration>
This is a very obscure fault that WCF services throw. The issue is that WCF is unable to verify the security of the message that was passed to the service.
This is almost always because of a server time skew. The remote server and the client's system time must be within (typically) 10 minutes of each other. If they are not, security validation will fail.
I'd call eloqua.com and find out what their server time is, and compare that to your server time.
Although your problem was solved with one of the above solutions, for the benefit of others, here's another option.
You also can get this exception when incorrect credentials are passed to a basic endpoint (SOAP 1.1) that uses username message credentials as you are. For example, if you are calling the service from code and do something like this:
var service = new TestService(); service.ClientCredentials.UserName.UserName = "InvalidUser"; service.ClientCredentials.UserName.Password = "InvalidPass";
This is different from a WSHTTP endpoint (SOAP 1.2) that throws an AccessDeniedException
when invalid credentials are passed through. I personally find the message contained herein a little misleading (it certainly cost me a few minutes the first time I encountered it for this reason) but the underlying cause was clear once I consulted the WCF Diagnostic Trace Logs.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With