Azure Cloud Service Instance Keep Recycling after deployment - SDK 2.6 - c#

I have ASP.NET MVC 5 project, referenced a SOAP Service from one of our client. I added the service using Visual Studio and, it requires a username/password authentication.
Here is the configuration part for the SOAP reference from the Web.Config file.
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="SoapBinding">
<readerQuotas maxDepth="32" maxStringContentLength="65536" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="*** SOAP URL ***" binding="basicHttpBinding" bindingConfiguration="SoapBinding" contract="** ContactName**" name="name1">
<headers>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken>
<wsse:Username>** username**</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">** password**</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</headers>
</endpoint>
</client>
</system.serviceModel>
Then, I created Azure Cloud Project, and publish the project from Visual Studio, but unfortunately the Instance is keep recycling.
The moment, I remove the <System.ServiceModel>, and remove the SOAP reference and redeploy; the web application works fine.
The MVC project run perfectly on local referencing the SOAP service, and I am able to communicate with the SOAP service.
Note: I have RDC to the azure instance and browse the application from IIS, I can see the page is loading and result are displaying from the SOAP service, but the Instance is keep recycling on Azure dashboard; therefore it won't be accessed from outside.
Any help will be appreciated. Thank you!

Related

C# SOAP Client use TLS instead of SSL 3.0

I have a C# application which is using Travelport Universal API interfaces through SOAP communication.
In C# I used the wsdls for generating the SOAP client.
I have this config settings for HTTPS connection (this was generated by Visual Studio from WSDL):
<system.serviceModel>
<bindings>
<basicHttpsBinding>
<binding name="AirLowFareSearchBinding" maxBufferSize="2097152" maxReceivedMessageSize="2097152">
<security mode="Transport">
<transport clientCredentialType="Basic" />
</security>
</binding>
</basicHttpsBinding>
</bindings>
<client>
<endpoint address="https://emea.universal-api.travelport.com/B2BGateway/connect/uAPI/AirService" binding="basicHttpsBinding" bindingConfiguration="AirLowFareSearchBinding" contract="AirServiceReference.AirLowFareSearchPortType" name="AirLowFareSearchPort" />
</client>
About this SSL3.0 vulnerability Travelport want to disabling SSL3, and I could use just over TLS.
My question is what should I change on this config, or should I change anything for TLS connection on https instead of SSL3.
In you code before calling to the service:
system.Net.ServicePointManager.SecurityProtocol=SecurityProtocolType.Tls12;
Here is a blog post Here

How do I set up WCF to consume Oracle web service using HTTPS?

I am currently using WCF to connect to our Java web services via the following configuration:
<bindings>
<basicHttpBinding>
<binding name="WebServicePortBindingHttp" maxReceivedMessageSize="500000">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Basic" proxyCredentialType="None" realm="" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://host:port/url" binding="basicHttpBinding" bindingConfiguration="WebServicePortBindingHttp" contract="Namespace.WSPort" name="WebServicePort" />
</client>
This is using normal HTTP. Even so, the server wouldn't authorize me until I manually added the WSSE headers using the method suggested in this answer. Once I started doing that, I was able to consume the web services without trouble.
On some of our environments, however, the server that my C# client must connect to uses HTTPS instead of HTTP. For this, the configuration given above does not work. To begin with, I had to change the security mode from TransportCredentialOnly to Transport, like so:
<binding name="WebServicePortBindingHttp" maxReceivedMessageSize="500000">
<security mode="Transport">
<transport clientCredentialType="Basic" proxyCredentialType="None" realm="" />
</security>
</binding>
I have tried numerous variations on these settings, however all that happens is the request times out. When I use Wireshark to trace the communication, I can see that the server is actually responding, but I can't interpret its response as the text appears garbled (I guess because it is encrypted).
This is what the binding configuration looks like that is automatically created by Visual Studio when I import the WSDL:
<customBinding>
<binding name="HTTPSoapBinding">
<textMessageEncoding messageVersion="Soap11" />
<httpsTransport />
</binding>
</customBinding>
But this still does not change the behaviour. It would appear that Microsoft and Oracle technologies do not simply interoperate.
Please advise.
I'm an idiot. There was something else causing the timeout! This configuration actually works:
<binding name="WebServicePortBindingHttp" maxReceivedMessageSize="500000">
<security mode="Transport">
<transport clientCredentialType="None" proxyCredentialType="None" realm="" />
</security>
</binding>
Strangely enough, now that I have identified the cause of my timeout, the webservice seems to accept just about any value for clientCredentialType (so far I have tried None, Basic and Windows, and all of them work). Could anyone explain this?
I apologize if I wasted anyone's time with this question.

