I'm developing a new set of web services at my company.
My manager asked me to provide a greater level of security for this, as the web services will handle sensitive informations.
I've searched the net for resources about how to secure an web service and the two runner ups are WSE3.0 and WCF.
But I have no idea which one is the best option to choose from.
My requirement stipulate that some of the web service must be called by non-.NET environment, so how to proceed?
Which one is the best in such scenario?
If you have the luxury of doing new development, DEFINITELY go with WCF!
It offers much more functionality, much more options for security, bindings, and way more extension points should you need to tweak your system.
WCF also support way more industry-standard interoperability scenarios than anything else before, so you should be more than covered in this area, too.
Here are a few articles specifically on WCF security:
Fundamentals of WCF Security
Programming WCF Security
WCF Security Guidance
No question here - it's a slam dunk - go with WCF !!
Marc
Related
I've very new at WCF, and I'm creating a prototype application to learn, which might turn into a commercial application. I understand the very basics of WCF, and I have my application WCF functional, at a basic level.
What are some tips experienced WCF users can give regarding pitfalls and steps I can take to make the app rock solid, at least regarding the WCF layer?
Couple of points to ponder:
make sure to implement rock-solid exception handling on your server side - implement the IErrorHandler interface on each service, define proper fault contracts
make sure to enable WCF tracing on the server side - those message logs are eminently useful when diagnosing problems!
make sure to think about versioning - make sure to use namespaces for both your service contracts and data contracts that will allow you to distinguish later version from the older ones (by means of the contract namespace)
think hard about your production hosting - IIS seems like a logical choice, but it's typically plagued by too many issues and problems that you don't have if you self-host. It's a bit more work yourself to create all those hosts - but it pays off with increased stability and better control on your side
Use security for your web service, particularly those bindings that support digital certificates.
Ensure your web service is interoperable with other web service frameworks, so that potential clients do not necessary need to be created using .NET and WCF.
Allow for endpoints (methods) to be retired in case they become obsolete. This allows clients of your web service to be informed of these retired endpoints so that they can be updated accordingly. Your retired endpoint could inform callers of what endpoint they should be using instead.
i am new to WCF but i learn this recently and thought to share with you.
if you are hosting your services on IIS then its best practice to make this a new account that you can control the direct privileges too, since NT AUTHORITY\NETWORK SERVICE
uses the default and can have a bit higher level of permissions. You can change this under the Application Pool in IIS that your website hosting WCF is running as.
my2cents
at my workplace we are about to start a big project. My boss (a programmer, this is a startup) wishes to use ASMX webservices for this purpose. I do not want to start off a new program using deprecated technology and would like to show him this. I dislike WCF at this moment because it has such an extreme learning curve, but I'd rather learn it than use an unsupported technology.
The problem I'm having is that I can not find any practical list of cons and downfalls when compared to WCF so that I can convince my boss to not use them. And saying "it's not as powerful" is not an adequate explanation. What exactly can it not do that we may need it to do for a webservice that is not meant to be shared externally? (as in, we don't support third-parties using our webservices unless they are using one of our clients. )
In short:
ASMX is
limited to only HTTP as its transport
limited to only being hosted in IIS (no other alternative)
limited to very simple security
limited to SOAP 1.1
WCF is
more flexible in transports: you can use HTTP, NetTCP, MSMQ, many more
can be hosted in IIS, WAS, or self-hosted in a Windows Service, in a console app, in a Winforms or WPF app
has much more security options
supports a plethora of WS-* standards
can interoperate with SOAP 1.1 and SOAP 1.2
In short: WCF is ASMX done right - much more flexible, much more powerful, much more in every respect.
Here's another quite useful comparison of WCF and ASMX: Comparing ASMX and WCF
and last but not least, WCF is also better in terms of performance, as this quite extensive MSDN article quite nicely shows (including performance numbers and graphs): A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies
I've never understood why some people think that WCF is difficult to learn. Try this: create a new WCF Service Project in Visual Studio. Now look at the code. Compare that with the same code you get from creating a new ASMX project. It's not very different.
I have three words for you: WCF. WCF. WCF.
Here are another three about why you should choose WCF: Power. Versatility. Configurability.
ASMX is great if you want to get a quick and dirty web service up and running, although to be honest it only takes maybe a few minutes more to do a WCF one.
The WS-* are really hard to implement with asmx: transactions, reliable messaging, security... etc etc.
And later the bindings: you can change the communication just by configuration, the asmx is just http.
WF exposing services and AppFabric works over wcf.
I would not have doubts, today wcf is the best option for starting a project that needs services.
I'm building a workflow app to investigate the technology. I can't decide whether to go for a web service (and a technology with which I'm basically familiar) with WebServiceInputActivity's or WCF and ReceiveActivity's (and a new technology that I'll have to learn).
Are there any major reasons to go either way?
Clarification:
Are there any major (architectural) reasons relating specifically to WF to go either way? I appreciate the input of the respondants, so far, but they focus on WCF rather than what the implications are for my workflow and its lifetime, maintainability, performance, expandability, etc. if I choose WebServices or WCF.
WF and WCF are very much hand in hand in .net 4. I'd definitely suggest the latter.
No doubt, it is WCF. Migrating ASP.NET Web Services to WCF
SUMMARY: Windows Communication
Foundation (WCF) provides a unified
framework for rapidly building
service-oriented applications that
makes it easy to build and consume
secure, reliable, and transacted Web
services. WCF’s single programming
model unifies the capabilities in
ASMX, WSE, Remoting, COM+, and MSMQ;
therefore developers need to learn
only one programming model.
Agree with the others here that you should go with WCF.
Just thought to add one more point, that just because you use WCF does not mean that you cannot access existing web services. You can use a WCF client with basichttpbinding, to access existing non WCF web services.
You are making a mistake to call ASMX web services "web services" and suggesting that WCF can't be used to make web services. A WCF service using basicHttpBinding is exactly like an old ASMX service.
The best reason to use WCF instead of ASMX is that Microsoft has now stated that ASMX is a "legacy technology", and that they will not be fixing bugs in it.
It's been a few years since I've done web services. I remember it to be fairly simply to create and consume one. In my current position, I work in a large organization and we use a lot of DB2 stored procedures the mainframe guy write for us to get at HR data.
I'm now starting on a new HR project and rather than having the same ol' data access code that is in most of our other HR apps, I suggested we write a code library DLL that did all this work and just use this DLL in our HR apps from here on out. Once I suggested this, my manager thinks this is a great idea, but he wants it done in web services.
My manager has now tasked me with researching options for securing these web services would be. He wants me to tell him if we should use WCF with this and if the Java developers in the organization will be able to use the web services I create.
I have done quite a few web searches and haven't found information that specifically answers these questions. Is there anyone here with experience in doing this and could answer the qeustions regarding the security, WCF (which I know little about), and interoperability with other platforms (Java)?
Thanks!
WCF is the current approach for building service end points in .NET apps. It's flexible in supporting different transport channels and protocols. You can certainly expose SOAP Web Services from WCF and use them from Java clients or anything else that supports XML.
The old way of doing that in .NET, simple ASMX Web services is deprecated in favor of WCF. It doesn't have all the bells and whistles of WCF but it's very simple to use. Personally, I still like it and use it in very simple Web services where WCF is an overkill.
As Mehrdad mentions (and I totally agree), WCF is the current offering my Microsoft for most cases.
ASMX is great and simple - but it's very limited in many ways:
you can only host your web services in IIS
you can only reach your web services over HTTP
security is very limited
WCF remedies this - and offer much more beyond that. You can host your WCF services in IIS - or self-host in a console app or Win NT Service, as need be. You can connect your WCF services using HTTP, TCP/IP, MSMQ, Peer-to-peer protocols, named pipes for on-machine communications and much more.
I'd definitely recommend you check out WCF and give it a spin. It's a tad more complex than ASMX, but it also offer just sooo much more capabilities and choices!
As for resoures: there's the MSDN WCF Developer Center which has everything from beginner's tutorials to articles and sample code.
Also, I would recommend you have a look at the Pluralsight screen casts on WCF - it's an excellent series going from "Creating your first WCF service" and "Creating your first WCF client" all the way to rather advanced topics. Aaron Skonnard very nicely explains everything in 10-15 minutes screencasts - highly recommended!
Recently I made the switch from using asmx web services to using wcf services, the transition is nearly finished, but I know I'm in for a lot of error checking and testing to make sure everything ported as expected.
My question is - so far I can only think of 1 good benefit to using wcf, and that is you get an easy way to implement a singleton web service.
Besides that I have to tell you, configuring a WCF Application seems way overly complicated, and I'll forever miss how easy it was to test asmx web services.
What other benefits are there to using WCF over ASMX web services?
more protocol options; ASMX is IIS and HTTP only - WCF gives you HTTP, NetTcp, MSMQ, IPC - you name it
you can write your service once, and expose it on multiple endpoints
self-hosting: you can host your WCF service in a console app, a Winforms app, a WPF app, or let it be handled by IIS/WAS - but you don't have to
a lot more options like reliable sessions, lot more security options
you don't have to deal with as much "plumbing goo" in WCF as you do in ASMX - you can concentrate on your business problem, and let the config and attributes handle all the gooey stuff you don't want to deal with
to name just a few.....
Search Google or Bing for "WCF vs ASMX" and I'm sure you'll find plenty more article, blog posts and comparisons.
ASMX has passed its time - WCF is the present and the future. It can do a lot more - therefore it's a bit more to learn.
But if you check out the right sources, like these two Dotnet Rocks TV shows (Keith Elder Demystifies WCF and Miguel Castro on Extreme WCF), I'm sure you'll get a quick and hopefully painless start into WCF!
Marc
WCF allows you detach service from the physical layout and protocols. For example, you can write one service and deploy it as either REST or SOAP, or whatever that may happen in the future. ASMX is great, but it's pretty much hardcoded to SOAP. Also the idea is that you can plug-in existing features like throttling just by changing preferences, which I haven't seen much benefit of.