I want to update client data with server data and vice-versa. Currently i am using BasicHttpBinding which is faster than wsHttpBinding.
My requirnment is to achive:
Fast data communication
Secure communication
Two binding is suitable in this scenario BasicHttpBinding and wsHttpBinding.
So which Binding should i use ? and What is the difference between BasicHttp and wsHttp binding ?
If you need security, use wsHttpBinding. It implements all the various security features, like message or transport security, client credentials provided as Windows credentials, username/password, or certificate. It supports reliable messaging and a lot more - a whole slew of the WS* standards.
BasicHttpBinding is just that - very very basic. It's more or less ASMX web services - pretty much no settings, no security (other than being routed over HTTPS).
If you need fast, use netTcpBinding - but that doesn't work well over internet connections. If that doesn't work, use basicHttpBinding - it's faster, leaner, less overhead than wsHttpBinding.
So you're back to the classic trade-off: you can have fast or secure - pick one. There's no "magic" way of having both at the same time - security does add overhead and thus slows things down. What is more important to you: secure communications, or fast communications??
wsHTttpBinding implemenets the WS-Security standard for web services communication, however, I believe HTTPS will provide you with sufficient security if you use basicHttpBinding.
You should also keep in mind that wsHttpBinding restricts your interoperability, as wsHttpBinding is only compatible with clients that support WS-* (SOAP 1.2).
In my opinion, I would stick with basicHttpBinding unless there are specific WS-* standard features that you need. In terms of WS-Security, the features it comes with is things like message level encryption (beyond the transport level encryption that HTTPS provides). To me, transport encryption ensures your message is encrypted when transmitted over the wire, the only benefit of having message level encryption is not wanting the overhead of using transport level security, but just wanting lighter weight encryption in specific areas of the message.
Here's a list of WS specifications from wikipedia for your information:
http://en.wikipedia.org/wiki/List_of_Web_service_specifications
Usually we recommend a fast secure transport like SSL for security. This is because any kind of message level security is CPU intensive in encryption/signing.
SO you can just use basic http binding with transport security for most scenarios without too much of trade off in perf.
If you aren't using any of the richer WS* protocols or sessions etc then you can stick with basic http binding.
Related
I have the following criteria to help me pick a WCF Http binding. My services need to:
be deployed in an intranet support impersonation/delegation
be interoperable with clients using unknown technology
support transaction flow between client and servers
not use certificates if possible (discards "Transport" security mode)
We need to decide between basicHttpBinding and wsHttpBinding.
Here are a few notes and questions on the three points:
I believe wsHttpBinding with "Message" security mode and "Windows" clientCredentialType would allow me to perform delegation.
The security configuration selected in point 1. to implement delegation does seem to make interoperability complex to support, am I right? The WS-* standards (wsHttpBinding) are definitely interoperable, but combined with "Message" security and "Windows" credential, could any WS-* compatible client invoke my services?
I believe wsHttpBinding seems the way to go here to support transaction flow?
Using "Message" security without certificates seems simpler in our situation?
Thanks in advance
If you want to support transaction flow, you need to use the wsHttpBinding. basicHttpBinding is really just that, a basic XML web service. MS claims it supports the WS-I Basic Profile v1.1 but it looks more like v1.2 since you can use MTOM with that binding.
Both are highly interoperable: wsHttpBinding is an implementation of numerous WS-* standards; what it doesn't support are older SOAP-only clients. That includes anyone using a .NET 2.0 style web service reference, and many forms of Java-based SOAP proxy.
With security, you start to get more of the benefits of a wsHttpBinding showing up. The basicHttpBinding cannot do Windows credentials, though, as you noted, that will limit your interoperability. I suspect you will find it very difficult to authentication non-Windows clients using Windows credentials, but as you indicated, that's the only way to get impersonation to happen. For non-WCF clients running on Windows, you may have more luck, since the client could still get access to the logged-in user's authentication token.
The best way to see how your security modes are going to affect non-WCF clients is to publish the bindings for your service and run the Java wsimport tool against them; if that can produce a working proxy from your WSDL then you should be able to use the service from any client.
If my Wcf Service and Web Application, both are in same server and if i want to access my web app over internet means which WCF security i have to use and why ?
Please advise me :)
Thanks
Kishore
It depends on binding and the context usage and not on transactions which is a different topic.
The intranet bindings (NetTcpBinding, NetNamedPipeBinding, and NetMsmqBinding) all
default to Transport security. Thus, no special programming is required on behalf of
the service or client developer. The reason is that on the intranet calls are typically
point-to-point, and Transport security yields the best performance. However, the intranet
bindings can also be configured for the None transfer mode; that is, they can be
used on the same transport protocol, only without security. The NetNamedPipeBinding
supports only None and Transport security—there is no sense in using Message security
over IPC, since with IPC there is always exactly one hop from the client to the
service. Also note that only the NetMsmqBinding supports the Both mode.
The Internet bindings all default to Message security, to enable them to be used over
nonsecure transports (that is, HTTP) and to accommodate multiple hops and
intermediaries.
As the name states... right now I'm using BasicHttpBinding, but I'm wondering if I can switch to WSHttpBinding and still be interoperable with, for example, Java.
wsHttpBinding and the newer ws2007HttpBinding both implement WS-* standards. You may have to configure the details so that they interoperate with your specific clients.
WSHttpBinding offers a lot of interoperable features but in the same time it by default uses message security with Windows authentication, service credentials negotiation over SPNego protocol and security context (WS-SecureConversation). Windows authentication and SPNego are not good candidates for interoperability and secure conversation doesn't have to be provided by older SOAP stacks.
So the answer is "it depends". You usually have to configure WSHttpBinding to be interoperable with Java. Moreover you don't have "full" control over used protocols (especially for security part) so sometimes you will use custom binding for interoperability.
What is the strength of the default TCP transport security using WCF netTCPBinding? Is it HIPAA compliant and where is documentation stating this?
HIPAA compliance only says what, not how. HIPAA requires you to prevent the data from being read in transit. It must be encrypted in some way that makes it non-trivial to decrypt.
From the HHS web site (http://www.hhs.gov/ocr/privacy/hipaa/understanding/srsummary.html):
Transmission Security. A covered
entity must implement technical
security measures that guard against
unauthorized access to e-PHI that is
being transmitted over an electronic
network.
The safest bet is to use the maximum security that the netTCP binding offers, which is SSL over TCP and message authentication:
NetTcpBinding binding = new NetTcpBinding();
binding.Security.Mode = SecurityMode.TransportWithMessageCredential;
You'll want to review the guidance on MSDN about Transport and Message security. There are also many great posts here on SO about configuring security with the netTCP binding.
Be sure to check with your legal department on your company's particular rules on transmitting e-PHI.
To answer your question, when configured correctly, the netTCP binding can securely encrypt traffic, which can meet the Transmission Security requirement.
netTCPBinding is an appropriate system-provided choice for communicating over an Intranet. The default configuration for the NetTcpBinding is faster than the configuration provided by the Htpp bindings.
On another note, I am not sure whether it is HIPAA compliant or not.
I'm starting this Wiki to collect best practices about creating interoperable web services (not clients) in WCF. Please share your experience if you know any feature which is not generally interoperable or which is not interoperable with specific platform.
Fairly simple:
avoid any .NET specifics like Exceptions (turn them into SOAP faults)
don't use any binding that start with net like netTcp, netNamedPipes, netMsmq and so forth - use wsHttpBinding for secure WS-* services, and basicHttpBinding for maximum reach / compatibility with even the weirdest client platforms
don't use the NetDataContractSerializer
I recommend WCF REST exposing multiple serialization formats, definitely xml for starters.
General interoperability:
Only HTTP and HTTPS transport channels are interoperable
Negotiation of security credentials is not interoperable (negotiateServiceCredential in message security). It uses TLSNego or SPNego protocols which are not always supported by other platforms.
HTTP streaming can cause troubles as well
Binary encoding over HTTP channel is not interoperable
OleTransactions are not interoperable
Use service security context with care (estabilishSecurityContext in message security). It uses WS-Secure Conversation protocol which is not available on some platforms
Edit:
WSDualHttpBinding and CompositeDuplexBindingElement are not interoperable