Message security allows a number of scenarios not possible with transport-level security:

  • end-to-end encryption
  • different parts of the message can be secured with different encryption mechanisms
  • different parts of the message can be secured using different credentials (a single message can have multiple receivers or a message can contain unencrypted routing data, but an encrypted payload)
  • the message security does not depend on the binding

Possible client credentials:

  • Certificate (use proxy.ClientCredentials.ClientCertificate.SetCertificate to set the certificate)
  • IssuedToken (a client requests a security token from a STS service and then it provides this token to the WCF service; the WCF service validates the token with the STS service)
  • None (anonymous access to the service)
  • UserName (use proxy.ClientCredentials.UserName.UserName and proxy.ClientCredentials.UserName.Password to set these values; the values cannot be configured in the config file)
  • Windows (the credentials for the currently logged-on Windows user)

The default client credentials type is Windows.

The xml sequence below shows how to set the clientCredentialType attribute.


<binding name="httpWithSecureMessage">

<security mode="Message">

<message clientCredentialType="UserName"/>

</security>

</binding>

Changing the algorithm suite

There are multiple security-specific algorithms to be executed when protecting a message (each algorithm ensures one security aspect, be it confidentiality, data integrity, parties authentication and so on).

An algorithm suite describes the following:

  • encryption type (like Aes128, TripleDes, Aes256)
  • symmetric and asymmetric keys signatures (Sha1, Sha256)
  • symmetric and asymmetric key wrap
  • computed key
  • maximum and minimum key lengths

The default algorithm suite is Basic256.

The algorithm suite attribute is ignored when the binding is net.pipe.

Establishing a security context

When a client and a server must exchange multiple messages, a security context should be established first and then this context should be used to authenticate the messages.

By default, establishSecurityContext is true (based on the assumption that a client will send multiple messages to the server).

The attribute establishSecurityContext is valid only for:

  • wsHttpBinding
  • wsHttpContextBinding
  • ws2007HttpBinding

Authenticating the server

The attribute negotiateServiceCredentials controls whether the server is authenticated using Windows Services SP Negotiation (SPNEGO) or the client must have an out-of-band information about the server to authenticate it.

When SPNEGO is executed, the server certificate is provided to the client.

When no negotiation occurs, there are two possibilities:

  • the service certificate is accesible to the client (it’s installed on the local system) (client credentials are one of None, UserName, Certificate)
  • the client and the service are part of the same Windows domain and a Kerberos token is used to authenticate the service (client credentials must be Windows)

 

Advertisements