I'm trying to consume a WCF service, hosted in a shared server. it works perfectly with SOAPUI, but when i tried to do it with my vb.net application it give me this error:
the http request is unauthorised with client authentication scheme
"anonymous".
I tried a lot of solutions, changing the app.config of my application, adding security mode="TransportCredentialOnly", with clientCredentialType="Windows" and "NTLM", and it only changes the last part of the error, giving "Negotiate" with "anonymous".
here how i add security in app.config
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
I think this is an application problem because, as I said before, it works perfectly in SOAPUI, I don't know if I need to add something more.
The web.config of WCF:
<system.web>
<compilation debug="true" targetFramework="4.0"/>
<httpRuntime maxRequestLength ="262144" executionTimeout="103600"/>
</system.web>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="basicHttpBinding" maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647">
<readerQuotas maxDepth="32"
maxStringContentLength="2147483647"
maxArrayLength="2147483647"
maxBytesPerRead="2147483647"
maxNameTableCharCount="2147483647" />
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior>
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpGetEnabled="true"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true"/>
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
<httpErrors errorMode="Detailed"/>
</system.webServer>
EDIT:
I just receive an answer from server's provider and he said that there's a program, ModSecurity, that is blocking me access to WCF until i add a correct content header and user agent. How can i add it to the call?
UPDATE:
I used the answer of GMan80013 and now i'm stuck in this part.
I'm getting this error "Coul not load type 'Microsoft.ServiceModel.Dispatcher.HttpUserAgentBehaviorExtensionElement, SolutionPruebas.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' registered for the extension 'httpUserAgent'".
This error come from this part, I assume:
<behaviorExtensions>
<add name="httpUserAgent" type="Microsoft.ServiceModel.Dispatcher.HttpUserAgentBehaviorExtensionElement, SolutionPruebas.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</behaviorExtensions>
Or from here.
<behaviors>
<endpointBehaviors>
<behavior name="LegacyServiceEndpointBehavior">
<httpUserAgent userAgent="test user agent" />
</behavior>
</endpointBehaviors>
Related
I have a WCF service that is working great in production except for one new instance of a client that is unable to communicate with the service.
The WCF service runs over https on .Net 4.0 on a Windows Server 2008 R2 system. All clients are .Net 4.0 or higher (these are not under my control/config).
Enabling WCF Tracing in the service when this one client fails to connect shows this error:
"Failed to lookup a channel to receive an incoming message. Either the endpoint or the SOAP action was not found."
I have verified the exact same URL and WSDL are used by working clients and the one nonworking client. I CAN view the service information site and WSDL over https using a web browser.
I am suspecting a possible SSL/TLS negotiation failure, but wanted to check to see if others are familiar with this particular type of situation.
Here is my service web config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<compilation targetFramework="4.0" />
</system.web>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_INamedService">
<security mode="Transport" />
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="NamedService.NamedServiceService">
<endpoint address="/NamedServiceService" binding="basicHttpBinding" bindingNamespace="https://my.domain.com/NamedServiceService" bindingConfiguration="BasicHttpBinding_INamedServiceService" contract="NamedServiceService.INamedServiceService" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior>
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpsGetEnabled="true" />
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
</configuration>
Possibly a typo in your endpoint bindingConfiguration:
bindingConfiguration="BasicHttpBinding_INamedServiceService"
Your binding is named: BasicHttpBinding_INamedService not BasicHttpBinding_INamedServiceService
<basicHttpBinding>
<binding name="BasicHttpBinding_INamedService">
<security mode="Transport" />
</binding>
</basicHttpBinding>
not sure what your contract name is but it does have ServiceService in it too, might want to double check that out.
If it is in the same project, why is your service implement and service interface namespace different? There may be some spelling mistakes in your configuration. I suggest you check it carefully.
name="NamedService.NamedServiceService"
contract="NamedServiceService.INamedServiceService"
Besides, try to use the following configuration to set up https protocol.
<bindings>
<webHttpBinding>
<binding name="myhttpsbinding" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" sendTimeout="00:10:00" receiveTimeout="00:10:00">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" />
<security mode="Transport">
<transport clientCredentialType="None"></transport>
</security>
</binding>
<binding name="myhttpbinding">
<security mode="None"></security>
</binding>
</webHttpBinding>
</bindings>
Feel free to let me know if there is anything I can help with.
I am trying to use SSL certificate authentication in WCF/.NET version 4.0 IIS version 7.5, but, when I enable the oneToOneMappings authentication, the system does not recognize the maxReceivedMessageSize, when I comment out the oneToOneMappings authentication section, IIS recognize the maxReceivedMessageSize variable.
Any ideas about how to make this WCF service use the maxReceivedMessageSize value that I set when the SSL certificate authentication is enabled?
Service Model section:
<system.serviceModel>
<services>
<service behaviorConfiguration="AServiceBehavior" name="<IContract>">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="MutualSslBinding" contract="<IContract>" name="AnEndpoint" />
<host><baseAddresses><add baseAddress="https://asite.com/service" /></baseAddresses></host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="AServiceBehavior">
<serviceCredentials>
</serviceCredentials>
<serviceMetadata httpGetEnabled="false" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" httpHelpPageEnabled="true" />
<serviceSecurityAudit auditLogLocation="Security" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="MutualSslBinding" axReceivedMessageSize="2147483647">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647"
maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
<security mode="Transport"> <transport clientCredentialType="Certificate" /></security>
</binding>
</basicHttpBinding>
</bindings>
<serviceHostingEnvironment aspNetCompatibilityEnabled="false" multipleSiteBindingsEnabled="true">
</serviceHostingEnvironment>
</system.serviceModel>
Certificate Security section:
<system.webServer>
<security>
<access sslFlags="Ssl, SslNegotiateCert, SslRequireCert" />
<authentication>
<anonymousAuthentication enabled="true" />
<basicAuthentication enabled="false" />
<clientCertificateMappingAuthentication enabled="false" />
<digestAuthentication enabled="false" />
<windowsAuthentication enabled="false" />
<iisClientCertificateMappingAuthentication enabled="true" oneToOneCertificateMappingsEnabled="true" manyToOneCertificateMappingsEnabled="true">
<oneToOneMappings>
<clear />
<add userName="<LocalUser>" password="<EncryptedPassword>" certificate="<Authentication certificate text>" />
</oneToOneMappings>
</iisClientCertificateMappingAuthentication>
</authentication>
</security>
<modules runAllManagedModulesForAllRequests="true" />
<directoryBrowse enabled="false" />
</system.webServer>
On this specific case the issue was not related to the WCF configuration but to the uploadReadAheadSize setting in IIS.
TLS Overhead
When you are using SSL Certificate Authentication the overhead of your request can increase the size to more than 49Kb on the authentication process.
Returning the error 413 Entity Too Large
Use uploadReadAheadSize to control the allowed request size for IIS.
First verify the IIS Request Filtering.
To do this, open IIS Manager. Select your application. In the Features view you will see “Request Filtering”. Open this feature and on the right hand panel you will find “Edit Feature Settings”
Maximum Allowed Content Length is an Optional U-Int attribute. It specifies the maximum length of content in a request, in bytes. The default value is 30000000, which is approximately 28.6MB.
Next, we can set the uploadReadAheadSize in IIS.
To navigate to this setting, use the following steps:
Launch "Internet Information Services (IIS) Manager"
Expand the Server field
Expand Sites
Select the site your application is in.
In the Features section, double click "Configuration Editor"
Under "Section" select: system.webServer>serverRuntime
The default setting value is 49Kb.
Response provided by Wanjun Dong at MSDN
serverRuntime settings
Context
I'm playing with WCF configuration, trying to enable reliable sessions.
When reliable sessions are disabled, everything works as expected, and the client can successfully connect to the server. As soon as I put enabled="true" in <reliableSession> in the Web.config of the service and the App.config of the client, the following exceptions is thrown when the client tries to open the connection:
The message with Action 'http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequence' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).
There are many questions about this exception on Stack Overflow, but none of the answers seem to apply. For example, I checked that the receiveTimeout and inactivityTimeout are the same, that the context mode is PerSession both service and client-side, etc.
Here's the trace. You'll find below my configuration. What's wrong with it?
Trace
The exception in red is the one I quoted above.
The received message just before is a CreateSequence.
The message sent just after the exception is the addressing/fault message, intended to propagate the exception to the client.
Service-side configuration
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
<bindings>
<netTcpBinding>
<binding name="netTcpEndpoint" sendTimeout="00:10:00" receiveTimeout="00:10:00">
<reliableSession ordered="true" enabled="true" inactivityTimeout="00:10:00" />
<security mode="Message">
<message clientCredentialType="None" />
</security>
</binding>
</netTcpBinding>
</bindings>
<services>
<service behaviorConfiguration="DebugOrientedBehavior" name="Demo.PipeService">
<endpoint address="Default.svc" binding="netHttpBinding"
name="TransportLayerServiceEndpoint" contract="Demo2.IPipeService" />
<host>
<baseAddresses>
<add baseAddress="http://[removed the public URI of the service]/Default.svc" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="DebugOrientedBehavior">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
Client-side configuration
<system.serviceModel>
<bindings>
<netTcpBinding>
<binding name="netTcpEndpoint" sendTimeout="00:10:00" receiveTimeout="00:10:00">
<reliableSession ordered="true" inactivityTimeout="00:10:00" />
<security>
<message clientCredentialType="None" />
</security>
</binding>
</netTcpBinding>
<netHttpBinding>
<binding name="TransportLayerServiceEndpoint">
<reliableSession ordered="true" enabled="true" />
<webSocketSettings transportUsage="Always" />
</binding>
</netHttpBinding>
</bindings>
<client>
<endpoint address="ws://[removed the public URI of the service]/Default.svc/Default.svc"
binding="netHttpBinding" bindingConfiguration="TransportLayerServiceEndpoint"
contract="PipeServiceReference.IPipeService" name="TransportLayerServiceEndpoint" />
</client>
</system.serviceModel>
On the server config enspoint add:
bindingConfiguration="netTcpEndpoint"
currently the binding configuration is not attached to the endpoint so the default net tcp settings are used. it was good before the change you made but not any more.
I have a silverlight app that calls a wcf service, and I'm having trouble deploying it.
I can publish the files, but when the app tries to access the service, it doesnt seem to get anything back.
The app is set for client credentials with Windows Authentication
What's weird is that its not throwing errors. The silverlight app just seems to stop with a blank screen.
To test the deployed service, I try to access it from a browser, and I'm prompted for credentials. I try putting in my name and password, but it just asks me for credentials again.
What credentials is it prompting me for?
How can I get past this?
Here's the client config:
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IService" maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647">
<security mode="TransportCredentialOnly" />
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="../Service.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IService" contract="ServiceReference1.IService"
name="BasicHttpBinding_IService" />
</client>
</system.serviceModel>
</configuration>
Here's the web config:
<configuration>
<system.web>
<httpRuntime executionTimeout="180" />
<compilation debug="true" targetFramework="4.0" />
<customErrors mode="Off"/>
</system.web>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpStreamingBinding" maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647" transferMode="Streamed" receiveTimeout="01:00:00" sendTimeout="01:00:00">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
<!--<transport clientCredentialType="Ntlm" />-->
</security>
</binding>
</basicHttpBinding>
</bindings>
<client />
<behaviors>
<serviceBehaviors>
<behavior name="">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment
multipleSiteBindingsEnabled="true" />
<services>
<service name="CitationAir.MissionPlanning.WebService.Service">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="BasicHttpStreamingBinding"
contract="CitationAir.MissionPlanning.WebService.IService" />
</service>
</services>
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
Using Windows Authentication, you will get a password prompt if Integrated Windows Authentication is turned off`, which can be because you are using a browser other than Internet Explorer.
The password wont work if your account is locked out, if you are connecting to a service in an untrusted domain, or if your account does not have sufficient permissions to access the resource.
Could it be any of those in this case?
I developed a wcf service. Since it will also be called by non-.net clients, I used basichttpbinding. Some of the methods need Impersonation. This is forced by decorating the webmethods with:
[OperationBehavior(Impersonation = ImpersonationOption.Required)]
After I deployed the service on our test server, I get a strange error when I call the service:
Could not load file or assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821' or one of its dependencies. Either a required impersonation level was not provided, or the provided impersonation level is invalid. (Exception from HRESULT: 0x80070542)
I get this error independently of the way I call the service. I get it when I call it via wcfTestClient and I get it when I call it via a console application that I wrote. (I added the webservice as web reference to this application to simulate the behaviour of a non .net client.)
Any ideas?
PS: Here is the web.config of my webservice:
<system.web>
<compilation targetFramework="4.0" />
</system.web>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding closeTimeout="00:15:00" openTimeout="00:15:00" sendTimeout="00:15:00" maxBufferSize="2147483647" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="">
<dataContractSerializer maxItemsInObjectGraph="2147483647" />
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<defaultDocument>
<files>
<add value="CrmConnectorDiamondData.svc" />
</files>
</defaultDocument>
</system.webServer>
</configuration>
Well in WCF client must allow impersonation explicitly. In WCF client it is done by adding behavior to client proxy either through configuration:
<behaviors>
<endpointBehaviors>
<behavior name="myBehavior">
<clientCredentials>
<windows allowedImpersonationLevel="Impersonation" />
</clientCredentials>
</behavior>
</endpointBehaviors>
</behaviors>
Or in the code:
proxy.ClientCredentials.Windows.AllowImpersonationLevel = TokenImpersonationLevel.Impersonation;
I expect that this have to be configured for WcfTestClient because default impersonation level allows only idnetification.
In case of ASMX proxy make sure that you are passing your credentials.
My opinion is that windows authentication is not a good choice for services used by non-.NET clients (especially if you also mean non-Windows).
Looks like the log4net library is incompatable with that impersonation level. If you remove the reference it will work.