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.
Related
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 have an IIS-hosted WCF service which is configured to use basicHttpBinding with transport security.
I have configured IIS with a certificate and I'm using an https endpoint to call the service.
Now, I have enabled message logging on the service at transport level - however, the messages I'm seeing are in clear text. Is this right? If so, why? Is there a way to see the encrypted messages?
Thank you in advance,
Fabio
This is correct behavior. Transport layer handles its decryption before it passes message to upper layer api like WCF so WCF always get message decrypted and it can't intercept the process - transport security is outside of WCF. Encrypted message on transport layer is logged only if you use message security because in such case transport layer just passes the message as is to WCF to deal with it.
Use Fiddler and don't enable SSL decryption in the options. It will allow you to inspect the message traffic as it is on the wire.
Also, worth reading is Debugging Localhost Traffic with Fiddler, a common gotcha for those new to Fiddler. Then check out the info page on HTTPS decryption, if you're interested in using that feature later.
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.
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.