What is wrong with my Silverlight / WCF Configuration

I've been struggling for a few hours I admit. I must be missing something with the Bindings/Configuration between my Silverlight application and WCF web service. It was working for awhile, but I must have accidentally changed some settings and I can't get it to work anymore.
In Visual Studio when I debug I have both the Service and Silverlight application launch at the same time, I have Windows authentication disabled in the web.config files for debugging. When I deploy, I go back and change my Configuration files to enable Windows security/transport so I can get user credentials on the web service side.
Now when I deploy both the WCF service and the Silverlight application to a different machine using IIS, I get an error "Not Found" from Silverlight when it attempts to contact the WCF service. Could someone explain to me the different configuration files that exist and what each should be pointing to? Here are my configuration files in their respective locations:
wwwroot\webserviceapp\web.config
<?xml version="1.0" encoding="UTF-8"?>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpEndpointBinding">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service behaviorConfiguration="ServiceBehavior" name="WebserviceName.Service1">
<endpoint address="" binding="basicHttpBinding"
bindingConfiguration="BasicHttpEndpointBinding"
name="BasicHttpEndpoint" contract="WebserviceName.IService1">
</endpoint>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" aspNetCompatibilityEnabled="true" />
wwwroot\web.config - this is the web.config for silverlight I guess?
<?xml version="1.0" encoding="UTF-8"?>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpEndpoint" 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="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://<<<ip_to_machine>>>/webserviceapp/Service1.svc"
binding="basicHttpBinding"
bindingConfiguration="BasicHttpEndpoint"
contract="ServiceReference1.IService1"
name="BasicHttpEndpoint" />
</client>
</system.serviceModel>
<system.webServer>
<defaultDocument>
<files>
<add value="ProjectTestPage.html" />
</files>
</defaultDocument>
</system.webServer>
wwwwroot\ClientBin\SilverlightApp.xap (the ServiceReferences.ClientConfig file):
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpEndpoint" maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647">
<security mode="TransportCredentialOnly" />
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://<<<ip_to_machine>>>/webserviceapp/Service1.svc"
binding="basicHttpBinding"
bindingConfiguration="BasicHttpEndpoint"
contract="ServiceReference1.IService1"
name="BasicHttpEndpoint" />
</client>
</system.serviceModel>
These are the three configuration files which seem to drive everything, unless I am wrong? Since I develop on one environment and deploy to another it seems like I must change these files to point to the right resources. When I hit my Silverlight application after I've deployed it to the new machine I get the application loading. Once it finishes loading, the first web service call it makes fails with exception and I get this in the Chrome Console:
Failed to load resource: the server responded with a status of 500 (Internal Server Error) http://<<<ip_to_machine>>>/webserviceapp/Service1.svc
Failed to load resource: the server responded with a status of 500 (Internal Server Error) http://<<<ip_to_machine>>>/webserviceapp/Service1.svc
Uncaught Error: Unhandled Error in Silverlight Application An exception occurred during the operation, making the result invalid. Check InnerException for exception details. at System.ComponentModel.AsyncCompletedEventArgs.RaiseExceptionIfNecessary()
at Project.ServiceReference1.GetAllNewsCompletedEventArgs.get_Result()
at Project.View.Home1.ClientGetAllNewsCompleted(Object pSender, GetAllNewsCompletedEventArgs pEventArgs)
at Project.ServiceReference1.Service1Client.OnGetAllNewsCompleted(Object state)
I'm like 99% certain that the Service is NEVER hit. I have a log statement at the very top of the function which is being called and it never logs anything.
IIS Configuration:
Web Service Authentication:
Anonymous = Disabled
ASP.NET Impersonation = Disabled
Windows Authentication = Enabled
Default Web Site (where my silverlight app is hosted):
Anonymous = Disabled
ASP.NET Impersonation = Disabled
Windows Authentication = Enabled
Anyone have any suggestions, or need anymore information from me to help debug?
EDIT: It is worth noting that I am able to navigate to the service from a different machine and see the service wsdl just fine. For example:
http://ipaddress/webserviceapp/Service1.svc
I can see this just fine, no errors.
I think the answer is pretty simple. The error I was receiving is a very generic error. The proper thing to do in this instance is to use Fiddler which will tell you EXACTLY what the error is. In my case, Trace logging wasn't working properly due to the service not loading properly. However, Fiddler was able to give me the exact exception messages which led me to resolve the problem quickly and easily.

