Securing Messages Using Message Security
This section discusses WCF message security when using NetMsmqBinding.
Before reading through this topic, it is recommended that you read Security Concepts.
The following illustration provides a conceptual model of queued communication using WCF. This illustration and terminology are used to explain
transport security concepts.
When sending queued messages using WCF, the WCF message is attached as a body of the Message Queuing (MSMQ) message. While transport security secures the entire MSMQ message, message (or SOAP) security only secures the body of the MSMQ message.
The key concept of message security is that the client secures the message for the receiving application (service), unlike transport security where the client secures the message for the Target Queue. As such, MSMQ plays no part when securing the WCF message using message security.
WCF message security adds security headers to the WCF message that integrate with existing security infrastructures, such as a certificate or the Kerberos protocol.
Using message security, the service and client can present credentials to authenticate each another. You can select message security by setting the Security mode to Message or Both (that is, use both transport security and message security).
The service can use the Current property to inspect the credential used to authenticate the client. This can also be used for further authorization checks that the service chooses to implement.
This section explains the different credential types and how to use them with queues.
The certificate credential type uses an X.509 certificate to identify the service and the client.
In a typical scenario, the client and the service are issued a valid certificate by a trusted certification authority. Then the connection is established, the client authenticates the validity of the service using the service's certificate to decide whether it can trust the service. Similarly, the service uses the client's certificate to validate the client trust.
Given the disconnected nature of queues, the client and the service may not be online at the same time. As such, the client and service have to exchange certificates out-of-band. In particular, the client, by virtue of holding the service's certificate (which can be chained to a certification authority) in its trusted store, must trust that it is communicating with the correct service. For authenticating the client, the service uses the X.509 certificate attached with the message to matches it with the certificate in its store to verify the authenticity of the client. Again, the certificate must be chained to a certification authority.
On a computer running Windows, certificates are held in several kinds of stores. For more information about the different stores, see Certificate stores.
Windows message credential type uses the Kerberos protocol.
The Kerberos protocol is a security mechanism that authenticates users on a domain and allows the authenticated users to establish secure contexts with other entities on a domain.
The problem with using the Kerberos protocol for queued communication is that the tickets that contain client identity that the Key Distribution Center (KDC) distributes are relatively short-lived. A lifetime is associated with the Kerberos ticket that indicates the validity of the ticket. As such, given high latency, you cannot be sure that the token is still valid for the service that authenticates the client.
Note that when using this credential type, the service must be running under the SERVICE account.
The Kerberos protocol is used by default when choosing message credential. For more information, see Exploring Kerberos, the Protocol for Distributed Security in Windows 2000.
Using this property, the client can authenticate to the server using a username password in the security header of the message.
The client can use the security token service to issue a token that can then be attached to the message for the service to authenticate the client.