WCF-WSHttp Transport Properties Dialog Box, Receive, Security Tab

 

Use the Security tab to define the security capabilities of the WCF-WSHttp receive adapter.

Use this	To do this
Security mode	Specify the type of security that is used. Valid values include the following: - None: Messages are not secured during transfer. - Transport: Security is provided using the HTTPS transport. The SOAP messages are secured using HTTPS. To use this mode, you must set up Secure Sockets Layer (SSL) in Microsoft Internet Information Services (IIS). - Message: Security is provided using SOAP message security over the HTTP transport. By default, the SOAP Body is encrypted and signed. This mode offers a variety of features, such as whether the service credentials are available at the client out of band, and the algorithm suite to use. If you select None, Certificate, or UserName for the Message client credential type property in this security mode, the service certificate for this receive location needs to be provided through the Service certificate - Thumbprint property. - TransportWithMessageCredential: Integrity, confidentiality, and service authentication are provided by the HTTPS transport. To use this mode, you must set up Secure Sockets Layer (SSL) in Microsoft Internet Information Services (IIS). The default is Message.
Transport client credential type	Specify the type of credential to be used when performing the client authentication. Valid values include the following: - None: No authentication occurs at the transport level. - Basic: Basic authentication. In Basic authentication, user names and passwords are sent in plain text over the network. You must create the domain or local user accounts corresponding to the credentials. - Digest: Digest authentication. This authentication method operates much like Basic authentication, except that passwords are sent across the network as a hash value for additional security. Digest authentication is available only on domains with domain controllers running Windows Server operating systems authentication. You must create the domain or local user accounts corresponding to client credentials. - Ntlm: NTLM authentication. Clients can send the credentials without sending a password to this receive location. You must create the domain or local user accounts corresponding to client credentials. - Windows: Windows integrated authentication. Windows Communication Foundation negotiates Kerberos or NTLM, preferring Kerberos if a domain is present. If you want to use Kerberos it is important to have the client identify the service with a service principal name (SPN). You must create the domain or local user accounts corresponding to client credentials. - Certificate: Client authentication using the client certificate. The CA certificate chain for the client X.509 certificates must be installed in the Trusted Root Certification Authorities certificate store of this computer so that the clients can be authenticated to this receive location. Note: The Transport client credential type property must match the authentication scheme of the IIS virtual directory hosting this receive location. For example, if the property is set to Windows, you also need to enable Integrated Windows authentication for the virtual directory that hosts it. Similarly if the property is set to None, you must allow anonymous access to the virtual directory that hosts this receive location. The default is Windows.
Message client credential type	Specify the type of credential to be used when performing client authentication using message-based security. Valid values include the following: - None: Allow the service to interact with anonymous clients. This indicates that this receive location does not require any client credential. - Windows: Allow the SOAP exchanges to be under the authenticated context of a Windows credential. You must create the domain or local user accounts corresponding to the client credentials. - UserName: Allow this receive location to require that clients be authenticated using the UserName credential. You must create the domain or local user accounts corresponding to client credentials. - Certificate: Clients are authenticated to this receive location using the client certificate. The CA certificate chain for the client X.509 certificates must be installed in the Trusted Root Certification Authorities certificate store of this computer so that the clients can be authenticated to this receive location. Note: The Message client credential type property must match the authentication scheme of the IIS virtual directory hosting this receive location. For example, if the property is set to Windows, you also need to enable Integrated Windows authentication for the virtual directory that hosts it. Similarly if the property is set to None, you must allow anonymous access to the virtual directory that hosts this receive location. The default is Windows.
Algorithm suite	Specify the message encryption and key-wrap algorithms. These algorithms map to those specified in the Security Policy Language (WS-SecurityPolicy) specification. Possible values are: - Basic128: Use Aes128 encryption, Sha1 for message digest, and Rsa-oaep-mgf1p for key wrap. - Basic128Rsa15: Use Aes128 for message encryption, Sha1 for message digest, and Rsa15 for key wrap. - Basic128Sha256: Use Aes256 for message encryption, Sha256 for message digest, and Rsa-oaep-mgf1p for key wrap. - Basic128Sha256Rsa15: Use Aes128 for message encryption, Sha256 for message digest, and Rsa15 for key wrap. - Basic192: Use Aes192 encryption, Sha1 for message digest, and Rsa-oaep-mgf1p for key wrap. - Basic192Rsa15: Use Aes192 for message encryption, Sha1 for message digest, and Rsa15 for key wrap. - Basic192Sha256: Use Aes192 for message encryption, Sha256 for message digest, and Rsa-oaep-mgf1p for key wrap. - Basic192Sha256Rsa15: Use Aes192 for message encryption, Sha256 for message digest, and Rsa15 for key wrap. - Basic256: Use Aes256 encryption, Sha1 for message digest, and Rsa-oaep-mgf1p for key wrap. - Basic256Rsa15: Use Aes256 for message encryption, Sha1 for message digest, and Rsa15 for key wrap. - Basic256Sha256: Use Aes256 for message encryption, Sha256 for message digest, and Rsa-oaep-mgf1p for key wrap. - Basic256Sha256Rsa15: Use Aes256 for message encryption, Sha256 for message digest, and Rsa15 for key wrap. - TripleDes: Use TripleDes encryption, Sha1 for message digest, Rsa-oaep-mgf1p for key wrap. - TripleDesRsa15: Use TripleDes encryption, Sha1 for message digest, and Rsa15 for key wrap. - TripleDesSha256: Use TripleDes for message encryption, Sha256 for message digest, and Rsa-oaep-mgf1p for key wrap. - TripleDesSha256Rsa15: Use TripleDes for message encryption, Sha256 for message digest, and Rsa15 for key wrap. The default value is Basic256.
Negotiate service credential type	Specify whether the service credential is provisioned at the client out of band, or is obtained from the service to the client through a process of negotiation. Such a negotiation is a precursor to the usual message exchange. If the Message client credential type property equals to None, Username, or Certificate, clearing this property implies that the service certificate is available at the client out of band and that the client needs to specify the service certificate. This mode is interoperable with SOAP stacks which implement WS-Trust and WS-SecureConversation. If the Message client credential type `property is set to Windows, clearing this property specifies Kerberos based authentication. This means that the client and service must be part of the same Kerberos domain. This mode is interoperable with SOAP stacks which implement the Kerberos token profile (as defined at OASIS WSS TC) as well as WS-Trust and WS-SecureConversation. When this property is selected, it causes a .NET SOAP negotiation that tunnels SPNego exchange over SOAP messages. The default value is selected.
Establish security context	Specify whether the security channel establishes a secure session. A secure session establishes a Security Context Token (SCT) before exchanging the application messages. The default value is selected.
Service certificate -Thumbprint	Specify the thumbprint of the X.509 certificate for this receive location that the clients use to authenticate the service. The thumbprint can be selected by navigating the My store in the Current User location with the Browse button. Note: You must install the service certificate into the Current User location of the user account for the receive handler hosting this receive location. Minimum length: 0 Maximum length: 40 The default is an empty string.
Use Single Sign-On	Use Single Sign-On to retrieve client credentials to issue an SSO ticket. This option is valid only for the security configurations listed in the following section, "Enterprise Single Sign-On Supportability for the WCF -WSHttp Receive Adapter." The default value is cleared.

Enterprise Single Sign-On Supportability for the WCF-WSHttp Receive Adapter

The WCF-WSHttp receive adapter can issue an SSO ticket from the SSO server only in the security configurations shown in the following table.

Security mode	Transport client credential type	Message client credential type
Transport	Basic	N/A
Transport	Digest	N/A
Transport	Ntlm	N/A
Transport	Windows	N/A
Transport	Certificate	N/A
Message	N/A	UserName
TransportWithMessageCredential	N/A	UserName

See Also

Managing BizTalk Hosts and Host Instances
How to Change Service Accounts and Passwords
How to Configure a WCF-WSHttp Receive Location
Installing Certificates for the WCF Adapters
Configuring IIS for the Isolated WCF Receive Adapters