This documentation is archived and is not being maintained.

<security> of <customBinding>

Specifies the security options for a custom binding.

   <issuedTokenParameters />
   <localClientSettings />
   <localServiceSettings />
   <secureConversationBootstrap />

The following sections describe attributes, child elements, and parent elements


Attribute Description


Optional. A Boolean value that specifies if a serialized token can be used on reply. The default value is false. When using a dual binding, the setting defaults to true and any setting made will be ignored.


Optional. Specifies the authentication mode used between the initiator and the responder. See below for all values.

The default is sspiNegotiated.


Optional. Sets the message encryption and key-wrap algorithms. The algorithms and the key sizes are determined by the SecurityAlgorithmSuite class. These algorithms map to those specified in the Security Policy Language (WS-SecurityPolicy) specification.

Possible values are shown below. The default value is Basic256.

This attribute is used when working with a different platform that opts for a set of algorithms different than the default. You should be aware of the strengths and weaknesses of the relevant algorithms when making modifications to this setting. This attribute is of type SecurityAlgorithmSuite.


A Boolean value that specifies whether time stamps are included in each message. The default is true.


Specifies the way that keys for securing messages are computed. Keys can be based on the client key material only, on the service key material only or a combination of both. Valid values are

  • ClientEntropy: The session key is based on key data provided by the client.

  • ServerEntropy: The session key is based on key data provided by the server.

  • CombinedEntropy: The session key is based on the key data provided by the client and service.

The default is CombinedEntropy.

This attribute is of type SecurityKeyEntropyMode.


Sets the order in which message level security algorithms are applied to the message. Valid values include the following:

  • SignBeforeEncrypt: Sign first, then encrypt.

  • SignBeforeEncryptAndEncryptSignature: Sign first, encrypt, then encrypt the signature.

  • EncryptBeforeSign: Encrypt first, then sign.

The default value depends upon the version of WS-Security being used. The default value is SignBeforeEncryptAndEncryptSignature when using WS-Security 1.1. The default value is SignBeforeEncrypt when using WS-Security 1.0.

This attribute is of type MessageProtectionOrder.


Optional. Sets the version of WS-Security that is used. Valid values include the following:

  • WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11

  • WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10

  • WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10

The default is WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11 and can be expressed in the XML as simply Default. This attribute is of type MessageSecurityVersion.


A Boolean value that specifies if keys can be derived from the original proof keys. The default is true.


Optional. A Boolean value that specifies if security context should be cancelled and terminated when it is no longer needed. The default is true.


Optional. A Boolean value that specifies whether WS-Security signature confirmation is enabled. When set to true, message signatures are confirmed by the responder. When the custom binding is configured for mutual certificates or it is configured to use issued tokens (WSS 1.1 bindings) this attribute defaults to true. Otherwise, the default is false.

Signature confirmation is used to confirm that the service is responding in full awareness of a request.


Optional. Specifies the ordering of the elements in security header. Valid values are

  • Strict: Items are added to the security header according to the general principle of “declare before use”.

  • Lax: Items are added to the security header in any order that confirms to WSS: SOAP Message security.

  • LaxWithTimestampFirst: Items are added to the security header in any order that confirms to WSS: SOAP Message security except that the first element in the security header must be a wsse:Timestamp element.

  • LaxWithTimestampLast: Items are added to the security header in any order that confirms to WSS: SOAP Message security except that the last element in the security header must be a wsse:Timestamp element.

The default is Strict.

This element is of type SecurityHeaderLayout.

Child Elements

Element Description


Specifies a current issued token. This element is of type IssuedTokenParametersElement.

<localClientSettings> element

Specifies the security settings of a local client for this binding. This element is of type LocalClientSecuritySettingsElement.

<localServiceSettings> element

Specifies the security settings of a local service for this binding. This element is of type LocalServiceSecuritySettingsElement.


Specifies the default values used for initiating a secure conversation service.

Parent Elements

Element Description


Defines all binding capabilities of the custom binding.

The following example demonstrates how to configure security using a custom binding. It shows how to use a custom binding to enable message-level security together with a secure transport. This is useful when a secure transport is required to transmit the messages between client and service and simultaneously the messages must be secure on the message level. This configuration is not supported by system-provided bindings.

The service configuration defines a custom binding that supports TCP communication protected using TLS/SSL protocol, and Windows message security. The custom binding uses a service certificate to authenticate the service on the transport level and to protect the messages during the transmission between client and service. This is accomplished by the <sslStreamSecurity> binding element. The service's certificate is configured using a service behavior.

Additionally, the custom binding uses message security with Windows credential type - this is the default credential type. This is accomplished by the <security> of <customBinding> binding element. Both client and service are authenticated using message-level security if Kerberos authentication mechanism is available. If the Kerberos authentication mechanism is not available, NTLM authentication is used. NTLM authenticates the client to the service but does not authenticate service to the client. The <security> of <customBinding> binding element is configured to use SecureConversation authenticationType, which results in the creation of a security session on both the client and the service. This is required to enable the service's duplex contract to work. For more information on running this example, see Custom Binding Security.

            <!-- use following base address -->
            <add baseAddress="net.tcp://localhost:8000/ServiceModelSamples/Service"/>
        <endpoint address=""
                    contract="Microsoft.ServiceModel.Samples.ICalculatorDuplex" />
        <!-- the mex endpoint is exposed at net.tcp://localhost:8000/ServiceModelSamples/service/mex -->
        <endpoint address="mex"
                  contract="IMetadataExchange" />

      <!-- configure a custom binding -->
        <binding name="Binding1">
          <security authenticationMode="SecureConversation"
          <textMessageEncoding messageVersion="Soap12WSAddressing10" writeEncoding="utf-8"/>
          <sslStreamSecurity requireClientCertificate="false"/>

    <!--For debugging purposes set the includeExceptionDetailInFaults attribute to true-->
        <behavior name="CalculatorServiceBehavior">
          <serviceMetadata />
          <serviceDebug includeExceptionDetailInFaults="False" />
            <serviceCertificate findValue="localhost" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName"/>