By default there is no data security in basicHttpBinding, so how to check it ?
we want to check that by default in basicHttpBinding when client gets response from wcf then data travel in plain text not in encrypted form. Actully we have implement some security on it so we also then check data communication in both scenario (default behavior and with security)
Use a tool such as fiddler to analyze the messages sent by HTTP from the client machine
Related
I have a WCF service hosted in IIS. The service is mandated to be basicHttpBinding. There is IBM DataPower in front of the WCF service that exposes it to outside world.
I am writing a WCF client app (inheriting from ClientBase) that has to encrypt the message body using a pre-shared public key and DataPower will decrypt it and forward the message to the hosting server. As for responses, DataPower will encrypt it and the client should be able to decrypt the responses received. One way to achieve this (that I could think of) is using IClientMessageInspector and use the BeforeSendRequest() to encrypt AfterReceiveReply() to decrypt. Before going this route, I wanted to know what other options are available to achieve this?
Usually the pattern is to use SSL which is easy to work with in DataPower and WCF clients. I'm not sure how easy it is to configure message level encryption in DataPower. If you insist on message level encryption first check if DP dsupports the standard WS-Security approach, in which case configuring the WCF client is easy (basic http binding with security mode of message and client credential type of certificate or username, but of course depend if you want to configure client auth).
Yes datapower supports WS-Security standard and you can play around any part or whole of messages for encryption/decryption. The only thing you need to weight here is whether to use PKI or symmetric encryption/decryption technique while playing with message level security.
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.
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.
I have a WCF service which would like to support basicHttpBinding and webHttpBinding. When the client successfully login, server will generate a token for client to pass to server on all the request make later. Question is how the client can pass the token to server? I don't want to add an extra parameter on every web method to hold the token.
Typically, the best way to do something like this is passing such "meta-information" in a WCF header. You can easily create a message inspector to extend WCF (it's really not that scary and hard to do!) which would inject the token into every outgoing request from the client, and retrieve it from the header and validate it on the server side.
There are a number of pretty good blog post out there showing you how to create a message inspector:
Richard Hallgren's WCF postings
Writing a WCF message inspector
Automatic Culture Flowing with WCF by using Custom Behaviour
Check out the two relevant interfaces to implement:
IClientMessageInspector on the client side, which has a BeforeSendRequest and AfterReceiveReply message to implement
IDispatchMessageInspector on the server side, which has a AfterReceiveRequest and BeforeSendReply method to implement
I'm connecting to a webservice using WCF. I can authenticate on the server correctly, send my request, and get a signed response back.
The only thing is that the body of the response isn't encrypted. Ok, I'm fine with that. It's not my service and not my call how they do things, I'm just writing a client.
The issue is that WCF keeps giving me a MessageSecurityException stating that the'Body' required part of the response message wasn't encrypted. Where in my app.config can I specify that I couldn't give two flying craps that it isn't encrypted and it should be let through and read?
For the record, I'm using customBinding.
The protection level (which defaults to "EncryptAndSign" in WCF) is set on the service contract, e.g. your interface that defines the service methods:
[ServiceContract(Name="YourServiceContract",
Namespace="http://www.yourdomain.com/2009/09/WCF",
ProtectionLevel=ProtectionLevel.None)]
public interface IYourService
{
string SayHello(string inputString);
}
You can set it to "ProtectionLevel.EncryptAndSign" (which is the default), "Sign" or "None".
However, you cannot set it to be one thing for the request and another for the response - the protection level applies to both directions of your WCF communication.
Check out the Fundamentals of WCF Security which explains these topics (this one in particular on page 2).
Marc
There is a way to send a secured message and permit the response to be unsecured. However it requires a hotfix you need to request from Microsoft technical support. This has saved me when workign with a goverment service that required recured requests but send unsecured faults back. See here for more information on the hotfix.