WCF Timing out from Windows Services but not Web Applications - asp.net

Hi All
I am currently having an issue calling a WCF service from a windows service. My Application Solution looks like this.
Web Administration Console (Web Project)
Central Control (Windows Service)
WCF service so the Web Administration Console can connect to it and configure it
Several Calls to use WCF on the Node (Window Service)
Node (Windows Service)
WCF service to allow the Central Control Windows service configure it
The Web Administration Console can access the Central Control WCF but the Central Control Times Out when ever it tries to connect to the Node. In testing this I created a Launcher app which is a simple Windows Form Project which creates an instance of each service and has a couple of buttons which use a WCF function in each of the windows services (just to see what was failing) this Launcher app couldn’t speak to either of the Windows Services. This was confused me so I added the same buttons to a Web Form in the Web Administration Console and it connected to both Windows Services perfectly through WCF. I know the WCF stuff is working as I can hit it through IE and see all of the wonderful XML (and obviously the fact that the calls work from the web app are a good indication of it being up and running)
In short
My web apps can use the WCF services in my Windows Services but Windows Forms and Windows services cannot. Why is this!?
I have pretty much already run out of time on this project so speedy replies would be awesome!
Tech/Code details
I am not using config files in the applications. Everything is being created through code and I have been using the same code to make my WCF calls every where. Also I have tried to turn security off everywhere in case that was the issue. Also I am using the same svcutil generated proxy files everywhere as well to keep it all consistent
Example of a call to the Node
Dim Bind As New WSHttpBinding(SecurityMode.None, True)
Bind.CloseTimeout = New TimeSpan(0, 0, 10)
Bind.OpenTimeout = New TimeSpan(0, 0, 10)
Bind.SendTimeout = New TimeSpan(0, 0, 10)
Dim client As New BN.BNodeServiceClient(Bind, New EndpointAddress("http://localhost:27374/Node"))
client.sendMessage("Test Message")
client.Close()
The Node opening its WCF
BNodeHost = New ServiceHost(GetType(iBNodeService))
BNodeHost.AddServiceEndpoint(GetType(BNodeService), New WSHttpBinding(SecurityMode.None, True), New Uri("http://localhost:27374/Node"))
Dim metadataBehavior As ServiceModel.Description.ServiceMetadataBehavior
metadataBehavior = BNodeHost.Description.Behaviors.Find(Of _
ServiceModel.Description.ServiceMetadataBehavior)()
If metadataBehavior Is Nothing Then
metadataBehavior = New ServiceModel.Description.ServiceMetadataBehavior()
metadataBehavior.HttpGetEnabled = True
metadataBehavior.HttpGetUrl = New Uri("http://localhost:27374/Node")
BNodeHost.Description.Behaviors.Add(metadataBehavior)
Else
BNodeHost.Description.Behaviors.Add(metadataBehavior)
End If
BNodeHost.Open()
This was all working before I made the different bits proper Windows Services and tried to add installers to it. The installers work fine and install the services which start and allow me to see all the WCF XML in IE.
As you might be able to tell, I am very new to WCF and this is my first application using it. The fundamental bits have been pretty much Copy/Paste/Alter jobs from a sample that doesn’t use config files.
Any help would be greatly appreciated.

verify that all the endpoints in the appconfig match the settings in the admin webapp's webconfig. each one sets various timeout values, ie:
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_ILookupService" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text"
textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<reliableSession ordered="true" inactivityTimeout="00:10:00"
enabled="false" />
<security mode="Message">
<transport clientCredentialType="Windows" proxyCredentialType="None"
realm="" />
<message clientCredentialType="Windows" negotiateServiceCredential="true"
algorithmSuite="Default" establishSecurityContext="true" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<behaviors>
<endpointBehaviors>
<behavior name="LargeEndpointBehavior">
<dataContractSerializer ignoreExtensionDataObject="true" maxItemsInObjectGraph="2147483647"/>
</behavior>
</endpointBehaviors>
</behaviors>
<client>
<endpoint address="http://localhost:59599/LookupService.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_ILookupService"
contract="FEEALookupServiceReference.ILookupService" name="WSHttpBinding_ILookupService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
</client>
</system.serviceModel>
hope that helps. good luck.

