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.
Related
I'm new to WCF and have very limited knowledge in WCF security. I have written an WCF service which should be exposed in internet for my clients. I need to Authenticate the clients to use my services. Clients should invoke my service with user id and password. I will do SSL certification as well but apart form that I need some authentication mechanism. Please advice me what binding,security mode, clientCredentialType and related configurations I should do for the security.
You can make use of WSHttpBinding for your services. The binding supports HTTPS transport and WS-Security. Along with this, you can also set security configuration at transport and message level. You can either specify that at ServiceContract or at OperationContract levels.
Here are few MSDN links to get you started:
Bindings and Security
WCF Security Fundamentals
Authentication with Transport Security
Please note that these may be very basic in comparison to your requirements.
It depends on what technology your clients use. If they are all .NET then you have free choice. If you have Java or other clients accessing your services you may have less headaches with BasicHttpBinding, which is completely adequate if you only need username authentication and SSL. The link #danish provided (http://msdn.microsoft.com/en-us/library/ff649647.aspx) shows you how to do that.
Here on MSDN as well as here states the when dealing with wsHttpBinding, Transport security is handled via SSL.
On the MSDN page about SSL and WCF it states that when a ServiceHost is hosted within IIS, the ServiceHost leaves the SSL to be handled by IIS.
Would this not imply that if binding/securityMode="Transport", that any wsHttpBinding/binding/security/transport/clientCredentialType values would be ignored as none of their options are needed to set up the SSL transport?
It even appears to to say something to this effect here when it states
"When setting the security mode to TransportWithMessageCredential, the
transport determines the actual mechanism that provides the
transport-level security. For example, the HTTP protocol uses Secure
Sockets Layer (SSL) over HTTP (HTTPS). Therefore, setting the
ClientCredentialType property of any transport security object (such
as HttpTransportSecurity) is ignored. In other words, you can only set
the ClientCredentialType of the message security object (for the
WSHttpBinding binding, the NonDualMessageSecurityOverHttp object)."
And yet here for basicHttpBinding and for wsHttpBinding, they both categorically emphasis with examples that if security mode is set to Transport, set the binding/transport/clientCredentialType to something (eg: Windows).
What's the exact difference between Transport and TransportWithMessageCredential?
And do I have the wrong end of the stick, and the SecurityType enum (None|Message|Transport|Mixed) is not just for privacy, but for authentication to the server?
If Transport security is provided by SSL encryption, how did Authentication/Authorization get tangled into this stage?
Thanks immensely for helping me get a better picture of how this all fits together.
As far as I know the TransportWithMessageCredential is kind of "best of both worlds". The channel is secured on the transport layer so there is a secure connection between client and service (which can be very fast, implemented in hardware), plus the message is signed with message credentials so it can survive multiple hops before arriving at the service (validated in WCF).
And of course, you can use message credentials which are not supported on the transport layer, username/password for example.
Here is WCF binding and security question I'm quite confused:
You are hosting a Windows Communication Foundation (WCF) service at
http://www.contoso.com for a law enforcement agency. The agency adds
operations to support sending biometric fingerprint data via
non-buffered streaming. The service data is routed between
intermediaries. The WCF binding you are using by default does not
support encryption. You need to ensure that the fingerprint data is
not disclosed when passed over the network. What should you do?
A. Use basicHttpBinding with message security to https:// www.contoso.com
B. Use basicHttpBinding with transport security to https:// www.contoso.com
C. Use wsHttpBinding with message security to https:// www.contoso.com
D. Use wsHttpBinding with transport security to http:// www.contoso.com
Answer is B. But I think here it says "The service data is routed between intermediaries", so message security should be favour over transport security. Well, it did say "The WCF binding you are using by default does not support encryption", but the options here do offer using wsHttpBinding, so I think both A and C will do. Can anyone tell what I'm wrong there?
This sentence in the question is the key:
The WCF binding you are using by default does not support encryption
So that means the question is implying you are using basicHttpBinding, since wsHttpBinding has WS*-Security enabled by default. You can actually inspect the calls via Fiddler. The messages are signed and encrypted using a security token by default - for the gory details - this explains the SPNEGO token that is cached on the service.
So that eliminates C, D because of the sentence I highlighted earlier.
That leaves A and B. I don't agree with B as MSDN itself states that Transport security only secures messages with the communication is point to point. If the message is routed to one or more SOAP intermediaries before reaching the ultimate receiver, the message itself is not protected once an intermediary reads it from the wire.
The question also clearly says:
The service data is routed between intermediaries
Therefore, I beleive the correct answer is A, some WCF experts on SO may correct me.
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.
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.