I am struggling hard with getting WCF service running on IIS on our server. After deployment I end up with an error message:
Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service.
I want to use Windows authentication and thus I have Anonymous access disabled. Also note that there is aspNetCompatibilityEnabled (if that makes any difference).
Here's my web.config:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<bindings>
<webHttpBinding>
<binding name="default">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" proxyCredentialType="Windows"/>
</security>
</binding>
</webHttpBinding>
</bindings>
<behaviors>
<endpointBehaviors>
<behavior name="AspNetAjaxBehavior">
<enableWebScript />
<webHttp />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="defaultServiceBehavior">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="false" />
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceAuthorization principalPermissionMode="UseWindowsGroups" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service name="xxx.Web.Services.RequestService" behaviorConfiguration="defaultServiceBehavior">
<endpoint behaviorConfiguration="AspNetAjaxBehavior" binding="webHttpBinding"
contract="xxx.Web.Services.IRequestService" bindingConfiguration="default">
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" name="mex" contract="IMetadataExchange"></endpoint>
</service>
</services>
</system.serviceModel>
I have searched all over the internet with no luck. Any clues are greatly appreciated.
So it seems like pretty common issue. The point is to remove mex from your bindings:
<endpoint address="mex" binding="mexHttpBinding" name="mex" contract="IMetadataExchange"></endpoint>
Alternativelly you enable Anonymous access in IIS and in your web.config you make sure anonymous access is denied.
Hope this will help some other soul.
(I was 100% sure I tried it with mex removed. :-O )
You may check this one.
I managed to make it work as expected.
<configuration>
...
<system.serviceModel>
...
<bindings>
<basicHttpBinding>
<binding>
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
</basicHttpBinding>
</bindings>
...
</system.serviceModel>
...
</configuration>
just use your service bindings for mex too.
So change your current config :
<endpoint address="mex" binding="mexHttpBinding" name="mex" contract="IMetadataExchange"></endpoint>
to
<endpoint address="mex" binding="webHttpBinding" bindingConfiguration="default" name="mex" contract="IMetadataExchange"></endpoint>
That should solve the problem
Anonymous authentication can, and in some cases must be enabled for the service but not for the site.
So check that your site's "root" authentication has only Windows Authentication enabled. Then expand your site, select 'service' folder and make sure that your service has Windows and Anonymous Authentication enabled.
I had identical environment where this worked, only difference in these environments was the service's authentication. Problem in my case was not caused be selected providers (Ntlm or Negotiate) but the authentication settings for site and service.
At least I had identical error message with basic MSSQL Master Data Services web site & service and this was the solution. I did get the error when running just the service but the site worked almost ok, MDS Explorer did not work because service's authentication settings were wrong at first. Cause of this miss-configuration might be a bug in MDS Configuration Manager when creating new MDS site?
So in my case the problem was not to be fixed by doing any special editing to the web.config nor the ApplicationHost.config files, I didn't do any editing the config files. Just selected the correct authentication settings for the web site and it's service in IIS manager. I am not sure that this is the case in here, but maybe worth to try?
It worked for me when I remove 'mex' endpoint and also set clientCredentialType = 'Ntlm'
I was hosting my WCF inside SharePoint.
Yes, it looks like you need to remove the mex endpoint completely. Setting
<serviceMetadata httpGetEnabled="false"/>
alone did not work. Thanks!
Additional solution:
You just have to make sure that the Service name and contract are correct.
Hope it helps in some way.
It appears this MEX binding issue was fixed in .NET 4.0. Changing our server's App Pool .NET CLR version from 2.0 to 4.0 cleared up the issue.
Related
After hours of searching for examples, most of which contain only snippets of methods but not the 'whole picture' I am asking for guidance. Starting with the out-of-the-box web.config Visual Studio creates with a new WCF Service, I wrote my basic web service. When you run in debug, WCF Test Client shows the functions that you can test. This is great. Now, wanting to move the code to IIS (first on my local machine, then next to the web server using SSL), I added some code I found on the web. I did have my configuration working at one point but managed to change it so much that I lost the original configurations. So, which that, I have this:
<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5"/>
</system.web>
<system.serviceModel>
<protocolMapping>
<add scheme="http" binding="webHttpBinding"/>
</protocolMapping>
<services>
<service name="TaskTrackerAppService.Service1" behaviorConfiguration="">
<endpoint address=""
binding="webHttpBinding"
contract="TaskTrackerAppService.IAppWebService"
behaviorConfiguration="WebBehavior"></endpoint>
<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" bindingConfiguration=""></endpoint>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="WebBehavior">
<webHttp/>
</behavior>
</endpointBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="TaskTrackerAppService.IAppWebService"></binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="" binding="webHttpBinding"
bindingConfiguration="TaskTrackerAppService.IAppWebService"
contract="TaskTrackerAppService.IAppWebService"></endpoint>
</client>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"
multipleSiteBindingsEnabled="true" />
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
<!--
To browse web app root directory during debugging, set the value below to true.
Set to false before deployment to avoid disclosing web app folder information.
-->
<directoryBrowse enabled="true"/>
</system.webServer>
I configure my client desktop application service reference to point to the local IP http:192.168.0.100:90/AppWebService.svc. Then when I run my client application I get an error:
Could not find default endpoint element that references contract 'ServiceReference.IAppWebService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.
So I'd like to get the web.config settings corrected. Then deploy to a hosted IIS service where SSL is ready. As a bonus, is there is way to configure the endpoints such that I can still run debugger and get WCF Test Client. In the once working config WCF test stopped working. Can it support both simple and hosted configurations?
Thanks.
The <client> section in the <system.serviceModel> is used by client application to specify the "ABC" properties (Address, Binding, and Contract) of the service endpoint. You should have that section in your desktop application so you can simply remove it from your server configurations.
The <client> section in the app.config of your desktop application should, however, have the same "ABC" properties as the service endpoint. Since your service binding is webHttpBinding the client should also have webHttpBinding as binding but I can see that the bindingConfiguration it is referring to, TaskTrackerAppService.IAppWebService is actually a basicHttpBinding so that is a misconfiguration.
Further, since your production environment is using SSL so your production web.config should have binding configuration for SSL something similar to this:
<bindings>
<webHttpBinding>
<binding name="webBindingHTTPS">
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
</binding>
</webHttpBinding>
</bindings>
with the following endpoint configuration:
<endpoint address=""
binding="webHttpBinding"
contract="TaskTrackerAppService.IAppWebService"
behaviorConfiguration="webBindingHTTPS"></endpoint>
The best way to achieve this is to use web.config transformation syntax. In that case, your Release web.config could have the following elements:
<bindings>
<webHttpBinding>
<binding name="webBindingHTTPS" xdt:Transform="Insert">
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
</binding>
</webHttpBinding>
</bindings>
<endpoint address="" xdt:Transform="Replace" xdt:Locator="Match(name)"
binding="webHttpBinding"
contract="TaskTrackerAppService.IAppWebService"
behaviorConfiguration="webBindingHTTPS">
</endpoint>
In this way, whenever you project is built in Debug mode it will be configured withoud SSL and whenever is built in Release mode, it will use SSL.
I'm trying to create a basic webservice with WCF. It's small, and will only be used internally between two servers, so there is no need for security of any kind. Unfortunately WCF demands a certificate:
The service certificate is not provided. Specify a service certificate in ServiceCredentials.
I don't want to configure a certificate anywhere. Certificates are great for security, but also invariably come packaged with two days worth of headaches until you get them right just so, and I don't want that right now.
I'm googling all around but cannot find an answer anywhere - can you disable this feature of WCF?
Added: Almost forgot, here's my bindings 'n stuff, just in case they're useful:
<bindings>
<wsFederationHttpBinding>
<binding name="XXXServiceBinding" maxReceivedMessageSize="1073741824">
<readerQuotas maxStringContentLength="1073741824" maxArrayLength="2147483647"/>
</binding>
</wsFederationHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="XXXServiceBehavior">
<dataContractSerializer maxItemsInObjectGraph="2147483646"/>
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service name="XXX.XXX" behaviorConfiguration="XXXServiceBehavior">
<endpoint address="xxx" contract="XXX.IXXX" binding="wsFederationHttpBinding" bindingConfiguration="XXXServiceBinding">
<identity>
<dns value="XXX Test Service"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
Added 2: Oh, right, VS2010, .NET 4.0. Windows 7, integrated VS webserver.
What does your web.config bindings section look like? Using basicHttpBinding with clientCredentialType="None" should as far as I know run without any certificates. Ie:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IServiceWS">
<security mode="None">
<transport clientCredentialType="None" />
</security>
</binding>
</basicHttpBinding>
</bindings>
....
If you don't want to use security why are you using WsFedarationBinding which is designed for federated security? Use BasicHttpBinding instead. It doesn't use any security by default or if all communication will be performed in the same windows domain with users and service using domain accounts you can use WsHttpBinding with default configuration - it will use Windows security without need for any certificate.
You are using wsFederationHttpBinding in the service. If it is not important to push in so much of security, you could have gone for simple HTTP binding called basicHTTP binding. Consider appropriate binding for the service.
I've written a WCF web service for consumption by a Silverlight app. Initially, the service only required a basic http binding. We now need to be able to deploy the service for use under both http and https. I've found some settings for web.config that allow me to do this as follows:
<system.serviceModel>
<behaviors>
<endpointBehaviors>
<behavior name="SilverlightFaultBehavior">
<silverlightFaults />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="CxtMappingWebService.CxtMappingWebServiceBehavior">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="True" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="SecureHttpBinding">
<security mode="Transport" />
</binding>
<binding name="BasicHttpBinding">
<security mode="None" />
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="CxtMappingWebService.CxtMappingWebService" behaviorConfiguration="CxtMappingWebService.CxtMappingWebServiceBehavior">
<endpoint address="" bindingConfiguration="SecureHttpBinding" binding="basicHttpBinding" contract="CxtMappingWebService.ICxtMappingWebService" behaviorConfiguration="SilverlightFaultBehavior" />
<endpoint address="" bindingConfiguration="BasicHttpBinding" binding="basicHttpBinding" contract="CxtMappingWebService.ICxtMappingWebService" behaviorConfiguration="SilverlightFaultBehavior" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
</system.serviceModel>
Unfortunately, however, there's a problem with this.
This web service needs to be deployed to hundreds of our customers' servers, and not all of them will be using https. Deploying it to a server that doesn't have an https binding set up in IIS causes it to fail. Is there a way to have both of these bindings in the web.config by default without it dying if there's not an https binding set up in IIS?
We've got a possible solution for this problem, but it doesn't really fit well with our deployment requirements.
Has anybody else encountered anything like this before, and how did you resolve it?
The accepted answer on this page is not of much use if you don't use an installer.
The correct answer lies in a later edit by the OP himself, all one needs to do is bind both http and https ports in IIS and then use the configuration below.
<service name="CxtMappingWebService.CxtMappingWebService" behaviorConfiguration="CxtMappingWebService.CxtMappingWebServiceBehavior">
<endpoint address="" bindingConfiguration="SecureHttpBinding" binding="basicHttpBinding" contract="CxtMappingWebService.ICxtMappingWebService" behaviorConfiguration="SilverlightFaultBehavior" />
<endpoint address="" bindingConfiguration="BasicHttpBinding" binding="basicHttpBinding" contract="CxtMappingWebService.ICxtMappingWebService" behaviorConfiguration="SilverlightFaultBehavior" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
That worked just fine for me!
In the end, we decided to go with external files using the configSource attribute for the bindings, behaviors, and services sections of the web.config, like so:
<bindings configSource="bindings.config" />
<behaviors configSource="behaviors.config" />
<services configSource="services.config" />
This way, we deploy it by default with those external files set up for http access only, and give the customer instructions (or assist them) on how to edit the external files to set up for https access. This also allows us to deploy future changes to the web.config itself without overwriting the external config files.
This would be handled by the installer you use to deploy the service. It should be a prerequisite (or at least leave an option in the installer) to deploy the both endpoints or only the http one.
Two of your endpoints have the same URI. This is not permitted in WCF. You should be able to specify endpoints with different bindings, but the URI's must be different (i.e. different port number or different contract).
Help please!!
I had the following set up working perfectly:-
WCF Service Library hosted in web site on local IIS 7
Silverlight Application on a web site on local IIS 7 using above services
The solution I am writing is for intranet and not internet use, however I have been told by my bosses that it needs to be over Https. I am using Windows Authentication.
Below is a chunk of the config file for one of the service endpoints (changed to remove company info etc):-
<services>
<service behaviorConfiguration="stdHttpBehavior" name="WcfServiceLibrary.StaticDataService">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="windowsHttpBinding"
name="StaticDataService" contract="WcfServiceLibrary.ServiceContracts.IStaticDataService" />
<endpoint address="mex" binding="mexHttpBinding" name="" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://localhost/WcfServiceLibrary/StaticDataService/" />
</baseAddresses>
</host>
</service>
<behaviors>
<serviceBehaviors>
<behavior name="stdHttpBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<dataContractSerializer maxItemsInObjectGraph="2147483647" />
</behavior>
</serviceBehaviors>
</behaviors>
To experiment with Https I created a 'Self-Signed Certificate'. I then added https to the Default Web Site bindings and changed the two web sites to require SSL and also changed the relvant URIs in the config files. I managed to get this to work but now I want to go back to standard Http and finish the project in that mode as it was easier to work with. I changed all the settings back (and I have checked these extremely carefully).
Now I get this error if I try to downoad the Service definition in the Silverlight project: -
'Could not find a base address that matches scheme https for the endpoint with binding BasicHttpBinding. Registered base address schemes are [http].'
If I put back the certificate and binding in IIS. The Service definition appears to download OK, however it references an https URI and therefore none of the actual service calls work as they are http adresses!
I tried adding a new web site to host the service but got the same errors.
I have been trying to solve this for the last couple of days but cannot find an answer. It seems as though there is a hidden reference somewhere and not in my project as it continued with a new web site added to IIS.
To use SSL over HTTP under Basic HTTP binding, you need to switch your endpoint to use Transport-level security. In your case you will also want to indicate the client credential type:
<bindings>
<basicHttpBinding>
<binding name="windowsHttpBinding">
<security mode="Transport">
<transport clientCredentialType="Windows" />
<message />
</security>
</binding>
</basicHttpBinding>
</bindings>
It may seem obvious, but did you change the security mode on the windowsHttpBinding binding configuration to BasicHttpSecurityMode.None?
<bindings>
<basicHttpBinding>
<binding name="windowsHttpBinding">
<security mode="None" />
</binding>
</basicHttpBinding>
</bindings>
Related resources:
Transport Security Overview
BasicHttpSecurityMode Enumeration
We are using AJAX Cascading dropdown and AutoComplete functionality with Restful WebService Services providing data. With one endpoint(non-secured) eveything was working fine, until we tried same web page with https. Our Webappplication needs to support both. Our of very few articiles/blogs on this issue I found 2 which applies to my requirements.
http://blog.abstractlabs.net/2009/02/ajax-wcf-services-and-httphttps.html
http://www.mydotnetworld.com/post/2008/10/18/Use-a-WCF-Service-with-HTTP-and-HTTPS-in-C.aspx
I followed same pattern, added 2 endpoints, assuming WCF will pickup appropriate endpoint looking at HTTP or HTTPS protocol. Worked like a charm in my dev machine(XP-IIS5) and 1 Server 2003R2(IIS6), however did work in Production server 2003-IIS6. Website in IIS is exact same(including permission etc).
The error it throws - Error 500(Could not find a base address that matches scheme https for the endpoint with binding WebHttpBinding. Registered base address schemes are [http]..)
Here's the sample configuration(ignore typos)
<system.serviceModel>
<bindings>
<webHttpBinding>
<binding name="SecureBinding">
<security mode="Transport"/>
</binding>
</webHttpBinding>
</bindings>
<behaviors>
<endpointBehaviors>
<behavior name="SearchServiceAspNetAjaxBehavior">
<enableWebScript />
</behavior>
</endpointBehaviors>
</behaviors>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<services>
<service name="SearchService">
<endpoint address="" behaviorConfiguration="SearchServiceAspNetAjaxBehavior"
binding="webHttpBinding" contract="SearchServiceContract" />
<endpoint address="" behaviorConfiguration="SearchServiceAspNetAjaxBehavior"
binding="webHttpBinding" bindingConfiguration="SecureBinding" contract="SearchServiceContract" />
</service>
</services>
</system.serviceModel>
Any help on this is highly appreciated ?
Thanks
KSS
I'm using almost the same configuration in my service, though my endpoint behavior references <webHttp /> instead of <enableWebScript />. You mentioned your servers are the same, but in any case, have you tried testing SSL traffic elsewhere on the affected server?