I'm using netTcpBinding with "Transport" security ("Windows" credentials & "EncryptAndSign" protection).
I already know that Kerberos (after SPNEGO) is used to authenticate client & server (both machines on the same Windows domain).
I'd like to know what is/are the algorythm(s) used then to encrypt and sign the TCP Transport channel since there is no config choice ("Message" security has "algorithmSuite" config parameter but it's not available for "Transport" security)
Thanks
The NetTcpBinding class uses TCP for message transport. Security for the transport mode is provided by implementing Transport Layer Security (TLS) over TCP. The TLS implementation is provided by the operating system.
You can also specify the client's credential type by setting the ClientCredentialType property of the TcpTransportSecurity class to one of the TcpClientCredentialType values, as shown in the following code.
C#
NetTcpBinding b = new NetTcpBinding();
b.Security.Mode = SecurityMode.Transport;
b.Security.Transport.ClientCredentialType =
TcpClientCredentialType.Certificate;
More info can be found here: http://msdn.microsoft.com/en-us/library/ms729700
Hope that helps.
Related
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.
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.
Is it possible to host a WCF service in IIS, access it over HTTP and have the message body encrypted using a wsHttpBinding configuration?
Yes, any protocol that can support message security and the WS-Security standard will be capable of encrypting your messages - it's actually the default setting, too.
See Message Security in WCF for more information, and for hints about how to secure your messages using a Windows credential or a X.509 certificate as the "shared secret" between client and server to ensure encryption.
Yes.
Check this page from MSDN on how to configure your bindings to do what you need:
MSDN - Web Service Protocols Supported by System-Provided Interoperability Bindings
any insights are helpful
A good explanation can be found on the .NET Development Forum:
[I]t is not true that you have to
enable anonymous in order to host WCF
in IIS. There are some restrictions
when you configure bindings though.
The basic principle is that: the
settings for the WCF binding should be
compatible with IIS settings. This
means that if you want to enable
transport layer authentication in the
binding, you have to do so to the
virtual application in IIS. For
example, when you use
BasicHttpBinding, you can enable the
transport layer auth by setting the
security Mode to
"TransportCredentialOnly". You can
disable IIS anonymous auth in this
case.
However, there is one special case: if
you are using WSHttpBinding over HTTP
instead of HTTPS, you would have to
enable anonymous in IIS. This is
because none of the security modes for
WSHttpBinding allows you to configure
transport-layer authentication over
HTTP, which has been implemented in
BasicHttpBinding. Of course, you can
solve this by using either
BasicHttpBinding or CustomBinding.
This is not a limitation. Instead it
tries to reduce confusion since you
would use either SSL (as transport
layer security) or message security
with WSHttpBinding.
In one of our networks we are utilizing the netTCPBinding. The WCF service hosted in windows service that run as a domain account.
From the event viewer I can see that my WCF service uses Kerberos authentication. Everything works seamlessly "out-of-the-box" with simple default configuration without an <identity> element in the configuration file and without any SPN setting for the machine like:
setspn -a WcfServiceName//Server domaonAccount
But from the multiple online references I concluded that SPN setting is necessary
Its not clear, why in my case it works without those settings?
Looking forward for an explanation from WCF-Security experts.
Per the WCF Security Guidance:
netTcpBinding : Specifies a secure, reliable, optimized binding suitable for
cross-machine communication. By default, it generates a runtime
communication stack with transport security and
Windows authentication as default security settings. It uses
TCP protocol for message delivery, and binary message
encoding.
In essence, its secure by default, callers must provide Windows creds for authentication.