WCF 4 REST - Multiple Standard Endpoints for Authentication

So I'm attempting to configure a WCF 4 REST app to utilize multiple standard endpoints (for the help functionality). The reason for this is that my hosting IIS process has both Anonymous and Windows Authentication enabled, and certain endpoints within my WCF app require one or the other (both results in an exception).
Previously, I was able to do this by defining some bindings:
<bindings>
<webHttpBinding>
<binding name="Anonymous">
<security mode="None" />
</binding>
<binding name="WindowsAuthentication">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
</webHttpBinding>
</bindings>
And then defining the services like so:
<services>
<service name="Host.SubscriberInfoHost">
<endpoint address="" binding="webHttpBinding" bindingConfiguration="WindowsAuthentication" contract="Host.ISubscriberInfoHost" />
</service>
<service name="Utilities.Instrumentation.ServiceStatus.ServiceStatusHost">
<endpoint address="" binding="webHttpBinding" bindingConfiguration="Anonymous" contract="Utilities.Instrumentation.ServiceStatus.IServiceStatusHost" />
</service>
</services>
This is what I've tried to do so far while utilizing the standard endpoints model:
<standardEndpoints>
<webHttpEndpoint>
<standardEndpoint name="Host.SubscriberInfoHost" helpEnabled="true" automaticFormatSelectionEnabled="true">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</standardEndpoint>
<standardEndpoint name="Utilities.Instrumentation.ServiceStatus.IServiceStatusHost" helpEnabled="true" automaticFormatSelectionEnabled="true">
<security mode="None" />
</standardEndpoint>
</webHttpEndpoint>
</standardEndpoints>
However doing this gets the service confused, as I receive:
System.InvalidOperationException: IIS specified authentication schemes 'Negotiate, Anonymous', but the binding only supports specification of exactly one authentication scheme. Valid authentication schemes are Digest, Negotiate, NTLM, Basic, or Anonymous. Change the IIS settings so that only a single authentication scheme is used
Which is exactly what I'm trying to get away from. Could anyone possibly give me a hand on how I would set this situation up using the new standard endpoints model? Thanks!
Found the answer to this after some experimentation. It turns out that the "name" attribute for standard endpoints is actually an endpoint configuration. So, you would use the following standard endpoints:
<standardEndpoint name="WindowsAuthentication" helpEnabled="true" automaticFormatSelectionEnabled="true">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</standardEndpoint>
<standardEndpoint name="Anonymous" helpEnabled="true" automaticFormatSelectionEnabled="true">
<security mode="None" />
</standardEndpoint>
And then, you would also configure a service such as the following (the "kind" and "endpointConfiguration" attributes must be set in order to tie this endpoint to the standard endpoint above)
<service name="SomeEndpoint">
<endpoint address="" kind="webHttpEndpoint" endpointConfiguration="WindowsAuthentication" contract="ISomeEndpoint" />
</service>
This allows you to mix authentication styles while maintaining the handy service help page.

Sporadic exceptions calling a web service that is load balanced

