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:
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)