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
Related
Using Windows Azure Service, and exposing a WCF service endpoint from on premise (behind firewall, NAT ....) is it possible to make available an intranet site to a worker role in Azure?
Basically I want to be able to make an HttpWebRequest request from a worker role in azure to a site in on premise for example http:// intranet.domain.net. Is this possible? Or how can I make it possible?
This is not possible out of the box. You have a few options (non-trivial)
1) You will need to build a custom "proxy" that receives requests from Service Bus (over say WebHttpRelayBinding) and then forward the request to "local" IIS using HttpWebRequest or other HTTP clients. Note that this is a lot of work and needs thorough testing of corner cases (e.g. authentication scenarios). Also, it doesn't work with custom domain names (e.g. intranet.domain.net) over "https".
2) Alternatively, you can split the content/web-site and business-data/logic into separate pieces. You can host the content directly at a public site. This public site can then talk to a web-service in the intranet over NetTcpRelayBinding (or one of the *HttpRelayBinding) and execute business logic or retrieve the data.
I have a one question about WCF web service security.Currently, we are developing one android mobile project and using wcf web service for data transfer and manipulation.
We use basicHttpBinding and hosted the web service as Window Service.
We don't have any security mode at the moment and I am afraid of every one can consume our web service if they know the service address.
For example, we have one service method and that will return string value. Currently, I can add that service to other visual studio project and mobile project and we can consume any time.
//WCF Service Method
public string DoWork()
{
return "This is return string!";
}
//We can consume it like below from other dot net project by adding service reference.
//Actually, those are not real client.
ServiceReference1.WebServiceClient serv = new TestingPrj.ServiceReference1.WebServiceClient();
string result = serv.DoWork();
My question is how can I secure my web service for real clients? I don't want other projects and people to consume our web services.
The simplest method is to use Basic Authentication over SSL. Basic Authentication requires the client to have a username/password pair, which only your application will know. If the authentication is purely to know if your client is the right one (rather than knowing which user is connecting), then you can use a single, hard-coded username/password.
SSL should be used as well so the credentials don't travel the wire in plain-text and can potentially be sniffed.
Using ssl certificates is the most secure way.
I'm using custom basic authentication module (http://www.custombasicauth.codeplex.com) for authenticating users in WCF service. I've used a custom membership provider and in the ValidateUser method I've making a db call and returning true if the authentication succeeds. I also created a binding that uses transport security for the WCF service. Everything works fine now the problem is the client want two endpoints to be created for the WCF service and the custom basic authentication should happen for one endpoint not for the other.
Is it really possible to achieve this by using the custom authentication module or I have to try some other ways?
This is not possible when hosting your service in IIS. IIS has authentication scoped per whole virtual directory and your endpoints are exposed on the same service = single resource in single virtual directory. You must either move to self hosting and host service in windows service (you will not need that module anymore) or you must deploy the service again to different virtual directory or web application and change security configuration in each deployment separately (= every endpoint will be in separate deployed service).
I have a number of WCF 4.0 rest services on an internal application server which are accessed from a DMZ'd public facing web server. Essentially I am looking for the simplest way to restrict access to the services to calls from the web server and select internal accounts. It seems like a simple task of which I can find no simple answer.
Info:
IIS6 for both the web server and the application server
.NET 4
Web Server is not a part of a trusted domain
REST Services are 100% code.
Client calls are passing credentials via System.Net.CredentialCache.DefaultCredentials ( not sure if this is the way to go )
For the network part, you can disallow all IP's except the one of the ones you trust in IIS.
I have created and tested a WCF REST service that is protected with SSL and Windows Authentication through IIS 7. I have also created and tested a pure html/javascript web client that is hosted in IIS 7 that is protected with SSL and Windows Authentication -- same server, different "site" within IIS. The REST service is not public, but the web client is.
Without security, everything works beautifully, but now we are ready for field testing and security must be implemented.
My end goal is to have the user visit mywebclient.com and authenticate using their Active Directory accounts. Initially I thought it would be safe to leave the service calls from the client to the REST service unprotected (since the traffic from the web client to the web service would be internal), but this does not protect us from an internal attacker. Also, in the future, the REST services will be available to handhelds through native applications.
I've tried to gain as much information on this subject as possible, but every piece of Microsoft documentation contains client examples written in .NET.
How can I share the security context between these sites without converting the web client to a .NET-based application? Could this be accomplished by combining the web client and service into one IIS "site"?
Edit: If the client and service exist in the same app pool, does that mean they could share authentication information between client and server processes?