I have a web service that I am running on three load balanced web servers and I am getting sporadic errors. Now, I admit that the load balanced part may be a bit of a red herring, but when I test with only 1 web server I cannot reproduce the error. If I test with all three web servers I can get the error (but it is not 100% of the time, more like 50%). All testing is done through the load balancer, we just tell the load balancer how many servers we want to farm.
The code is simple single request code. That is, there is no state. A request is made and a response is returned. The web service code is c# .NET 4 running on IIS 7.5. The client code is both a web site and a desktop app.
I get one of two exceptions:
System.ServiceModel.Security.MessageSecurityException:
An unsecured or incorrectly secured
fault was received from the other
party. See the inner FaultException
for the fault code and detail. --->
System.ServiceModel.FaultException:
The security context token is expired
or is not valid. The message was not
processed.
Or I get:
System.ServiceModel.Security.SecurityNegotiationException:
Secure channel cannot be opened
because security negotiation with the
remote endpoint has failed. This may
be due to absent or incorrectly
specified EndpointIdentity in the
EndpointAddress used to create the
channel. Please verify the
EndpointIdentity specified or implied
by the EndpointAddress correctly
identifies the remote endpoint. --->
System.ServiceModel.FaultException:
The request for security token has
invalid or malformed elements.
As you can see from the following snips from my .config files, I am not using security as this is strictly an internal web service. (names have been changed to protect the innocent--namely me).
Server Side:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<!-- Service Side web.config -->
...
<system.serviceModel>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
<services>
<service behaviorConfiguration="InternalUseOnly.InternalUseOnlyServiceBehavior" name="InternalUseOnly.InternalUseOnlyService">
<endpoint address="" bindingNamespace="http://somecompany.com/webservices" binding="wsHttpBinding" contract="InternalUseOnly.IInternalUseOnlyService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="InternalUseOnly.InternalUseOnlyServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
...
</configuration>
Client side
<?xml version="1.0" encoding="UTF-8"?>
<!-- Client Side web.config -->
<configuration>
...
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IInternalUseOnlyService" 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" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<client>
<endpoint address="http://intranet.somecompany.com/InternalUseOnly/InternalUseOnlyService.svc" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IInternalUseOnlyService" contract="InternalUseOnlyService.IInternalUseOnlyService" name="WSHttpBinding_IInternalUseOnlyService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
</client>
</system.serviceModel>
...
</configuration>
Thoughts anyone?
Additional information: After reviewing the answers below I have tried two things, both without success.
The most obvious change (which I did not notice at first) was to change one of properties on the client to allow cookies <system.serviceModel><bindings><wsHttpBinding><binding name="blah, blah, blah" ... other properties... allowCookies="true" /> It defaults to false. Further, our load balancer uses cookies to keep affinity. But, it did not make a difference (no clue why yet).
Next, I tried various security options in the client side app.config file. This included both <security mode="None" /> and a more elaborate:
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" />
<message clientCredentialType="None" establishSecurityContext="false" negotiateServiceCredential="false"/>
</security>
although the settings in the last one was just a guess on my part. I did not make any server side changes to the app.config as I don't know what to change and, sadly, I can only test with production as we only have 1 dev web server, not three.
I am going to go out on a limb here and guess that the security involved is the Message security specified on the client side:
<security mode="Message">
<transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
<message clientCredentialType="Windows" negotiateServiceCredential="true" algorithmSuite="Default" />
</security>
If you are creating a client and connecting, the negotiated windows credential token may be cached. If you don't have sticky sessions enabled, the token might be passed back to the wrong server and will fail. My guess is that its always on the second call?
It is an NTLM problem caused by using load balancers without sticky sessions. To correct the problem you need to configure session affinity (sticky session). If you don't you will get a failure because part of the NTLM handshake happened on one server and the other part happens on another server.
While Chris and Jeff have help get me on the track to an answer, what actually solved it for me was this article i found from Microsoft on Load Balancing Web Services. In short, what we had to do to resolve this for our web farm was to switch from the default wsHttpBinding to basicHttpBinding. This was not difficult, but was an all-or-nothing move. The main web service and every client had to be reconfigured at the same time or it would break.
While wsHttpBinding does have a property of allowCooikes that could be set to true, it apparently does not use them until after the connection is made, at which point the request could jump servers on the first request and thus fail.

Categories

Resources