I have a WCF service which i host as a Windows Service. I need to support both Windows and NTLM authentication on the service endpoint.
I came across a MSDN page which explains exactly the same with .NET 4.5, here's the link:
http://msdn.microsoft.com/en-us/library/hh556235(v=vs.110).aspx
Going by this, I configured my service endpoint in code as explained in the self-hosted services section of the above link. But, when I test this doesn't work. I captured the traffic and observed that there's no HTTP 401 challenge sent by the service, instead, it directly fails with HTTP 400 Bad Request error. I believe that should have been a HTTP 401 challenge sent to client.
Did I miss anything here?
Well it is possible and I could make it work after 4 days of struggle, the errors HTTP Bad Request does not indicate the problem. But, As I added service metadata behavior with HttpGetEnabled it worked.
Also, ensure if you define ServiceAuthenticationBehavior you do mark the ClientCredentialType to InheritedFromHost. This would ensure the authentication schemes as indicated by the ServiceAuthenticationBahavior are applied.
Hope, this would save someone else's 4 days! :)
You can have multiple authentication schemes running within the same Windows service, but not at the same end point - that's not possible.
For instance, I can create and IIS or self-host a web service called NeedHelp that uses three kinds of authentication, and here are my endpoints:
http:/ /NeedHelp:8001/NoAuth
http:/ /NeedHelp:8002/WindowsAuth
http:/ /NeedHelp:8003/CertAuth
All of those can run under the same web service, all hosted by IIS or self hosted as a Windows service. But they all need separate port addresses.
Related
We have 2 Linux Web apps running in Azure ( blessed images, not custom ones) running on .NET 6 with custom domains - one API and an MVC app. It's a multitenant organization and the API is using the host header from the incoming HTTP request to resolve a tenants database. So far so good - on IIS everything is working great - we are setting the host header in the HttpClientFactory with the correct domain name, sending the request and the API does its job.
Now the problem - when deployed to Azure, when we set the header to the domain from which the request should be sent(which is the domain we are currently on), the container goes in to a loop when the first HTTP request occurs, executing this request over and over again and after some time our timeout DelegateHandler on the HttpClient is being hit. If we do not set the header the loop stops but we do not have the correct Host header in the request and our API is unable to process the request.
I know there is a reverse proxy which is resolving which web app should process the request based on the custom domain in Azure and I am pretty sure that's our problem but I am not very familiar with Azure architecture and don't know what to do.
P.S. If we use a custom header and set there the host name and reconfigure the API to use this custom request header everything works fine, but that's not what we want.
So any help would be of great help.
I don't do much client side web programming, so I'm trying to grasp this concept in how it relates to my specific situation.
I have a RESTful WCF service running on a port in the 50000s. Additionally, I have a bunch of web forms (not ASP WebForms) written in HTML5/CSS3/JavaScript that make AJAX calls to this WCF service. The web forms are hosted on the same host, but are using port 80. The AJAX calls made by the web forms are all GET only requests.
Additionally, I have a third-party cloud-hosted application that's in a completely different location (different host), which needs to call the WCF service as well. This communication is performing POSTs & PUTs to the WCF service.
Obviously the calls being made from the third-party hosted cloud application is cross origin. From my research it appears that the different ports are in fact different origins.
I know that security & CORS are different concepts, but here is what I'm trying to accomplish and I need to better understand how all of this works:
Right now I allow all cross-origin requests, and everything is working, but I'd like to limit it down to improve security and then eventually set up HTTPS with transport security with both the webforms & WCF service using the same certificate. The third-party cloud service hosted-app would still need to be able to communicate with the WCF service so I would need to allow it to authenticate differently, so that would be done with a secret-key being passed since everything is server-side only.
This whole communication 'triangle' feels murky to me, and I hope that SO is the right place for me to be posting this question since it isn't directly code related.
Is the WCF - web forms situation described above considered cross-origin?
A) If the above is not cross-origin, would I then only need to pass the Access-Control-Allow-Origin: 'https://my-cloud-host' in my web.config?
B) If it is I understand that just need to echo back the allowed origins(s) in the header. What do I set (if anything) for Access-Control-Allow-Origin in IIS in this case? What do I echo if it's not allowed, just the original origin?
Would my idea to use the same certificate for mutual SSL Authentication work if they are hosted on different ports? Would this prevent the cloud-service from communicating with the WCF service, or would having a second endpoint allow for this?
Am I losing my mind? I'm so confused by this whole thing.
Yes. In all major browsers except for IE, a different port IS considered to be another origin.
A) is correct. You need only to allow your port-80 origin to send requests.
I'm not sure about that. I tend to beleive that SSL is port-awared, and you can't use the same certificate on different ports.
You can read this excellent article to give your mind some rest.
So this is in relation to my question here.
So I have an existing wcf service running already, hosted on IIS. I created a Router Service that will do some XPath filtering on the header. So if the header is match then go to service1.
Now, I hosted my Router Service on IIS and I can access it like http://iis.com/myrouter/router.svc/ and give me this wsdl stuff. Now when I try to request a service method on service1 like this http://iis.com/myrouter/router.svc/general/getMyMethod?blah=blahblah. It gives me a 404 error. I used fiddler by the way.
On my request through fiddler I added my custom header like "service_version:1". I used a namespace by the way on my <namespaceTable> but I don't know how to append it on my request. Anyway, my main concern is how can I make my Router Service work on IIS?
Update: I am using System.ServiceModel.Routing.RoutingService by the way. So what I am trying to accomplish is Routing Services.
Your help is greatly appreciated.
You are likely facing this. A SOAP service can't be accessed that way because it relies on the SOAP package. Here is another article that should lead you down the right direction. However, the direction it leads you down is that testing a SOAP service by hand is not to be desired and probably a futile effort.
However, one note is that it leads you to use the WCF Test Client - that's the best direction to go my friend and it's very easy to use. Provide the URL and it will do the rest.
Invoke soap wcf service in Fiddler like in Wcf test client
Accessing the RESTful Endpoint
If you're trying to test the RESTful endpoint then the issue is likely surrounding the routing that is configured. Please refer to this link for assistance - make sure you're setting up your service the same because the attributes they use build the routing properly. Remember that you're not going to reference the RESTful endpoint with the same address as the SOAP endpoint.
http://geekswithblogs.net/michelotti/archive/2010/08/21/restful-wcf-services-with-no-svc-file-and-no-config.aspx
You can also check out this link.
Hosting WCF soap and rest endpoints side by side
I am developing a set of web services using ServiceStack.net. I plan to host these services on Appharbor. I am fairly new to appharbor and cloud hosting in general.
I see that there is an interface within the dashboard to upload my SSL cert. What other configuration do I need to do to AppHarbor and/or my application to get this working properly?
Another note, My Servicestack services will be hosted within an MVC website. I will require all servicestack calls to be made over SSL and have implemented a request filter to check for this and throw a 403 if a non-secure call is attempted.
If you are happy with SNI SSL support, no further configuration should be necessary. Use this gist to determine whether a request is made with an SSL-encrypted connection.
Is there any way I can accomplish the following:
Single Web.config file for a .net web application.
the web application exposes a number of WCF services for consumption by javascript.
Production requires ssl, so all these services are forced over ssl.
Development does not allow ssl, (ASP.NET development server)
How can I configure this so that production will utilize an HTTPS endpoint, and development will utilize an HTTP endpoint for the same service?
Adding two endpoints to the same service doesn't work, because when it tries to connect to the HTTP endpoint it throws an error since the asp.net development server doesn't support the https endpoint.
I solved this by using a ServiceHostFactory to generate the appropriate bindings for me.
It was a little awkward at first, having less control, but works out better in the end.
this is the line that was key, I put it in my .svc file:
Factory="System.ServiceModel.Activation.WebScriptServiceHostFactory"
I'm not certain that this is the best solution to your problem, but one way of doing this would be to declare in the config file a variable to indicate what environment this is running in (dev or prod). If you configure two endpoints, you could say in your hosting code,
if environment=="dev", then host the service on endpoint A.
if environment=="eval", then host the service on endpoint B.