I couldn't work this one out properly. There seemed to be an issue with Windows Service to Windows Service communication. There is a way of making it happen somewhere but I ran out of time so I solved it by turning one of the bits (the Central Control) into a normal windows application and installed it that way. Works fine and the client is happy :)

Check the permissions for the users that the Windows Services are running under - they like to default to Network Service which may not have sufficient permissions. Run them as a dedicated user with the correct permissions.
And check Windows Firewall. It loves to block some of your web connections. I usually just turn it off.

Related

401 Client 'Negotiate', Server 'Negotiate,NTLM' When Calling WCF Server to Server

Ok, I've read every thread & question I can find with this error and surprisingly have not found a solution. I'm trying to require Windows authentication on my IIS hosted WCF service (.NET 4.0) which, until now, has been optional. I have had a Windows authentication enabled endpoint available on the server for a while with several remote applications successfully using it. I'm now trying to switch our web applications and other server apps that use the WCF service over to this secured endpoint by giving them the exact same client configuration as the working remote clients, but the server apps are receiving a 401 with the message:
The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'.]
I have Anonymous and Windows authentication enabled for the WCF hosting site. The web application I've started with is hosted on a different server than the WCF service and is running on ASP.NET 2.0 and Windows Server 2008 R2 Enterprise. I have both created a client behavior with allowNtlm and set the NetworkSecurity: LAN Manager authentication level to Send LM & NTLM... on the client end. On the hosting end, it is set to Send NTLMv2 Response Only...I don't know if that affects how the server/service handles authentication. I've also tried setting allowedImpersonationLevel to Impersonation on the client which, thankfully, didn't work (because impersonation shouldn't be necessary). We seem to get the same result for a Windows service and console app running on the same server as the web app.
Here is my server config:
<binding name="WindowsSecuredBinding">
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
</binding>
...
<service behaviorConfiguration="OMWebServices.QueueServiceBehavior"
name="OMWebServices.QueueService">
<endpoint address="" binding="basicHttpBinding" name="QueueEndpoint"
bindingName="" contract="OMWebServices.IQueueService" />
<endpoint binding="basicHttpBinding" bindingConfiguration="WindowsSecuredBinding"
name="QueueSecuredEndpoint" contract="OMWebServices.IQueueService" />
<endpoint address="mex" binding="mexHttpBinding" name="QueueMetadataEndpoint"
contract="IMetadataExchange" />
</service>
...
<behavior name="OMWebServices.QueueServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
And here is the client config:
<endpoint address="https://.../QueueService.svc" binding="basicHttpBinding" bindingConfiguration="QueueSecuredEndpoint" behaviorConfiguration="OMServiceBehavior" contract="OMQueueService.IQueueService" name="QueueSecuredEndpoint" />
<binding name="QueueSecuredEndpoint" 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="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="Transport">
<transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
....
<!-- The behavior I tried that didn't make a difference -->
<behavior name="OMServiceBehavior">
<clientCredentials>
<windows allowedImpersonationLevel="Impersonation" allowNtlm="True"/>
</clientCredentials>
</behavior>
My first question is, what is this error message really telling me? It says the client scheme is Negotiate and the server's responding with Negotiate,NTLM. If the server offers Negotiate and and client is using Negotiate, what's the problem?
Second question is, obviously, what's wrong and how do I make it work?
EDIT
Well this is stupid. The problem seems to be there are no credentials being passed. Way back when the web site was in development, I started writing code to explicitly set the credentials in code, but in the process, found that it was already working without explicitly setting them. So that code has remained commented out. This was running on IIS 6. Now running on IIS 7, it seems to only work if I explicitly set the credentials in my code. Can I get it automatically using the w3wp process' account?
To answer the first question, the error message is telling me exactly what it says; I'm not authorized. The line telling me the client authentication scheme and server header is just extra info, not an indication of a conflict. It's actually confirmation that the configuration is correct.
In the staging environment, the problem is being masked because the WCF service and the web application are hosted on the same server. The problem is the web app's site is configured to use IUSR (or IUSR_Server), a local account, for anonymous users by default. This is the user that is being passed (which I believe is equal to CredentialCache.DefaultNetworkCredentials). When they're on different servers, WCF on server 2 obviously can't authenticate a server 1 user. The solution is in IIS, right click Anonymous Authentication > Edit...> check Application pool identity (which is a domain account in my case) or enter a domain account for Specific user.
It just means your client and server are using different authentication scheme.
In your client config, you've set up a
<transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
and a message security
<message clientCredentialType="UserName" algorithmSuite="Default" />
So you might be getting errors because of this. These links might help you.
Ch. 7 Message and Transport Security
security of basicHttpBinding
Also, in your client config
<endpoint address="https://.../QueueService.svc" binding="basicHttpBinding" bindingConfiguration="QueueSecuredEndpoint" behaviorConfiguration="OMSServiceBehavior" contract="OMQueueService.IQueueService" name="QueueSecuredEndpoint" />
Change the behaviorConfiguration from behaviorConfiguration="OMSServiceBehavior"
to behaviorConfiguration="OMWebServices.QueueServiceBehavior"
Also did you try to use TransportCredentialOnly? If not, it might be good to try this http://msdn.microsoft.com/en-us/library/ff648505.aspx
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
My problem with this error was not config related but specific to
a WCF Service calling another on the same machine.
Because this affected a fleet of new servers that were partly provisioned through a C# console app, I solved it by executing code like this through the affected servers:
const string userRoot = "HKEY_LOCAL_MACHINE";
const string subkey = #"SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0";
const string keyName = userRoot + #"\" + subkey;
Registry.SetValue(keyName, "BackConnectionHostNames", hostnamesOnServer.ToArray(), RegistryValueKind.MultiString);
Reboot wasn't required on Windows Server 2012.
This can also apparently be an issue with your credentials not being passed correctly. I needed:
Client.ClientCredentials.Windows.ClientCredential.UserName = User;
Client.ClientCredentials.Windows.ClientCredential.Password = Password;
Instead of:
Client.ClientCredentials.UserName.UserName = User;
Client.ClientCredentials.UserName.Password = Password;
(Oddly, the second way worked once in a while for me, but not always.)
I was having exactly the same issue reported here. The AD account being used for credentials had had the password changed. Once I used the new password it started working.
This error is very misleading for an incorrect password situation.

Setting up a WCF host within a website project

This is going to be a weird question, but:
I'm currently running a wcf service on my website (made in Visual Studio 2012 - .scv file). I have a console client which I try to test the connection with in addition to the built in wcf test client. The test client runs fine and I'm able to call upon the functions, but when I stop running the site/test client (which should mean host by extension, right?), my console client can still run and talk to the service just fine.
I'm also able to visit the WCF service page while it's not running in the browser. When I created the WCF in console, I was not able to do any of these things while the host wasn't actually running. Because of this I'm wondering if there's something wrong with the code that I'm just not seeing.
I could see this developing into an issue when I try to get the website online on a server (since my testing client won't be located on the same machine as the service. I'm assuming this is happening because I have access to the files even when it's not running).
What should I do/what is wrong?
Thank you for your time.
relevant web.config code:
<system.serviceModel>
<services>
<!-- ICanHasGamez=solution that holds the webpage&wcfservice -->
<service name="ICanHasGamez.APIHost" behaviorConfiguration="behavior">
<endpoint address="" binding="basicHttpBinding" contract="ICanHasGamez.IAPIHost">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name ="behavior">
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"
multipleSiteBindingsEnabled="true" />
</system.serviceModel>
app.config code from the Console Client:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IAPIHost" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:2105/APIHost.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IAPIHost" contract="ServiceReference1.IAPIHost"
name="BasicHttpBinding_IAPIHost" />
</client>
</system.serviceModel>
</configuration>
In your website project's properties under the web tab, are you hosting it in IIS? If so, the WCF service will keep running, even if you're not using the built in WCF test client. IIS runs on its own, outside of the visual studio environment. You can turn off your service by stopping it in IIS manager, if you'd like, but otherwise it's usable outside of VS.
In contrast, running the WCF service in a console (known as self-hosted) will close down when it's host application, i.e your console application, closes.
In short, if you are using local IIS for your web project, then this isn't anything you've done wrong and is expected behaviour. And regarding running your service on a different machine to your test client, that's not a problem. If you're running it in IIS, then your hosting computer just needs IIS turned on and that project running in IIS there. Voila! If you're running the service as self-hosted, i.e in a console, just leave the console open. Check out this StackOverflow question for some of the pros and cons of self-hosted wcf vs IIS (the accepted answer is a bit local to that particular OP, but the answers below are more informative).
I hope this helps and I hope I'm not barking up the wrong tree here.
I don't see anything wrong with the scenario you described - its expected behavior.
When you host the WCF service in IIS, as long as IIS is up and running (and there's no other problems), your service can receive requests. If the service host has been disposed (due to inactivity timeout or other reasons), if a new request is received IIS will spin up a new instance.
On the other hand, if you're self-hosting the WCF service in, for example, a console app, then the only time that service is able to respond to requests is when the self-hosting application is running.
So to answer your question, you're not doing anything wrong, and you don't need to do anything different. You should be able to simply deploy the WCF Service to the remote server, and then access it with your client.

WCF - More than one endpoint configuration for that contract was found - Error

We have working ASP.Net web application with WCF. wcf service hosted as a windows service. All is fine. Then we made a change so that service contract will have different namespace (From Namespace1.IserviceContract to Namespace2.IserviceContract). After the change we deployed to the server and getting following error when we try to instantiate the service object.
System.InvalidOperationException: An endpoint configuration section for contract 'Namespace2.IserviceContract' could not be loaded because more than one endpoint configuration for that contract was found. Please indicate the preferred endpoint configuration section by name.
Generated: Fri, 06 Jul 2012 21:02:56 GMT
System.Web.HttpUnhandledException: Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.InvalidOperationException: An endpoint configuration section for contract 'Namespace2.IserviceContract' could not be loaded because more than one endpoint configuration for that contract was found. Please indicate the preferred endpoint configuration section by name.
at System.ServiceModel.Description.ConfigLoader.LookupChannel(String configurationName, String contractName, Boolean wildcard)
at System.ServiceModel.Description.ConfigLoader.LoadChannelBehaviors(ServiceEndpoint serviceEndpoint, String configurationName)
at System.ServiceModel.ChannelFactory.ApplyConfiguration(String configurationName, Configuration configuration)
at System.ServiceModel.ChannelFactory.ApplyConfiguration(String configurationName)
at System.ServiceModel.ChannelFactory.InitializeEndpoint(String configurationName, EndpointAddress address)
at System.ServiceModel.ChannelFactory`1..ctor(String endpointConfigurationName, EndpointAddress remoteAddress)
at System.ServiceModel.EndpointTrait`1.CreateSimplexFactory()
at System.ServiceModel.EndpointTrait`1.CreateChannelFactory()
at System.ServiceModel.ClientBase`1.CreateChannelFactoryRef(EndpointTrait`1 endpointTrait)
at System.ServiceModel.ClientBase`1.InitializeChannelFactoryRef()
at System.ServiceModel.ClientBase`1..ctor()
at TestApplication.ManagementWrapper.VerifyAuthentication(Int32 appId, String Token)
at TestApplication.VerifyAuthentication(String tokenstring)
we did a research about this issue and found that this type if exception shows up if we have two client endpoints defined in our web.config file. however we are certain that we have only one client endpoint defined. More over this exception shows up only in the server. local works fine. here is our service model:
<system.serviceModel>
<bindings>
<netTcpBinding>
<binding name="NetTcpBinding_Management" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" transactionFlow="false" transferMode="Buffered" transactionProtocol="OleTransactions" hostNameComparisonMode="StrongWildcard" listenBacklog="10" maxBufferPoolSize="4194304" maxBufferSize="2147483647" maxConnections="10" maxReceivedMessageSize="2147483647">
<readerQuotas maxDepth="32" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="32768" maxNameTableCharCount="2147483647" />
<reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false" />
<security mode="None" />
</binding>
</netTcpBinding>
</bindings>
<client>
<endpoint address="net.tcp://servername:9010/Management/service/ManagementService" binding="netTcpBinding" bindingConfiguration="NetTcpBinding_Management" contract="Namespace2.IserviceContract" name="NetTcpBinding_IserviceContract" />
</client>
</system.serviceModel>
we also tried to restart IIS and application pool. Still getting the same exception.
Try searching your web.config for another that is using the web address as your ManagementService. Also, search the web.config for any reference to the old namespace (contract="Namespace1.IserviceContract"). Don't forget to check for extra .config files. That little gotcha has burned me before.
Whatever protocol is being called like basic, net.tcp or wshttp, that address should be in web config file remove other addresses from client section in app.config file, in my case i am calling the service as htp://machinename:700/test.svc but in the client section there were addresses with net.tcp and wshttp configurations, removed those addresses and issue is fixed for me.
Please right click on svc file of your wcf service and click on View markup.
then modify namespace there also. It should work fine then.
If everything in your web.config appears to be correct, this error can be caused by another application on the same server. I spent several days troubleshooting a similar issue.
In my case, the environment had a large number of WCF services deployed as web applications in IIS under a single website as follows.
/Root Website
/Service1
/Service2
/Service3
/ServiceX
One of the child services was mistakenly deployed to the root website physical folder rather than to it's own physical folder. This bad deployment contained a client endpoint definition that was common to all of the services and caused all of the child services to break. Apparently, the same client endpoint cannot be used by the parent website and a child web application.
Removing the client endpoint from the root website fixed the issue for me.

Forming an HTTP request for a SOAP web service

I trying to acces this SOAP Web Service (http://iberius.scjn.gob.mx:8080/Mobile/Tematica.svc) and I also have its WSDL files available
http://iberius.scjn.gob.mx:8080/Mobile/Tematica.svc?wsdl
http://iberius.scjn.gob.mx:8080/Mobile/Tematica.svc?wsdl=wsdl0
http://iberius.scjn.gob.mx:8080/Mobile/Tematica.svc?xsd=xsd0
http://iberius.scjn.gob.mx:8080/Mobile/Tematica.svc?xsd=xsd1
http://iberius.scjn.gob.mx:8080/Mobile/Tematica.svc?xsd=xsd2
http://iberius.scjn.gob.mx:8080/Mobile/Tematica.svc?xsd=xsd3
But I'm never worked with soap and I'm not finding the WSDL files clear enough.
What I'm trying to do is query the service for the different operations available, for example the ListaMinistros operation that takes a parameter actualizacion that is a date in the format yyyymmdd.
I have tried every possible combination to contact the service but it responds with a Endpoint not found response.
If you could provide me with an example of the SOAP XML it would be great as almost all of the other available operations are the same so I cold see how to do it myself.
Thanks in advance
========
EDIT
I have set up the WSDL reference in a C# project with visual studio to se what kind of request it makes
the config file it comes up with its the following:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<bindings>
<customBinding>
<binding name="Rest">
<textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16"
messageVersion="Soap12" writeEncoding="utf-8">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
</textMessageEncoding>
<httpTransport />
</binding>
</customBinding>
</bindings>
<client>
<endpoint
binding="customBinding" bindingConfiguration="Rest" contract="SCJN.Tematica"
name="Rest" />
</client>
</system.serviceModel>
But it doesent includes the address for the endpoint, so I modified the endpoint to look like this:
<endpoint address="http://iberius.scjn.gob.mx:8080/Mobile/Tematica.svc"
binding="customBinding" bindingConfiguration="Rest" contract="SCJN.Tematica"
name="Rest" />
But the service responds with a endpoint not found.
So is there a way to find out wich address to call.
Also the WSDL does not list SOAPAction attributes but rather wsaw:Action in the operations supported, wich is translated in my .NET code to the following
[System.ServiceModel.OperationContractAttribute(Action="urn:Tematica/ListaMinistros", ReplyAction="urn:Tematica/ListaMinistrosResponse")]
ConsoleApplication2.SCJN.Ministro[] ListaMinistros(string actualizacion);
Try soapUI.org, it's a feature rich opensource/commercial web service explorer. You can feed in the WSDL and it will automatically create SOAP request stubs, which can be send to the endpoints named in the WSDL. Even the HTTP headers can be made visible.
You can download webservice studio.
Its free program and it will show you a soap message. Search in the google.
These articles [1][2] describes wsdl and soap.
The better options is to use the wsdl2java tool available with the platform. If there is no such thing available then you can use some other framework like Axis2 and examine the request and response messages for each and every operation.
[1] http://wso2.org/library/2873
[2] http://wso2.org/library/2935

implementing Ws-security within WCF proxy

I have imported an axis based wsdl into a VS 2008 project as a service reference.
I need to be able to pass security details such as username/password and nonce values to call the axis based service.
I have looked into doing it for wse, which i understand the world hates (no issues there)
I have very little experience of WCF, but have worked how to physically call the endpoint now, thanks to SO, but have no idea how to set up the SoapHeaders as the schema below shows:
<S:Envelope
xmlns:S="http://www.w3.org/2001/12/soap-envelope"
xmlns:ws="http://schemas.xmlsoap.org/ws/2002/04/secext">
<S:Header>
<ws:Security>
<ws:UsernameToken>
<ws:Username>aarons</ws:Username>
<ws:Password>snoraa</ws:Password>
</ws:UsernameToken>
</wsse:Security>
•••
</S:Header>
•••
</S:Envelope>
Any help much appreciated
Thanks, Mark
In order to call these kind of services, you will typically use either basicHttpBinding (that's SOAP 1.1 without WS-* implementations) or then wsHttpBinding (SOAP 1.2, with WS-* implementations).
The main issue will be getting all the security parameters right. I have a similar web service (Java-based) that I need to call - here's my settings and code:
app./web.config
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="SoapWithAuth" useDefaultWebProxy="false">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Basic" proxyCredentialType="None" realm="" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint name="SoapWithAuth"
address="http://yourserver:port/YourService"
binding="basicHttpBinding"
bindingConfiguration="SoapWithAuth"
contract="IYourService" />
</client>
</system.serviceModel>
and then in your client's code when calling the service, you need this snippet of code:
IYourServiceClient client = new IYourServiceClient();
client.ClientCredentials.UserName.UserName = "username";
client.ClientCredentials.UserName.Password = "top-secret";
Does that help at all?
The WCF client proxy doesn't support the password digest option. The only way to do this is to build the UsernameToken yourself and then inject it into the SOAP headers before the message is sent.
I had a similar problem which is described here, which should be enough to help you solve your same issue.
I ended up using the old WSE3.0 library for the UsernameToken, rather than coding the hashing algorithm myself and then using a custom behavior to alter the SOAP headers.

Resources