load balancing WCF with wsHttpBinding and Message Security with client credentials type windows

Question

We have got a normal WCF service which has a binding that looks like this:

 <wsHttpBinding>
 <binding name="ServiceBinding" receiveTimeout="00:10:00" sendTimeout="00:10:00"
                bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
                maxReceivedMessageSize="20971520"
                messageEncoding="Mtom" textEncoding="utf-8" useDefaultWebProxy="true"
                allowCookies="false">                   
                <security mode="Message">
                      <message clientCredentialType="Windows" negotiateServiceCredential="true"
                        establishSecurityContext="false" />
                </security>
            </binding>
</wsHttpBinding>

this service sits in 2 servers behind a load balancer. As suggested here

http://msdn.microsoft.com/en-us/library/vstudio/hh273122(v=vs.100).aspx

I have set establishSecurityContext to false. When i run call the service i get intermittent issues related to invalid security context token. Even though i say not to establishSeurityContext it seems that WCF is doing all the normal handshake stuff.

At this point of time using Cert, BasicHttBinding or no security is not an option because of the requirement.

I have even got the infrastructure team to enable sticky sessions in the load balancer but nothing seems to work the way we expect it to.

Me and my team has done almost everything that has been said in the internet but nothing seems to work when there is a load balancer and this binding is working perfect when there is not load balancer.

Has any one got luck with this binding?

We are chasing Microsoft to send us the WCF expert but apparently folks are hard to get hold of.

How can i get this thing to work nicely with Load Balancer?

Ivan Samygin · Accepted Answer · 2014-08-03T19:07:14.077

You set negotiateServiceCredential="true". That means security context is created during initial exchange, but this context won't be used in subsequent calls (because of establishSecurityContext="false"). The negotiation process allows client to get server credentials safely. Then client uses these credentials to secure the message. That's why all "handshake stuff" happens.

This scenario is described in this article: "Message Security with a Windows Client".

The security negotiation is needed when you're using load balancer (because actual server's credentials depend on a machine that will serve request) unless you're using the same credentials for all service instances behind balancer. In the latter case you can set negotiateServiceCredential="false" and specify server credentials in config or code. For example, you can use clientCredentialType="Certificate" and use the same server certificate for all machines. Or you can clientCredentialType="Windows" and configure arbitrary SPN to a domain user, which is used to run all services behind balancer (I didn't try this scenario, see details below).

In your case negotiateServiceCredential="true". So possible issues are:

1) Sticky session may not work properly. You can test it by implementing simple WCF service with BasicHttBinding that returns

String.Format("{0}{1}", prefix, DateTime.Now);

Configure prefix="" in app settings on one server behind balancer and prefix="!!!!!!!!!!!!" on another. Then call this service in a loop many times and log results. You'll see if there's an issue with the sticky session.

2) If sticky session works correctly, ensure that your configuration works exactly for all servers when no balancing is used.

When you can't use sticky session, you should set negotiateServiceCredential="false". The negotiation is not used, so client should have server credentials are being configured explicitly in code or configuration. To use the Windows credential type without negotiation, the service's user account must have access to service principal name (SPN) that is registered with the Active Directory domain. See details and example in "Message Security with a Windows Client without Credential Negotiation"

To use arbitrary SPN you should configure your services to run under the same Windows domain account. To set arbitrary SPN to the account you can use setspn utility on a domain controller:

setspn a AcmeService/GlobalBank WS_Account

as described in Kerberos Technical Supplement for Windows

See also article about Message Security for description of various scenarios and corresponding settings.

We don't want to go for Kerberos authentication in this point of time, and my initial question was if Microsoft explicitly says enabling sticky session or disabling establish security context is the way to go for load balancing in their article why does it not work in real life? — Bravo11, Aug 03 '14 at 02:14
FYI...@Ivan i have tried basicHttpBinding without any problem but that is not where i want to go — Bravo11, Aug 03 '14 at 02:15
Yeah, I guess the following statement in the article is wrong: "If the establishSecurityContext property is set to false, the one-time initial step is not executed, and requests do not rely on an established session. This is the alternative to using sticky sessions.". negotiateServiceCredential is true by default so initial step is still executed. It could affect balancing. basicHttpBinding does not cause any problem because it does not imply any security by default (http://msdn.microsoft.com/en-us/library/system.servicemodel.basichttpsecuritymode(v=vs.110).aspx). No negotiation is happened. — Ivan Samygin, Aug 03 '14 at 11:33
I discover additional info about using Windows credentials and updated the answer. — Ivan Samygin, Aug 03 '14 at 17:16
Got Reply from microsoft saying exactly same thing as you are saying and asking to disable sticky session and try establishsecuritycontext to false and negotiateservicecredentials to false so i am accepting you answer. — Bravo11, Aug 05 '14 at 21:19
I want to try kerberos authentication would appreciate if you could redirect me to the right location — Bravo11, Aug 05 '14 at 21:24
All info is already in the answer. http://msdn.microsoft.com/en-us/library/ms735117(v=vs.110).aspx would give you a sample of message security with Kerberos (you can copy config). To generate SPN for service account use command I mentioned in the answer. Then use generated SPN in configuration in identity element (replace service_spn_name value of sample config). It should work. — Ivan Samygin, Aug 05 '14 at 23:20

Yaron Naveh · Answer 2 · 2014-08-04T09:49:42.090

As mentioned, one option is to turn off both negotiateServiceCredential and establishSecurityContext. This will result in a performance penalty, which may or may not be meaningful for your scenario. If this method does not work too it is possible that due to kerberos/ntlm there is no "one shot" authentication. I suggest to turn on Fiddler (or wcf logs) for just one user operation (one proxy call) and see if it also makes just one XML call to the server or does it require multiple calls for authentication.

Another option is to ensure all servers use the same account which was also mentioned by Ivan.

There is a third option where you make the servers stateless by using a stateless security context token. Just set:

requireSecurityContextCancellation=false

In this way all clients will send the cookie to the server each time so it does not matter which server they got. I know that with certificates security this means all servers must use the same certificates, not sure what is the implicaiton in windows security. Here is a full example:

http://msdn.microsoft.com/en-us/library/ms731814(v=vs.90).aspx

Creating a custom SecurityStateEncoder might also be relevant in some scenarios:

http://msdn.microsoft.com/en-us/library/system.servicemodel.security.secureconversationservicecredential.securitystateencoder.aspx

load balancing WCF with wsHttpBinding and Message Security with client credentials type windows

2 Answers2

Linked