We have a DMZ where we host an IIS website which in turn communicates to our "app" server (also IIS) WCF services using TCP.
When we are on the domain and in the network this works fine. When we try to access the services from the DMZ we get a "cannot handle anonymous" user exception. Accessing the app server directly works fine.
Any suggestions on the best way to configure the security between the DMZ and the app server?
Thanks.
KJQ
netTcpBinding default to using Windows credentials so a different AD domain will not work. In a case like this using a mutual certificate is good option to validate between the DMZ and the actual service.
Related
I'm working on a wcf hosted inside a windows service. It works like a charm but now I need to reserve a specific hostname for this wcf just as IIS does.
To be more clear, my hosted wcf runs on a windows server machine which response to multiple dns name, but I need to let the wcf reachable only from one of these dns. If I was using IIS it would be achievable by setting a specific hostname within the http-bindings settings, but unfortunately, I can't manage my wcf like that.
To your knowledge, is there any way to reserve a specific hostname for a hosted wcf outside IIS?
Thanks in advance!
yes, you could do it by register the http endpoint at kernel level(http.sys) using the following commands
cmd: ***netsh http add urlacl url=http://fqdn:port/urlpath user=serviceaccount***
Then only on that specific dns/hostname, your http service will listen.
We have a server in our DMZ that we use to host our WCF web services on for some external clients.
This server only accepts connections from a single IP address to make it more secure.
Does anyone know if this it is possible to add application insights to a service that only accepts connections from a single IP? would I need to make changes to allow application insights to work?
Thanks
Martin.
Application Insights collects telemetry and sends it out to back-end servers hosted in Azure. So, till you have outbound connectivity to Azure, your web services will work fine with Application Insights.
I have an external (public) website developed in Silverlight. The Silverlight app currently calls http based wcf services hosted in IIS.
I am now having to call a wcf service with net.tcp binding hosted in a different app server. I have the net.tcp wcf service hosted in a windows service on port range 4502-4530 and with an interface to expose clientaccesspolicy.xml file as part of the service. I am able to invoke this service from my Silverlight app in the web server. I want the SL app to make direct call to net.tcp, rather than routing the call to it from another http based service.
Question is will this work without any issues when exposed over internet.
Client browser --> IIS webserver with Silverlight website --> App Server with wcf service on net.tcp.
I am assuming in this case, from XAP SL would try to make direct call to the app server service using net.tcp ?
The communication between the web server and app server could be opened up for ports 4502-4535. But I am wondering what about the client. Does this setup require the ports to be available even in the clients machine (with browser)?
Any insight is much helpful.
Thanks.
Take a look at http://support.microsoft.com/kb/2425652; there is sample code included as well! If you setup clientaccesspolicy.xml correctly; it should work as long as clients can access your TCP server.
If your clients are behind some firewall which is blocking your server's ports; they may face connectivity issues!
I need to host a WCF service that will give its clients access to internal business systems on a public facing web server. Obviously I must secure this so that no one from the outside world even knows the service exists, let alone be able to call methods and access the data it exposes.
The overall idea is that the public facing website hosted on the same machine will call the WCF service and then the WCF service will provide it with the required data...
Public Facing Web Site <-> WCF Service <-> Business Systems / Databases
So I need to understand how to secure the service so it can only be accessed via the public facing website.
Ideas I had..
IIS filtering so that the IIS Site hosting the WCF service will only accept requests from a certain IP address.
Obscure port that will not be allowed through the public facing firewall.
Protocol such as NetTCP or NamedPipes
But what about the actual WCF security set up? As both the Public Facing Site and the service are on the same machine is Windows Authentication as option? Questions I have regarding this are...
Should the service client and the service simply use Windows Authentication?
Do I need specific user accounts as opposed to Network Service? If the website runs under network service would this then automatically authenticate to the service?
My objective is that someone in the outside world should not know of the services existance or be able to make access to it.
Thanks in advance.
Technical environment is: IIS7, .Net 4 and WCF 4.
I would suggest you create a http handler '.ashx' and use that as the endpoint for client requests.
If your using asp.net you can secure it by using simple forms authentication and retrieving username and password from the request headers to authenticate the request.
Then execute any requests to your business webservices which is also secured by your forms authentication.
Cheers
I have a WCF service which is exposed using a single endpoint with netTcpBinding which sits on Server A, hosted on IIS7.5/WAS on our internal LAN on our domain.
This service is then consumed by an ASP.NET web client application sitting on Server B, also hosted on IIS7.5 with an external hosting provider outside of our domain, and linked to our LAN via a VPN secured to allow only traffic between Server A and Server B.
During development while I was testing the concept I ran the web client application on another IIS server internally on our domain using binding security mode="Transport" and transport clientCredentialType="Windows" which worked fine.
I then moved the web client application to the external Server B for further proof-of-concept testing setting the binding security mode="None", as obviously with this server being outside of our domain I cannot use Windows authentication, and it still works fine.
What I need to do now, to enable the switch back to using transport security is to set the clientCredentialType="Certificate", as you cannot have transport security with clientCredentialType="None".
This is where I have started to come unstuck. I seem to be going around in circles as to where in the web.config of the service and the client web.config to define the certificate and where to store which bits of the certificate.
Essentially what I'm trying to do is authenticate that Server B is indeed Server B calling the service on Server A, thus preventing any spoofing or DNS subversion issues, which could result in the service at Server A being illegally accessed.
My thinking is that I need to create a certificate for Server B to which Server A holds the public key to validate it? If this is the case Server B already has a wildcard SSL certificate installed on it as it serves various applications of ours as subdomains. Could this certificate be used for the WCF authentication?
None of the SO questions I've found seem to cover this, and all the various websites and book examples I've found aren't that clear. It's starting look like WCF configuration is somewhat of a black art.
This is all built using .NET 4 and Visual Basic. Any help would be greatly appreciated.
This MSDN example has examples of how to configure netTcpBinding with certificates in both code and config. Just pick the scenario that suits you. The certificate should be issued by a public (commercial) certificate authority like VeriSign or Thwate so it will be trusted by your external host provider and your internal server.