Windows Communication Foundation performs a lot of the heavy lifting to make it easier for your service to provide the basic security features that most distributed systems need. The big three protections— confidentiality, integrity, and authentication (or CIA ) are provided by most standard Windows^® Communication Foundation bindings. If you don't want these protections, you'll have to turn them off, because they are on by default.

    You can expose a single service contract over as many bindings as you like; just expose a different endpoint for each binding. For example, you might expose a very simple WS-I basic profile binding over HTTPS to interoperate with existing partners in a supply chain. At the same time, you could expose a TCP endpoint that uses Windows authentication for local clients in your domain. A typical standard binding has a lot of different knobs for adjusting security settings, but each binding has been carefully tuned to provide secure default settings for most of the scenarios you'll encounter. The two knobs you'll most often need to toggle are the security mode (transport versus message security) and the client credential type.

 

Transport Security: 

1. wsHttpBinding

    If configure wsHttpBinding for transport security(basically means SSL security), Windows Communication Foundation will not supply CIA for messages. You're expected to run over HTTPS so that SSL can provide these guarantees. In fact, Windows Communication Foundation will refuse to set up the connection unless an HTTPS URI is provided. If  hosting inside IIS, need to install an SSL certificate for the Web site. On the other hand, if hosting in  own process and using HTTP.SYS directly, need to register a certificate with HTTP.SYS, either programmatically or via the command-line tool, HTTPCFG.EXE.  It uses message security by default, with WS-Security and WS-SecureConversation. The default client credential type is Windows, which makes it really easy to get started with.

2. basicHttpBinding

    If broad reach across platforms is your goal, there's no better choice today than using the WS-I basic profile over SSL which of course would also mean using basicHttpBinding instead of wsHttpBinding. It's important to note that this particular binding doesn't provide CIA by default.

3. netTcpBinding

    For internal communication in a domain environment where both client and service use Windows Communication Foundation, netTcpBinding with transport security might be a better choice. It certainly performs a lot better given its binary encoding, and since it uses Kerberos exclusively by default, there's no need for certificates.

 

Message Security:

    Instead of providing CIA at the transport level, we can choose to push these details down into the SOAP messages themselves by using message security. The main benefit here is flexibility.  We can use any type of security credentials want, largely independent of transport, as long as both client and service agree. In fact, we could even send multiple credentials, which becomes interesting in delegation scenarios where intermediaries are involved.

 

Mix Transport and Message security

    In this mode, confidentiality and integrity and the server's authentication are provided at the transport level, whereas client authentication is performed at the message level. The client can then use WS-Security to send any shape of credential that she wants.

 

<binding name="MyBindingTweaks">
  <security mode="TransportWithMessageCredential">
    <transport clientCredentialType="None"/>
    <message clientCredentialType="IssuedToken"/>
  </security>
</binding>

 

    Once you've chosen either transport or message security (or mixed mode), and assuming you've not chosen a security mode of None, the next major decision is the shape of credential that the client and service will use. Windows Communication Foundation simplifies this by giving you only one knob, the client credential type, which also determines the service credential type that makes sense in each scenario. There are at least five options for client credentials:

1. None

    The first option is None, where the client is anonymous. In this case the service uses a certificate to assure the client of the service's identity. 

 

<bindings>
  <basicHttpBinding>
    <binding name="MyBindingTweaks">
      <security mode="Transport">
        <transport clientCredentialType="None"/>
      </security>
    </binding>
  </basicHttpBinding>
</bindings>

2. UserName

    The second option is UserName, where the client supplies a user name and password. In this case the service uses a certificate to identify itself to the client. This certificate will also be used to encrypt the client's credentials for transmission to the service.

On client side coding:

pxy.ChannelFactory.Credentials.UserNamePassword.UserName = "username";
pxy.ChannelFactory.Credentials.UserNamePassword.Password = "password";

 

and the The result will be a username token embedded in the <headers> of the SOAP message :

<s:Envelope xmlns:s="...">
    <s:Header>
      <o:Security s:mustUnderstand="1" xmlns:o="...">
        <o:UsernameToken u:Id="uuid-060c77ce-...">
          <o:Username>username</o:Username>
          <o:Password o:Type="...">password</o:Password>
        </o:UsernameToken>
      </o:Security>
    </s:Header>
    <s:Body>
      <SubmitCreditCard xmlns="...">
        ...
      </SubmitCreditCard>
    </s:Body>
  </s:Envelope>

3. Windows

    The next option is Windows, where both the client and service use a Windows account to authenticate. Windows Communication Foundation will negotiate Kerberos or NTLM, preferring Kerberos if a domain is present and NTLM does not actually authenticate the service to the client, only the client to the service. If you want to use Kerberos it's important to have the client identify the service with a service principal name (SPN) in config.

4. Certificate

    Certificate is another option, where the service has a certificate and the client also has a certificate of her own. This is typical in many business-to-business scenarios today.

5. IssuedToken

    IssuedToken allows your service to accept a signed set of claims from a security token service (STS), it enables federated identity scenarios and InfoCard. When you federate with a partner organization, you allow the partner to authenticate its own users via whatever technique makes sense for them. In the best case, this will allow users in the partner organization to use your service with single sign-on, even though they don't share an Active Directory domain or trust with you. The users in the partner organization are required to authenticate with an STS, which issues a signed Security Assertion Markup Language (SAML) token.