Zulfiqar's weblog

Architecture, security & random .Net

Message security knobs

Posted by zamd on February 11, 2008

Security in WCF is all about credentials. Credentials are used for authentication; claims extracted from the credentials are used for authorization. If credential contains keys then these are used to provide integrity and confidentiality. 

Credentials are supported both at transport level and message level. For message level credentials, WS-Security specification defines the mechanism to encapsulate security token (serialized representation of credentials) in a SOAP message. 

When you use message security with WCF there are couple of interesting knobs which I am going to explain in this post. So let’s consider the following snippet as an example. 

<message clientCredentialType=UserName 




·         establishSecurityContext 

Setting establishSecurityContext=false results in one shot message security. In this mode every message is secured independently — algorithm suits determines what algorithm should be used to secure the message. By default WCF uses RSA-OAEP, which uses a symmetric key to encrypt the message and signature. This symmetric key is then wrapped/transported using the public key from the server certificate. All of this security stuff is contained in every SOAP message. 

With one shot message security there are further two options: 

o   Not using derived keys 

Above explanation was for case in which derived keys were turned off. Some of the other stacks (e.g IBM DataPower) don’t support derived keys yet so in those cases this needs to be turned off. By default wsHttpBinding uses the derived keys and there is no way to turn this off from the config file. You have to use a custom binding, if you need to turn off derived keys. See this for details. By default “derived keys” are turned off in case of basicHttpBinding. 

o   Using derived keys 

With derived keys turned on, WCF derives two keys from the symmetric key and use one to sign the SOAP message and other to encrypt various parts of the SOAP message. It is considered bad practice to sign and encrypt data using the same key as certain attacks are more likely to succeed in this case so derived keys provide more resilient against such attacks and that’s why its enabled on wsHttpBinding as a default option. 

Setting establishSecurityContext=true results in a “Security Context Token” established between client and server. Once this token is created on both ends – all subsequent message exchanges will be secured using this context token. By default this token is issued with a 15 minute life time and need to be re-issued if required beyond 15 minutes. Again not using derived keys here means multiple messages (exchanged in 15 minutes life-span) will be secured using the same “Security Context Token” so security in this case will be more weaker than one shot security. So use of derived keys is more important in case of secure conversation. 

·         negotiateServiceCredential 

Credential negotiation is a process of exchanging keys and authenticating communicating parties using some form of handshake. Now credential negotiate can be done at the transport level using something like SSL over HTTPS or can be done at SOAP level using TLSNego (SSL over SOAP). 

Setting negotiateServiceCredential=falsemeans that service credentials should be made available to the client using some out-of-band mechanism. Here starts the complexity as WCF supports many different types of credentials and out-of-band availability mechanism is credential specific. 

So in case of Certificate credentials, service certificate should be provided to all the clients prior to communication and clients should refer the service certificate in their security configuration. 



    <defaultCertificate findValue=localhost 

      storeLocation=LocalMachine storeName=My 


    <authentication certificateValidationMode=PeerOrChainTrust /> 



In case of Kerberos credentials, setting negotiateServiceCredential=false results in on-shot Kerberos or sometimes called Kerberos direct. For this mode to work the service must be running under machine SPN (NetworkService, LocalService accounts etc) and client must specify the SPN in the endpoint identity. 

<endpoint address=http://zamd.net/servicemodelsamples/service.svc 




          contract=Microsoft.ServiceModel.Samples.ICalculator > 


    <servicePrincipalName value=host/zamd.net/> 



Setting negotiateServiceCredential=true will results in credentials negotiation. Now as mentioned earlier actual negotiation depends on client and service credential type and could either be done at transport level or message level (using appropriate credential exchange protocols) depending on your security mode. Let’s take this example: 


  <binding name=Binding1> 

    <security mode=Message> 

      <message clientCredentialType=UserName negotiateServiceCredential=true/> 




The above binding will result in UserNameForSslNegotiated credential type — which uses UserName as client credential type and certificate as service credential and service credentials will be negotiated using SSL over SOAP aka TLSNEGO. 

6 Responses to “Message security knobs”

  1. Nupur Bakshi said

    Hello Sir,
    I am developing a project based on WCF Message Based security with UserNamePassword Client Credentials and Binding used is wsHttpBinding.Everything is working fine but I want to tell you that I have taken 2 buttons on the interface.Both buttons are calling different methods of same service.In one button I have passed Client Credentials the and in another one I simply created an instance to call the method.When I click on the button in which Client credentials are passed it calls the method after authenticating the client but when I click on the button in which only instance is created it throws an error “UserName is not provided.Specify UserName in Client Credentials”.I don’t want to re-authenticate the client on every call of the method.If I am doing wrong provide me the full guidance on how to implement it and do take into consideration that I am new in WCF so provide me the step by step and complete help.Thanks

  2. The comment that IBM’s Websphere DataPower SOA Appliances do not support derived keys with WS-Security Policy is inaccurate. Not to say that there aren’t interop issues with the default configuration of both WCF and SOA Appliances, but nothing that can’t be worked around.

    DataPower SOA Appliances do support a Kerberos based WS-Security Policy interop but do not support the wsHttpBinding out of the box due to the following.

    The interop issues are specifically with signing using a Derived Key. The maximum key length specified by WS-Security Policy for Derived Key Signing is 24 bytes and currently in the SOA Appliances’s WS-Security Policy framework that information is not passed to the signing operation, and thus the signing action will use the default [aka 32 bytes]. Clearly this is a defect with the IBM product that is being addressed in a future release of the SOA Appliance firmware. In the mean time there is a very simple workaround, which is to drop an explicit *Sign* action on the response’s user rule to override DataPower’s WS-Security Policy *Sign* behavior.

    IBM and Microsoft share many customer that are using their respective WS-Security Policy implementations with great success. This includes the DataPower SOA Appliance products as well as the rest of the Websphere family. We continue to work closely to make this integration more consumable as the standard matures and becomes mainstream amongst customers.

    Corey Scobie
    Technical Executive – Websphere DataPower SOA Appliances
    IBM Corporation

  3. Unknown said

    Thanks for the insight.

  4. Unknown said

    You don’t happen to know if there’s a knob allowing the use of a custom security token for a service credential do you? I’ve been looking and haven’t found one yet.

  5. zamd said

    There is no knob rather you have to extend Message security framework to support custom security token.
    See this for an example of such custom security token.

  6. Unknown said

    Doesn’t help, I’ve got a custom token written and can use it as a client credential. My problem is that I want to use it as the server credential as well and I can’t find any way to configure that. I keep getting a "Token type not accepted due to security policy" error and have been unable to determine where that policy is being set.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: