In Wcf client is not connecting to the host - wcf

The request message must be protected. This is required by an operation of the contract ('IMyNumericService','http://tempuri.org/'). The protection must be provided by the binding ('BasicHttpBinding','http://tempuri.org/').
when i am trying to connect to the host where i have registered my service , i am getting the above exception. But Host was working ,when i try to connect from client app it was showing above exception

On to client and service security in WCF. You can set the protection level of messages sent over the wire at the message, fault, operation and/or service level in WCF. There are three message ProtectionLevel property flavors to set as an attribute. This ensures that any endpoint used for the service will require this protection level as a minimum.
None
Plain text traveling over the wire.
Sign
The message is digitally signed.
Ensures no modification to the message.
The message is still plain text.
EncryptAndSign
Before signing, the message is encrypted.
Ensures no modification to the message and is scrambled.
If, for instance, the EchoService is set a ProtectionLevel of EncryptAndSign on the ServiceContract level, an endpoint with BasicHttpBinding would fail to start up. This is because BasicHttpBinding doesn’t support this protection level by default (it can be enabled).
[ServiceContract(ProtectionLevel = ProtectionLevel.EncryptAndSign)]
public interface IEchoService
{
[OperationContract(IsOneWay = true)]
void RegisterClient(Guid guid);
[FaultContract(typeof(EchoFault))]
[OperationContract]
EchoMessage Echo(EchoMessage message);
[OperationContract]
List<EchoMessage> GetAllEchos();
}
Using this protection level with a BasicHttpBinding endpoint results in an exception on the host.
System.InvalidOperationException: The request message must be protected. This is required by an operation of the contract [..]. The protection must be provided by the binding [..].
However if we change the endpoint binding to, for instance, wsHttpBinding, the service runs fine. This is because WsHttpBinding supports the EncryptAndSign protection level by default.

Related

WCF Routing Service with netTcpBinding

I am using the Wcf Routing Service with the netTcpBinding
I have a WCF Service named ServiceTwo exposing just only one netTcpBinding endpoint
I have a client application consuming the ServiceTwo
Then I have a routingService between them, the routing service has two endpoints, a basicHttpBinding and a netTcpBinding. The routing always use netTcpBinding to communicate with the ServerTwo.
I am using the full IIS 8.5, enabled Http Activation and Non Http Activation, already setup protocol "http, net.tcp" for the ServiceTwo and the routing service as well.
for these below scenarios, it works
if the client application client consumes the ServiceTwo directly, not go through the routing, using netTcpBinding -> it works fine
or the client application call the ServiceTwo through the routing using basicHttpBinding (the routing always use netTcpBinding to communicate with the ServerTwo) -> it also works fine.
But for the case client app using the netTcpBinding to connect to the routing (the routing always use netTcpBinding to communicate with the ServerTwo)
I just got an exception as below:
An unhandled exception of type
System.ServiceModel.CommunicationException' occurred in mscorlib.dll
Additional information: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:59.9659874'.
Could you please advise something I might miss and cause the error
Thank you very much.
Regards
This error occured for me, when my client was using SecurityMode.None, but not my Service. But I think the exception is rather general.
So I would advice you to re-check all values that set up your ServiceChannel incl. your Binding on Service & Client.
btw: this error occurs for me only in case the client sets a SecurityMode and the service does not! If it is vice-versa a more meaningful exception occurs. Namely: (ProtocolException - This could be due to mismatched bindings (for example security enabled on the client and not on the server))

Securing WCF Service

I'm trying to set up security on a WCF web service, using the ProtectionLevel attribute:
[ServiceContract(ProtectionLevel= ProtectionLevel.EncryptAndSign)]
This compiles, but Visual Studio throws exceptions when I try to update the service reference in another project (same solution).
System.InvalidOperationException: The
request message must be protected.
This is required by an operation of
the contract
('IStorageService','tempuri.org/';).
The protection must be provided by the
binding
('WSHttpBinding','tempuri.org/';).
What else do I need to set up to get this to work?
Your ServiceContract attribute is specifying that the service requires a secure channel for all operations, with both message signing (the message contains a digital signature which can prove that it hasn't been tampered with) and message encryption (the bytes of the message are encrypted when transmitted over the network).
Your client code (i.e. in the project which calls the service) must satisfy these requirements. If this project is using BasicHttpBinding with default settings, then the requirements of the service will not be satisfied (security is disabled by default for the BasicHttpBinding). If you configure the client project to use WsHttpBinding instead, with its default settings, the exception should go away (this binding has EncryptAndSign enabled by default).
The ProtectionLevel is a way for the developer to set the minimum level that a binding must comply with. When a service is deployed, the actual binding specified in configuration may or may not support the minimum level. For example, by default, the BasicHttpBinding class does not supply security (although it can be enabled). Therefore, using it with a contract that has any setting other than None will cause an exception to be thrown. see here

WCF netTcpBinding MaxReceivedMessageSize and Custom UsernamePasswordValidation

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.

Allow nonencrypted response from server using WCF

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.

WCF Routing Message Security

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?