Invalid security context token when using Load Balanced WCF (AWS)
I have a WCF application hosted on AWS. To make it more accessible, I took a snapshot of the WCF machine and started another instance with that image.
Also, I have created an elastic load balance (ELB) that routes requests to these 2 servers.
With my WCF client, I can successfully connect to both servers if I use the public IP of the device. But if I use the ELB hostname my connection fails with the following error:
System.ServiceModel.FaultException: The message could not be processed. This is most likely because the action ' http://tempuri.org/IService/GetCustomerData ' is incorrect, or because the message contains an invalid security context token or expired, or because there is a mismatch between the bindings. The security context token will be invalid if the service terminated the channel due to passivity. To prevent the service from interrupting idle sessions prematurely, increase the receive timeout on the service endpoint binding.
The error indicates that I have an invalid token or has expired. So, I checked the send and receive timeout and it is already set to 10 minutes : sendTimeout="00:10:00"
, receiveTimeout="00:10:00"
(requests usually take 5-15 seconds)
My bid configuration:
<bindings>
<wsHttpBinding>
<binding name="wsHttpBinding" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" useDefaultWebProxy="true">
<reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false" />
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="Basic"/>
<message clientCredentialType="UserName"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
Also, I double checked:
- ELB and Devices Firewall is open on ports 80 and 443.
- My ELB was configured with the correct certificate and has a listener on port 443.
- I have an IIS web server on both machines. If I use ELB address everything works.
- If the ELB is directed to one machine, WCF works. If routes are up to two machines, WCF doesn't work.
source to share
I managed to solve this problem by adding the following: establishSecurityContext="false"
.
<bindings>
<wsHttpBinding>
<binding name="wsHttpBinding" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" useDefaultWebProxy="true">
<reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false" />
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="Basic"/>
<message clientCredentialType="UserName"
establishSecurityContext="false"/> <!-- this line -->
</security>
</binding>
</wsHttpBinding>
</bindings>
Google, I found out that:
If this value is set to false , key exchange and validation must be performed for each call using asymmetric encryption. The default value for this parameter is true , which means that the first call will create a security context with asymmetric encryption, but it will be cached, and further calls will only use symmetric encryption, which is faster.
Performance Rating: Yaron Naveh
When the client is expected to make many calls in a row, it is better to set this parameter to true BUT with load balancing, calls are redirected to different servers and this message is interrupted due to an invalid token . Therefore, you must disable this security context feature.
Detailed explanation in the section "Defining the security context": https://msdn.microsoft.com/en-us/library/hh273122(v=vs.100).aspx
source to share
Based on your claim that you have the correct certificate installed on the ELB, I am assuming you are using SSL offloading. This can be a problem as the client binding needs to be configured using transport security, but the service will receive the request on port 80, so this requires a different binding configuration.
However, WCF requires transport security when specifying client credentials, so you may need to disable SSL offloading if you need to send client credentials.
source to share