Why is wsHttpBinding secure by default? How does it work?

Here's a detailed answer to a great question from my MSDN session today. 

Q1. In the WCF demo, I illustrated the “secure by default” nature of wsHttpBinding.  In order to illustrate this, we inspected the messages using Fiddler2 from a call using basicHttpBinding and  than a call using wsHttpBinding.  There are 4 messages that show up in Fiddler2 for the wsHttpBinding call.  We are not using certificates, rather Windows credentials.  How does process work exactly?

A1. (short version)By default wshttpbinding uses SPNEGO to bootstrap a SecurityContextToken that is cached on the Service.  Typically you will see the following log pattern in your traces: your method call, ISSUE for SCT, ISSUE for SPNEGO (can be multiple messages), exchange SCT and finally method secured with SCT key.

Answer (detailed - steps 1 through 3 below)

1. Client does a SP-Nego handshake first. This results in an SCT.

a. Client sends RST to Service. The RST is for an SP-Nego TokenType and contains an SP-Nego blob

b. Service sends back an RSTR back to the client with an SPNego blob

c. Client sends an RSTR again to Service (if needed)

d. Service responds with an RSTRC containing the final symmetric key wrapped as an SCT

NOTE: Steps (c) and (d) can occur as many times as needed. We’ve typically seen a total of 4 legs (2 from client and 2 from service)

2. Client acquires another SCT (for message level security) from the Service. This SCT has a longer lifetime, and represents the real session key between the client and the service

a. Client sends RST signed and encrypted with SCT (from 1)

b. Server sends RSTR containing SCT signed and encrypted with SCT (from 1)

NOTE: Unlike Step 1, this is only a single RST/RSTR leg.

By messages being signed and encrypted (in 2a), I mean that all addressing headers are signed, the body is signed and encrypted with this SCT.

3. Client calls the service method

a. Message is secured with the SCT (from 2). By secured, I mean the same as in the NOTE for (2) above.

b. Server secures the response with the same SCT. By secures, I mean all addressing headers are signed, and the body is signed and encrypted with the same SCT that came in the request

Q2. When using wsHttpBinding, using Windows Credentials, what is used for the encryption keys?   

A2. It will be a derivedkey from the SCT session key.

Q3. What is the identity node in the client app.config generated by svcutil.exe?  When I am not connected to a domain, an error is raised using the userPrincipalName service identity type.  The error is: “The Security Support Provider Interface (SSPI) negotiation failed."  A blog post by an MCS emp found here (http://blogs.msdn.com/ericjo/archive/2006/10/10/How-to-fix-a-SecurityNegotiationException.aspx) suggests we use the servicePrincipalName identity type. 

A3. The UPN requires access to AD to succeed, if you have NTLM allowed (and things are setup right) we will downgrade to NTLM. 

Regarding the SPN – By default, all system accounts (like Network Service, Local System, etc..) are mapped to an SPN of host/localhost, or even host/[machine-name]. If the service is WebHosted (under IIS), then it will run as a System account, in which case the SPN has to be specified. If the service is running under a user account, then a UPN needs to be specified.

Comments (2)

  1. Gary says:


    We have our web servers behind a load balancer (F5/BigIP). We are planning to use "WSHttpBinding" with "Windows" as "MessageClientCredentials" and "NTLM" or "Windows" as "TransportClientCredentials" . Do we have to turn the "sticky" session on  on the F5 device in the above scenario? Thanks!

Skip to main content