I have a WCF Service hosted as Windows Service and client is an ASP.Net application consuming WCF Service methods.
In process of implementing security, I am confused over which among netTcpBinding/wsHttpBinding will be suitable for my case.
Most likely all the applications in scene (WCF Service, Windows Service, ASP.Net Website) will be sitting on different servers in our office, thus in an Intranet. ASP.Net website will be accessed by users over Internet.
Though, I can always use wsHttpBinding here, will it be suitable to set the service endpoint using netTcpBinding in my case?
Check this out for a comparison of all the different built in bindings:
Configuring System-Provided Bindings - MSDN
As for your case, as long as it's the web server contacting the WCF service and you don't need to provide an endpoint for any external consumers of the service...netTcpBinding should be up to the job.
You can expose your service over more than one binding if you wish, so you could actually use both.
However, if you control both client and service and they both use WCF, netTcpBinding is much faster. Unless you have a firewall between those two, I would choose that.
Use netTcpBinding instead wsHttpBinding if you are willing to trade interoperability for performance knowing that you can easily cancel the trade if you are not satisfied with the results (it's a matter of changing config values).
Since your WCF Services will be accessed by applications sitting in your office (INTRANET), I would go with netTcpBinding.
In an intranet scenario, it is recommended that you use netTcpBinding unless you have a specific requirement to use other bindings such as wsHttpBinding. By default, netTcpBinding uses binary encoding and transport security, which delivers better performance.
Following URLS will help to get more information
http://msdn.microsoft.com/en-us/library/cc949026.aspx
http://msdn.microsoft.com/en-us/library/ms730879.aspx
Since your WCF service is a windows service +1 for netTcpBinding. Hosting netTcpBinding on IIS is difficult.
Related
What are the pros and cons of hosting a WCF service in IIS versus using a Windows service?
FYI - I have googled but it's surprisingly hard to find relevant answers.
We've just implemented a big WCF service, and did it as a self-hosted windows service. The reason we did it that way was our architects wanted the extra control you get from hosting your own and taking IIS out of the equation. Basically, when you go the self-hosted route,
you process each request
you configure your own endpoints
you configure your certs
you control the exception handling
etc.
Our WCF service is industrial scale with rev proxies, load balancing and about 50 methods attached to the endpoints. And we use multiple encryption protocols depending on the types of devices connecting.
However, if I was doing a smaller WCF web service with just a single server, a single endpoint and a few method calls, I'd probably use IIS to manage the endpoint and implement the SSL letting the UI do the configuration work that would otherwise have to be done in code. It's just easier from what I've seen.
Long story short, if you host it, you control everything in code. If you're interested in a quicker delivery, I'd start with IIS.
I have a silverlight web application and I am loading data to the client side using a wcf service. Should I secure the WCF service? Can anyone who's on the network call methods of the service?
Yeah they can see and access the service if they know the url.
And if they can see it, they only need to do a "Add Service reference" and they can see all methods available.
And since silverlight uses the basichttpbinding, it can work through firewalls (they typically allow http traffic).
You should secure it if it contains sensitive info.
By default you'll have security through obscurity, so if you're not broadcasting your WCF service's presence, it's not likely to be found or called. Additionally, it would be very hard to use it without having an appropriate client proxy configured. If you do not have the MEX endpoint set up, you are again pretty safe.
All that said though, you haven't really authorized the calls. It's theoretically possible to locate your WCF service and create a proxy to call it. So if you want to be safe, which I recommend, look into WCF authorization. It's fairly easy to set up, and you can use various options such as username-password, Windows accounts, or X.509 certificates. Each has its pros and cons.
This article goes into great detail, and there are others. http://msdn.microsoft.com/en-us/magazine/cc948343.aspx
I need to create a web service to collect data from my customer’s applications.
Those applications are programmed with different technologies and they all have one thing in common: they can consume plain SOAP Web Service.
I already have a WCF Service that could be exposed but as it was built for internal purpose only, I never had to secure it.
I did read a lot of articles on how to secure WCF service and how to consume it from a Microsoft client application. However, I'm really concern about the customer’s non-microsoft applications abilities to implement a standard WCF Service security. I must keep in mind that some of them might be stateless and unable to hold on to a session or anything that might be required by a secure WCF Service.
So here are the options I have right now.
1) Add username/password parameters to each WCF function and perform a credential check on every call. (I do have an SSL certificate... is it enough to consider this option as secured?)
2) Drop my WCF Service and create a plain SOAP Web Service with username/password parameters as mentioned in option #1 to be closer to my customer’s applications capabilities.
3) Implement standard WCF security and let the customers find a way to deal with it on their own. (The real question here: is WCF security simple enough to be implemented by any SOAP client?)
4) Change my name and move to Jamaica with my customer’s money before they find out that I’m a Web Service security noob.
5) Something else…
So what is the my best option here?
Yes, I can offer the option we use. It sounds like you want basicHttpBinding.
We have a WCF web service using basicHttpBinding and set IIS to use basic http authentication.
Therefore non-.NET clients can consume it easily (basicHttpBinding) and we can give them an Active Directory domain account that allows them access via IIS. No usernames / passwords to constantly send back and forth through the web service and it runs over HTTPS for security.
It's currently being consumed by PHP, Java and .NET clients. Yes, .NET clients can still import this as a service reference which makes thing like trapping FaultExceptions easier.
No solution is perfect for everyone but works great for our needs.
Yes, but certain configurations favour certain vendors. See the WCF Express Interop Bindings project on CodePlex:
http://wcf.codeplex.com/wikipage?title=WCF%20Express%20Interop%20Bindings
They offer settings for interop with:
Oracle WebLogic
Oracle Metro
IBM WebSphere
Apache Axis2
The Oracle Metro (previously known as SUN WSIT) stack is by far the most advanced as regards the WS-*/Oasis standards.
I am starting a new webservice project which will be consumed by multiple consumer applications done in different technology like ASP, ASP.Net and PHP. I am planning to develop this service as a WCF service. I am new to WCF and I understand WCF is like umbrella tech which has all the features for developing a distributed SOA applications.
I would like to get your advice on whether my choice of opting WCF service over classic asmx service is correct. The consumer applications are existing application done different technologies as I said before. This service is a simple service that creates and updates user information in a centralized DB.
If my decision of choosing WCF is correct, then please let me know if there are any specific things I need to consider so that the existing application can consume my WCF service without any hiccups. In other words, I can provide a asmx service for this which they can consume directly without any issues (and currently they are consuming some of our asmx service. Since the current requirement is new I want it to be done with WCF). Likewise, the consumer should be able to consume my service like they consume asmx service.
I am asking this question because WCF provides additional features like security, etc. and hence the consumers should also follow the practice to communicate with the service.
Any advice is highly appreciated.
You probably want to use BasicHttpBinding in your WCF service and, although I'm not a PHP developer, I understand that PHP 5 has a SOAP library that can be used to create a service proxy based on the WSDL document exposed by the WCF service, assuming metadata exchange is enabled.
For my project's web services I want to support desktop clients and silverlight clients. Should I write a separate web service for each or put all the operations in one service? If I put them all in one, I have to go with basicHttpBinding. The winforms app uses wsHttpBinding now, what do I lose going with basicHttpBinding?
I very strongly recommend you read this thoroughly:
"Silverlight and WCF Feature Comparison"
http://msdn.microsoft.com/en-us/library/cc896571(VS.95).aspx
There are quite a few gotchas when developing a web service for silverlight usage, especially if you already have a wsHttpBinding solution. Good luck!
EDIT: also I found this article useful:
WCF : BasicHttpBinding compared to WSHttpBinding at SOAP packet level
http://geekswithblogs.net/claeyskurt/archive/2008/04/22/121508.aspx
Use one web service with two endpoints, that would allow you to support basicHttpBinding as well as wsHttpBinding.
The difference between the two bindings is that basic is Soap 1.1 whereas ws is Soap 1.2 and WS-Addressing Specifications, in addition wsHttpBinding offers more security options