I have changed the user of the app pool my WCF service from "ApplicationPoolIdentity" to a custom user.
However, when I now make the call from the client to the service I am getting an SSPI failed error.
Here is the config for the client
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<client>
<endpoint
name="NetTcpBinding_IStaticService"
address="net.tcp://app02.company.com/StaticService/StaticService.svc"
binding="netTcpBinding"
contract="StaticServiceClient.IStaticService">
</endpoint>
</client>
</system.serviceModel>
</configuration>
I have been battling with this all day so some help would be really appreciated
Probably too late now to help you, but I've been getting that SSPI error ('cannot generate SSPI context') and discovered it was linked to having changed the password of the account used as the pool identity.
If you go into IIS and re-set the pool identity account with the new password that fixes it.
Related
I have a WCF service with basic authentication, which requires a username and password. I am using this service within a thick client and the username and password are stored in the application so can be easily passed.
I now want to use this service with an ASP.NET application. I have security enabled, and it is working fine. I want to know the best way of sending these credentials to my web service. The user name I can get easily using this.User.Identity.Name, but the password is more difficult. Of course I could store it in an encrypted session variable, but is this the right solution? Snippet of code below with the currently hard coded password shown:-
MyServiceClient client = new MyServiceClient();
client.ClientCredentials.UserName.UserName = this.User.Identity.Name;
client.ClientCredentials.UserName.Password = "Password";
BTW: This is my first question after many years of finding answers here, so please go easy on me :-)
To enable the authentication service
If you do not already have an ASP.NET Web application, create one.
Add a service file (.svc) to the Web site that contains the following directive to reference the AuthenticationService class, as shown in the following example:
VB
<%# ServiceHost
Language="VB"
Service="System.Web.ApplicationServices.AuthenticationService"
Factory="System.Web.ApplicationServices.ApplicationServicesHostFactory" %>
C#
<%# ServiceHost
Language="C#"
Service="System.Web.ApplicationServices.AuthenticationService"
Factory="System.Web.ApplicationServices.ApplicationServicesHostFactory" %>
Make the following configuration settings in the Web.config file to configure the service and to require SSL:
Enable the authentication service in the authenticationService element.
Define the endpoint contract in the services element and the service behavior in the behaviors element. Include the bindingNamespace property in the endpoint contract as shown in the following example in order to prevent an exception in some proxy generation tools. For more information about WCF endpoints, see Windows Communication Foundation Endpoints.
Configure the serviceHostingEnvironment element for ASP.NET compatibility. For more information about hosting WCF services, see WCF Services and ASP.NET.
Create a binding in the bindings element that requires SSL. For more information about transport security in WCF, see Transport Security.
The following example shows the system.serviceModel element from a Web.config file that shows the configuration settings described in the previous list.
<system.web.extensions>
<scripting>
<webServices>
<authenticationService enabled="true"
requireSSL = "true"/>
</webServices>
</scripting>
</system.web.extensions>
<system.serviceModel>
<services>
<service name="System.Web.ApplicationServices.AuthenticationService"
behaviorConfiguration="AuthenticationServiceTypeBehaviors">
<endpoint contract=
"System.Web.ApplicationServices.AuthenticationService"
binding="basicHttpBinding"
bindingConfiguration="userHttps"
bindingNamespace="http://asp.net/ApplicationServices/v200"/>
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="userHttps">
<security mode="Transport" />
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="AuthenticationServiceTypeBehaviors">
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment
aspNetCompatibilityEnabled="true"/>
</system.serviceModel>
To configure forms authentication
In the Web.config file, configure the Web application to use forms authentication.
The following example shows the authentication element in a Web.config file that is configured to use forms authentication.
<authentication mode="Forms">
<forms cookieless="UseCookies" />
</authentication>
The authentication service requires cookies. Therefore, in the authentication element, set the cookieless attribute to "UseCookies". For more information, see ASP.NET Forms Authentication Overview.
Security
If you are passing sensitive user data such as authentication credentials, always access the authentication service over the secure sockets layer (SSL, by using HTTPS protocol). For information about how to set up SSL, see Configuring Secure Sockets Layer (IIS 6.0 Operations Guide).
I've read the many other posts, but none have been able to help me. I'm running a WCF IIS project in one instance of Visual Studio, and in another I have a web forms client. The above error is what I get when I run both locally and the site tries to connect to the service. The EXACT same WCF code running on the server works when the same client running locally connects to it. I can't figure out why. I've tried to enable tracing but cannot get a file to generate. Here's my client config
<client>
<endpoint address="http://localhost:64974/Service1.svc/ws" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IService" contract="ServiceReference1.IService" name="WSHttpBinding_IService">
<identity>
<dns value="host"/>
</identity>
</endpoint>
</client>
and here's the WCF config
<services>
<service name="Service1">
<endpoint address="ws" binding="wsHttpBinding" contract="IService">
<identity>
<dns value="host"/>
</identity>
</endpoint>
</service>
</services>
I've changed the service names to remove private data
I've got it working now. Not sure what the problem was. I created a new client and ran it connecting locally to the WCF web project. Both are using the local development server. Thanks everyone for the help
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.
I have a windows service project that references an asp.net webservice. When I run this service locally on my machine via VS it works fine and when I call the web method I get the results I want.
Today I deployed this to a test server and when I call the web method it fails because the it is trying to connect to the local host webservice and not the one on the server. The error I get is "Unable to Connect to remote server --> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it: 127.0.0.1"
My service has a app.config file and the web service settings are correctly pointing at the webservice url. I know the url is correct as when I put it into IE it resolves to the webservice. Also the properties of the webservices are correct.
Any suggestions on how the service is getting hold of localhost would be greatly appreciated.
Could be a windows security issue. Are you calling the process/web method as an elevated? Also, is Windows Firewall Service Running? If so is there an exception for the IP/port/app process? Is RPC running? Check credentials and those listed above.
I would recommend that you store your proxy's address using the standard WCF configuration. Here's an example.
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IService1" />
</wsHttpBinding>
</bindings>
<client>
<endpoint address="http://yourServerIP:51717/Service1.svc" binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_IService1" contract="ServiceReference1.IService1"
name="WSHttpBinding_IService1">
</endpoint>
</client>
</system.serviceModel>
Resolved this today at work with the following lines of code.
webservice ws = new webservice()
ws.Url = (new xxxx.Properties.Settings()).WS;
ws.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;
Thanks for all your help guys
Cheers
APW
I have a WCF service that gets called from client side JavaScript. The call fails with a Service is null JavaScript error. WebDevelopment helper trace shows that the calls to load the jsdebug support file results in a 404 (file not found) error.
Restarting IIS or clearing out the Temp ASP.Net files or setting batch="false" on the compilation tag in web.config does not resolve the problem
From the browser
https://Myserver/MyApp/Services/MyService.svc displays the service metadata
however
https://Myserver/MyApp/Services/MyService.svc/jsdebug results in a 404.
The issue seems to be with the https protocol. With http /jsdebug downloads the supporting JS file.
Any ideas?
TIA
Figured it out!
Here is the services configuration section from web.config
Look at the bindingConfiguration attribute on the endpoint. The value "webBinding" points to the binding name="webBinding" tag in the bindings and that is what tells the service to use Transport level security it HTTPS. In my case the attribute value was empty causing the webservice request to the /js or /jsdebug file over HTTPS to fail and throw a 404 error.
<services>
<service name="MyService">
<endpoint address="" behaviorConfiguration="MyServiceAspNetAjaxBehavior" binding="webHttpBinding" bindingConfiguration="webBinding" contract="Services.MyService" />
</service>
</services>
<bindings>
<webHttpBinding>
<binding name="webBinding">
<security mode="Transport">
</security>
</binding>
</webHttpBinding>
</bindings>
Note that the bindingConfiguration attribute should be empty ("") if the service is accessed via http instead of https (when testing on local machine with no certs)
Hope this helps someone.
If you still get the same error after all your possible work done. Just add a "AJAX Enabled WCF-Service".
For me the issue was the following; we added MVC to a solution with routing. Our WCF services were not being ignored. I resolved this by adding the following rule (where "WCF" is the folder we keep our services in).
routes.IgnoreRoute("WCF/{*pathInfo}");
Hope that saves somebody a few hours.