I'm building a WCF Service that uses Custom Username/Password validation on netTcpBinding with message level security. I've been researching MaxReceivedMessageSize settings and I've got a query of a rather technical nature. I've noticed that when you specify a custom username validator that it gets called deep inside the plumbing of WCF (during handshaking I suppose).
If I have a relatively large MaxReceivedMessageSize of 1MB, will WCF read the entire message off the line and then do authentication, or will it first do the authentication and somehow discard the rest of the message?
The reason for my query is DoS attacks. I am hoping that due to the authentication the service would be immune to large message DoS attacks.
I believe that full message is loaded. The message is first processed by transport channel which doesn't have any information about message security. So the channel reads the whole message with using selected encoder and creates Message instance. This instance is passed to futher processing including message security checking. The only exception is when you use Streamed transfer mode. In that case only message headers are read in receiving channel and placed to buffer.
To prove this you can also turn message logging which is able to log messages on transport level and at service level. Transport level is message received from transport, service level is message received at service (after all security processing). So the message is already read at transport level.
Related
I have implemented message layer security using message inspector mechanism in a wcf service.
On the client side, in IClientMessageInspector.BeforeSendRequest I add an authentication header.
On the service side, in IDispatchMessageInspector.AfterReceiveRequest I inspect the authentication header in the message. If it is not found or as expected, I throw a SecurityException and try to log it to a database.
Here comes the interesting part. When logging to database, I try to read from this webservice again (this is web service which provides configuration info).
This is where the service stalls/deadlocks. I can see that the call to read configuration (when logging to db) is made, but I don't receive the call on the service. I keep getting a timedout exception every time.
After a little googling, I came across this post, which mentions that message inspectors are synchronous in nature. If that is so, how can I achieve what I am after?
I have a wcf service and handle a lot of client (server document generation). This service should receive a lot of request and should be handle in queue. It also have a callback. (callback will return successfully generated document). I am still using PIA and will implement OpenXML in the future.
Is it wcf msmq is the way to implement this?
Is there any samples might be related? Previously its running in local machine but now want to change it as a so called "Server generated"
WCF MSMQ doesn't support callback directly - it supports only one-way operations. But for example this article discuss how to add this support. With default configuration you can send message back to original sender but it is not a callback. To support responses every client will have to expose queue and pass address of its queue as part of the request to be able to receive the message from the service. More about responses in MSMQ is in MSDN magazine.
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'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.
I'm building some routing functionality between services. The original service and the service that does the routing have an identical configuration; both are using netTcpBinding with the following binding configuration:
netTcpBinding
security mode="Message"
message clientCredentialType="UserName"
The service behavior uses a AspNet Membership Provider and a client certificate we've installed on the machine.
When I switch off the message security it relays just fine but when it's switched on I get the following exception:
"The message could not be processed. This is most likely because the action 'http://foo/Whatever' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings*. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding." (Emphasis mine)
My thinking is that the certificate is operating on the message twice (once on the original call and then on the relay) and this is what corrupts the message's security token.
Questions:
Is my thinking on target?
Is there a way to continue to use message security for routing without having the complexity of a token service?
You mentioned switching between no security and message security. Are you making sure to change both the WCF service endpoints as well as the endpoint on the receiving end? If not, and the two do not match up, you will receive an error. That's what that error seems to be saying to me.
For Question 2, what type of environment are you running in? A closed system where you could use encrypt and sign, or a public environment, where you might need to be using a special key?